现代浏览器中，很多甚至所有的浏览器都没有使用流水线式的HTTP请求。理论上，通过减少获取网站所需的往返次数，流水线式请求应该加速请求。
根据HTTP标准，所有服务器必须处理流水线式请求，因此问题不应该是服务器缺乏支持。
我见过一些安全方面的担忧，例如如果客户端向一个对服务器性能有压力的URL推送尽可能多的流水线式请求，并忽略可能收到的任何答案，则会发生第七层拒绝服务攻击。
这将是关闭服务器上流水线式支持的原因（违反标准），但我找不到在客户端上关闭它的任何理由。
然而，在Android浏览器和Chrome移动版中，默认情况下已启用流水线式请求。
为什么Chrome、Firefox、IE、Opera和Safari在它们的桌面（有时是移动）版本中不使用流水线式HTTP请求？他们关闭它的理由是什么？
以下原因导致流水线未启用：
更大的问题实际上是队列阻塞及其对性能和鲁棒性的影响。简单的流水线只会使性能变差。
已从Chrome中删除启用流水线的选项，因为已知存在崩溃错误和前置队列阻塞问题。当启用流水线时，许多服务器和中间件表现不良且不一致。在这些问题得到解决之前，建议不要使用流水线。目前需要自定义构建Chromium才能使用。
总体而言：
存在错误的代理仍然很普遍，这会导致奇怪和不稳定的行为，使Web开发人员难以预见和诊断。
正确实现流水线传输很复杂：正在传输的资源大小、使用的有效RTT以及有效带宽直接影响流水线传输提供的改进。如果不知道这些信息，重要的消息可能被延迟在不重要的消息之后。而且，重要性的概念甚至在页面布局过程中还在不断演变！因此，HTTP流水线传输在大多数情况下只能带来较小的改进。
流水线传输受HOL问题的影响。
HTTP/2提供了一种替代方案：
使用HTTP/1.x协议，浏览器的能力受限：该协议不支持多路复用，并且没有方法将请求优先级通知服务器。因此，它必须依赖于使用并行连接，这使每个源可以进行有限的并行处理，最多可处理六个请求。结果，请求在客户端上排队，直到有可用连接，这增加了不必要的网络延迟。理论上，HTTP Pipelining试图部分解决此问题，但实际上未能获得广泛应用。HTTP/2解决了这些低效率：请求排队和头阻塞被消除，因为浏览器可以在发现所有请求时立即调度它们，并且浏览器可以通过流依赖关系和权重来传达其流优先级偏好，从而允许服务器进一步优化响应传递。
代理也可以使用：
你可以尝试我所做的一些事情来加快KDE3中Konqueror的速度。我对Konqueror没有HTTP pipelining感到不满，因此经过一些搜索，我安装了Polipo作为本地HTTP / HTTPS / FTP代理，并设置Konqueror使用它（如果我记得正确，则为端口8123上的localhost）。除了HTTP pipelining外，Polipo还提供了改进的缓存，由于它是代理，我可以设置每个浏览器都使用它，并且缓存将在浏览器之间共享。（这也意味着最好禁用每个浏览器的独立缓存。）接受的答案可能有些过时。今天我看到chrome桌面将10个请求通过单个HTTPS连接发送到我们的服务器，这为我提供了管道计数。
