为什么流水线在现代浏览器中被禁用？

Why is pipelining disabled in modern browsers?

很多（如果不是所有）现代浏览器都没有使用流水线 HTTP 请求。理论上，流水线应该通过减少获取网站所需的往返次数来加速请求。

根据HTTP标准，所有服务器必须处理流水线请求，所以应该不是服务器不支持的问题。

我看到了一些安全问题，例如第 7 层 DoS 攻击，如果客户端将尽可能多的流水线请求推送到服务器性能密集型 URL，忽略任何可能的答案收到。

这将是在服务器上关闭流水线支持的一个原因（违反标准），但我找不到任何理由在客户端上关闭它。

然而，它在 Android 浏览器和 Chrome 移动设备上默认打开。

为什么 Chrome、Firefox、IE、Opera 和 Safari 不在其桌面（有时是移动）版本中使用流水线 HTTP 请求？他们关闭它的原因是什么？

流水线被禁用，原因如下：

  • 火狐：

The bigger issue has frankly been head of line blocking and its impact on performance and robustness. Naïve pipelines simply make performance worse.

  • Chrome:

The option to enable pipelining has been removed from Chrome, as there are known crashing bugs and known front-of-queue blocking issues. There are also a large number of servers and middleboxes that behave badly and inconsistently when pipelining is enabled. Until these are resolved, it's recommended nobody uses pipelining. Doing so currently requires a custom build of Chromium.

总的来说：

Buggy proxies are still common and these lead to strange and erratic behaviors that Web developers cannot foresee and diagnose easily.

Pipelining is complex to implement correctly: the size of the resource being transferred, the effective RTT that will be used, as well as the effective bandwidth, have a direct incidence on the improvement provided by the pipeline. Without knowing these, important messages may be delayed behind unimportant ones. The notion of important even evolves during page layout! HTTP pipelining therefore brings a marginal improvement in most cases only.

Pipelining is subject to the HOL problem.

HTTP/2 提供替代方案：

With HTTP/1.x, the browser has limited ability to leverage above priority data: the protocol does not support multiplexing, and there is no way to communicate request priority to the server. Instead, it must rely on the use of parallel connections, which enables limited parallelism of up to six requests per origin. As a result, requests are queued on the client until a connection is available, which adds unnecessary network latency. In theory, HTTP Pipelining tried to partially address this problem, but in practice it has failed to gain adoption.

HTTP/2 resolves these inefficiencies: request queuing and head-of-line blocking is eliminated because the browser can dispatch all requests the moment they are discovered, and the browser can communicate its stream prioritization preference via stream dependencies and weights, allowing the server to further optimize response delivery.

也可以使用代理：

You can try something I did to speed up Konqueror in KDE3. I was dissatisfied that Konqueror did not have HTTP pipelining, so after some searching, I installed Polipo as a local HTTP/HTTPS/FTP proxy and set Konqueror to use it (localhost on port 8123 if I remember correctly). In addition to HTTP pipelining, Polipo also provided improved caching, and since it was a proxy, I could set every browser to use it and the caching would be shared between the browsers. (This also means that it is a good idea to disable each browser's independent caching.)

Salesforce 使用以下流程：

Salesforce has a powerful and field-tested approach for mitigating HOLB at the TCP layer: we decouple the relation between an HTTP request and a TCP connection. Think about your transport as composed of multiple TCP connections (as many as the network context would need). Any part of the HTTP request can go over any TCP connection. So if you hit the HOLB in one connection, it not only helps in mitigating affected requests, it also minimizes impact to other application requests using healthy connections. The result is an ability to enjoy the benefits of multiplexing and pipelining at the HTTP layer while minimizing risks of HOLB.

参考资料

接受的答案可能有些过时了。今天，我看到 chrome 桌面管道在针对我们服务器的单个 HTTPS 连接中发出 10 个请求，这为我提供了管道计数。