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

【问题标题】：Why is pipelining disabled in modern browsers?为什么在现代浏览器中禁用流水线？
【发布时间】：2015-08-09 05:52:15
【问题描述】：

如果不是所有现代浏览器，许多现代浏览器都没有使用流水线 HTTP 请求。理论上，流水线应该通过减少获取网站所需的往返次数来加速请求。

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

我看到了一些安全问题，例如，如果客户端将尽可能多的管道请求推送到对服务器来说是性能密集型的 URL，而忽略可能收到的任何答案，则会引发第 7 层 DoS 攻击。

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

不过，它在 Android 浏览器和 Chrome 移动设备上默认开启。

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

【问题讨论】：

我投票结束这个问题，因为它不是为了解决实际问题。它可能更适合programmers stackexchange。
What are the disadvantage(s) of using HTTP pipelining?的可能重复
我赞成投票。 我想知道答案！
rfc 没有说明服务器必须处理流水线，只是它不应该拒绝无效的查询。但是服务器只回答第一个查询是正确的，或者只是管道的一个子集（当然以正确的顺序）。

标签： google-chrome internet-explorer http firefox http-pipelining

【解决方案1】：

流水线被禁用的原因如下：

火狐：

坦率地说，更大的问题是线路阻塞及其对性能和稳健性的影响。简单的管道只会使性能变差。

铬：

启用流水线的选项已从 Chrome 中移除，因为存在已知的崩溃错误和已知的队列前端阻塞问题。还有大量的服务器和中间盒在启用流水线时表现不佳且不一致。在解决这些问题之前，建议不要使用流水线。目前这样做需要自定义构建 Chromium。

一般：

有缺陷的代理仍然很常见，它们会导致 Web 开发人员无法轻松预见和诊断的奇怪和不稳定的行为。

要正确实施流水线很复杂：正在传输的资源的大小、将使用的有效 RTT 以及有效带宽直接影响到流水线提供的改进。在不知道这些的情况下，重要的消息可能会延迟到不重要的消息之后。重要的概念甚至会在页面布局过程中演变！因此，HTTP 流水线仅在大多数情况下带来了边际改进。

流水线受制于HOL problem。

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 的风险。

参考文献

【讨论】：

现在我想知道为什么移动浏览器倾向于启用流水线！他们使用相同的代理、中间框并且应该有相同的 HoL 问题（但更糟糕的是，因为它使用了更高延迟的连接）。 HTTP/2 当然是未来的解决方案，但在那之前。
是否有任何移动浏览器记录了这种区别？我看过但没有发现任何东西，除了使用自己的代理的 Opera Mini，并且没有一个记录移动和桌面在流水线或 HTTP 一致性方面的差异。
很好的答案！ FWIW，bugzilla.mozilla.org/show_bug.cgi?id=264354#c65 简要介绍了移动设备与桌面设备的差异。

【解决方案2】：

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

【讨论】：

HTTP/2 本质上具有内置管道，这可能就是您所看到的。 stackoverflow.com/questions/34478967/… chromium.org/developers/design-documents/network-stack/… 表示“启用流水线的选项已从 Chrome 中删除”。
嗯，这不太可能，因为所讨论的服务器仅实现 HTTP/S 1.0 和 1.1。此外，HTTP/2 不会多路复用而不是管道，因此在 HTTP/2 中没有请求 AFAICT 的逻辑顺序。我没有检查纯 HTTP；也许这就是区别。
我应该补充一点，我维护了上述服务器，并且我最近修复了 HTTP 管道（这就是我观察管道请求计数的原因），因为我们的 Web 应用程序开始仅在 Chrome 上显示奇怪的故障。进一步的检查发现 Chrome 使用了流水线，而我们的已经坏了。 TBH 我非常惊讶，但我认为 Chrome 正在使用流水线（再次）。似乎（仅？）在快速连续的 fetch 请求中使用了流水线。