许多（如果不是所有）现代浏览器都没有使用流水线 HTTP 请求。理论上，流水线应该通过减少获取网站所需的往返次数来加速请求。
根据 HTTP 标准，所有服务器都必须处理流水线请求，所以问题不应该在于服务器缺乏支持。
我已经看到了一些安全问题，例如第 7 层 DoS 攻击，如果客户端将尽可能多的流水线请求推送到服务器性能密集型 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 流水线感到不满意，所以经过一番搜索，我将 Polipo 安装为本地 HTTP/HTTPS/FTP 代理，并设置 Konqueror 使用它（如果我没记错的话，localhost 在端口 8123 上）。除了 HTTP 管道，Polipo 还提供了改进的缓存，因为它是一个代理，我可以设置每个浏览器都使用它，并且缓存将在浏览器之间共享。（这也意味着禁用每个浏览器的独立缓存是个好主意。）
Salesforce 使用以下流程：
Salesforce 有一种强大且经过现场测试的方法来减轻 TCP 层的 HOLB：我们将 HTTP 请求和 TCP 连接之间的关系解耦。将您的传输视为由多个 TCP 连接组成（与网络上下文所需的数量一样多）。HTTP 请求的任何部分都可以通过任何 TCP 连接。因此，如果您在一个连接中点击 HOLB，它不仅有助于减轻受影响的请求，还可以最大限度地减少对使用健康连接的其他应用程序请求的影响。结果是能够在 HTTP 层享受多路复用和流水线的好处，同时最大限度地降低 HOLB 的风险。
参考
接受的答案可能有些过时。今天，我在针对我们服务器的单个 HTTPS 连接中看到了 chrome 桌面管道 10 个请求，这为我提供了管道计数。