应用错误收集

许多（如果不是全部）现代浏览器都没有使用流水线HTTP请求。理论上，流水线操作应该通过减少获取网站所需的往返时间来加快请求。

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

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

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

默认情况下，Android浏览器和Chrome移动设备已启用。

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

由于以下原因，禁用了管道输出：

火狐：

更大的问题坦率地说是线路阻塞的主要因素及其对性能和稳健性的影响。天真的管道只会让性能变得更糟。

铬：

启用流水线操作的选项已从Chrome中删除，因为已知崩溃错误和已知的队列前阻塞问题。在启用流水线操作时，还有大量服务器和中间件行为严重且不一致。在解决这些问题之前，建议没有人使用流水线技术。目前这样做需要自定义构建Chromium。

一般来说：

Buggy代理仍然很常见，这导致了Web开发人员无法预见和诊断的奇怪和不稳定的行为。

流水线操作很难正确实施：传输资源的大小，将要使用的有效RTT以及有效带宽直接影响管道提供的改进。如果不了解这些，重要信息可能会延迟到不重要的信息之后。重要的概念甚至在页面布局中发展！因此，HTTP流水线技术仅在大多数情况下带来了微小的改进。

流水线操作受HOL problem。
的约束

HTTP / 2提供了另一种选择：

对于HTTP / 1.x，浏览器利用以上优先级数据的能力有限：协议不支持多路复用，并且无法将请求优先级传达给服务器。相反，它必须依赖于并行连接的使用，这使得每个源最多可以有六个请求的有限并行性。因此，请求在客户端上排队，直到连接可用，这会增加不必要的网络延迟。从理论上讲，HTTP Pipelining试图部分解决这个问题，但实际上它未能被采用。

HTTP / 2解决了这些低效问题：消除了请求排队和线头阻塞，因为浏览器可以在发现所有请求时调度所有请求，并且浏览器可以通过流依赖性和权重传达其流优先级排序首选项，允许服务器进一步优化响应传递。

也可以使用代理：

您可以尝试我在KDE3中加快Konqueror的速度。我不满意Konqueror没有HTTP流水线，所以经过一些搜索，我将Polipo安装为本地HTTP / HTTPS / FTP代理并设置Konqueror使用它（如果我没记错的话，在端口8123上使用localhost）。除了HTTP流水线之外，Polipo还提供了改进的缓存，由于它是一个代理，我可以设置每个浏览器使用它，缓存将在浏览器之间共享。（这也意味着禁用每个浏览器的独立缓存是一个好主意。）

Salesforce使用以下过程：

Salesforce有一个强大且经过实地测试的方法来减轻TCP层的HOLB：我们解耦HTTP请求和TCP连接之间的关系。将您的传输视为由多个TCP连接组成（与网络上下文一样多）。 HTTP请求的任何部分都可以通过任何TCP连接。因此，如果您在一个连接中点击HOLB，它不仅有助于减轻受影响的请求，还可以最大限度地减少使用健康连接对其他应用程序请求的影响。结果是能够在HTTP层享受多路复用和流水线操作的好处，同时最大限度地降低HOLB的风险。

<强>参考

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

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

2 个答案: