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客户端如何能够获得流水线的好处，并在同一时间不支付响应排队的缺点是什么？
客户端无法规避HOL-排队，因为它是RFC 2616流水线的唯一好处（在我看来）的一部分，是在极其特殊和窄箱。 考虑：
的R 1 成本 = Request A处理成本。
R 2 成本 = Request B的处理成本。
TCP 成本 =成本谈判新的TCP连接。
采用流水线会，因此，在特定的情况下是可行：
的R 1个 成本 ≥R 2≤ 成本 TCP 成本
如何往往是一个请求比以前的要求比谈判一项新的TCP连接更昂贵和更便宜？ 不经常。 我想补充一点的WebSockets是（目前）一个更有趣，更合适的解决方案（只要并行后端处理而言）。
它不能（在HTTP / 1.1）。 这可能是在HTTP的未来版本。
没有在HTTP报头没有默认机制，以确定哪个响应将匹配哪个请求。 的响应是已知的是，因为在其中它接收的顺序的特定请求。 如果你要求1.JPG，2.JPG，3.JPG，4.JPG和5.JPG以任意顺序发送的响应，你不会不知道哪个是哪个。
（你可以实现自己的标记在客户端和服务器头，但你肯定不符合协议和大多数实现不知道如何面对这一切。你将不得不做一些处理映射，这可能否定预计这种并行执行的好处。）
你从现有的HTTP管道机制获得的主要好处是：
这些好处也可以通过更现代的网络浏览器技术，其中多个请求可以单独和页面的某些部分可能被更新（通过AJAX）发送逐步获得的。
