2

RFC 2616第 8.1.2.2 节指出:

支持持久连接的客户端可以“管道”其请求(即,发送多个请求而不等待每个响应)。服务器必须以与接收请求相同的顺序发送对这些请求的响应。

串行响应通常弊大于利,因为串行响应实际上需要服务器进行更多处理,并抵消了流水线带来的性能优势。

例如,如果 HTTP 客户端请求文件 1.jpg、2.jpg、3.jpg、4.jpg 和 5.jpg,则无论 3.jpg 在 1.jpg 之前返回,还是 4 .jpg 在 3.jpg 之前返回。客户只希望响应可用,以任何顺序。

HTTP 客户端如何获得流水线的好处,同时又不为响应队列的缺点买单?

4

3 回答 3

2

客户端无法绕过 HOL 排队,因为它是 RFC 2616 的一部分。流水线的唯一好处(在我看来)是在极其具体和狭窄的情况下。考虑:

R 1成本=Request A加工成本。
R 2成本=Request B加工成本。
TCP成本= 协商新 TCP 连接的成本。

因此,在以下特定情况下使用流水线是可行的:

R 1成本R 2成本TCP成本

一个请求比前一个请求更昂贵并且比协商一个新的 TCP 连接更便宜的频率是多少?不经常。我要补充一点,Websockets(到目前为止)是一个更有趣和更合适的解决方案(就并行后端处理而言)。

于 2012-07-17T18:53:01.183 回答
1

它不能(在 HTTP/1.1 中)。它可能在 HTTP 的未来版本中。

于 2012-07-17T19:10:19.840 回答
1

HTTP 标头中没有默认机制来识别哪个响应将匹配哪个请求。由于接收到的顺序,响应被称为对特定请求的响应。如果您请求 1.jpg、2.jpg、3.jpg、4.jpg 和 5.jpg 并以任意顺序发送响应,您将不知道哪个是哪个。

(您可以在客户端和服务器标头中实现自己的标记,但您肯定不符合协议并且大多数实现不知道如何处理它。您必须进行一些处理才能映射,这可能会否定这种并行实现的预期好处也是如此。)

您从现有 HTTP 管道机制中获得的主要好处是:

  • 可能减少通信延迟。这可能很重要,具体取决于您的连接。
  • 对于需要更长的服务器端计算的请求,服务器可以在接收到请求时在后台启动此计算,同时它正在发送先前的响应,以便能够更早地开始发送第二个结果。(这也是一种延迟形式,但在响应准备方面。)

这些好处中的一些也可以通过更现代的网络浏览器技术获得,其中可以单独发送多个请求,并且可以逐步更新页面的某些部分(通过 AJAX)。

于 2012-07-17T19:23:08.390 回答