非串行管道 HTTP 可能吗？

RFC 2616第8.1.2.2节 http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.1.2.2 states:

支持持久连接的客户端可以“管道”其请求（即发送多个请求而不等待每个响应）。一台服务器MUST发送对这些请求的响应以相同的顺序请求已收到。

串行响应是often弊大于利，因为串行响应实际上要求服务器做更多的事情加工 https://devcentral.f5.com/weblogs/macvittie/archive/2009/04/02/http-pipelining-a-security-risk-without-real-performance-benefits.aspx并抵消了通过管道获得的性能优势。

例如，如果 HTTP 客户端请求文件 1.jpg、2.jpg、3.jpg、4.jpg 和 5.jpg，则无论 3.jpg 在 1.jpg 之前返回，还是 4.jpg 都没有关系。 .jpg 在 3.jpg 之前返回。客户只是希望尽快得到答复，any order.

HTTP 客户端如何才能获得管道传输的好处，同时又不用承受响应队列的缺点？

客户端无法规避 HOL 队列，因为它是 RFC 2616 的一部分。管道的唯一好处（在我看来）是在极其具体和狭窄的情况下。考虑：

R¹_cost = Request A processing cost.
R²_cost = Request B processing cost.
TCP_cost = Cost of negotiating new TCP connection.

因此，在以下特定情况下使用管道是可行的：

R¹_cost ≥ R²_cost ≤ TCP_cost

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