为什么HTTP每个套接字只能处理一个待处理请求？

Question

好奇，我想知道为什么HTTP在设计上只能处理每个套接字的一个待处理请求。

我理解这种限制是因为没有'Id'将请求与其响应相关联，因此将响应与其请求匹配的唯一方法是在发送请求的同一套接字上发送响应。如果套接字上有多个待处理请求，则无法匹配对其请求的响应，因为我们可能无法按照发送请求的相同顺序收到响应。

如果协议设计为对请求和响应具有匹配的“Id”，则只有一个套接字可能存在多个待处理请求。这可以大大减少使用Web服务的Internet浏览器和应用程序使用的套接字数量。

为了简单起见，HTTP设计是这样的，即使效率较低，或者我错过了什么，这是最好的方法吗？

感谢。

Answer 1

不正确。阅读有关HTTP1.1流水线的信息。 Apache实现它并且Firefox实现它。虽然Firefox默认禁用它。

要在Firefox中启用它，请使用about:config并在过滤器中写入“pipelining”。

请参阅：http://www.mozilla.org/projects/netlib/http/pipelining-faq.html

Answer 2

在单个套接字上发送多个请求的一个问题是它会导致低效的排队。

例如，假设您在商店，有2个收银员，还有10个人等待退房。制作生产线的理想方法是拥有一个10人的队列，并且当他们可用时，下一个排队的人会前往收银台。但是，如果您一次发送所有请求，您可能会将5个人送到收银员A，5个人送到收银员B.但是，如果您将带有最大购物车的5个人送到同一个收银台怎么办？这是不好的排队，如果你在一个套接字上排队一堆请求会发生什么。

注意：我并不是说您不能很好地使用排队，但如果单个套接字上没有排队，它可以很容易地做到这一点。

Answer 3

这基本上是为了简单;多年来已经提出了各种建议，即在同一连接上复用（例如SPDY）但尚未起飞。

Answer 4

我会审查一些问题。

第一个与TCP本身的性质有关。 TCP遭遇“头线”阻塞问题，其中只有一个未完成（未确认）的请求（连接/ TCP级别）在飞行中。鉴于传统的延迟，从加载时用户体验的角度来看，与今天采用的并行连接方案浏览器的结果相比，这可能是一个问题。链接的延迟越高，这种基本限制的影响就越大。

还存在并发问题，有时您确实希望以递增/并行方式加载多个资源。回到当天，mozilla对马赛克的最大特点之一是它会逐渐加载图像和对象，这样你就可以开始看到发生了什么并使用资源而无需等待它加载。由于连接较少，因此存在风险，例如，在从样本角度看样式表可能是灾难性的之前，在页面上加载大图像。期望某种缓解情报或明确配置以优化订单请求可能不是一个现实或理想的解决方案。

有一些建议，例如HTTP over SCTP，或多或少会完全纠正您在传输级别引发的问题。

Answer 5

还要意识到HTTP并不一定要求Content-Length标头来提供数据。即使每个HTTP响应都是ID，您如何管理没有内容长度（HTTP / 1.0样式）的流式二进制内容？或者，如果客户端发送Connection: close标头以使客户端由于未知长度而关闭？

要管理这个，你必须在Multiplex中使用HTTP chunk（已经存在）（我认为没有人实现这个），并为许多程序添加一些非平凡的工作。