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 回答