Fil*_*und 17 firefox internet-explorer google-chrome http http-pipelining
许多(如果不是全部)现代浏览器都没有使用流水线HTTP请求.理论上,流水线操作应该通过减少获取网站所需的往返时间来加快请求.
根据HTTP标准,所有服务器都必须处理流水线请求,因此问题不应该是服务器上缺乏支持.
我已经看到了一些安全问题,例如,如果客户端将尽可能多的流水线请求推送到服务器性能密集的URL,忽略可能收到的任何答案,则会出现第7层DoS攻击.
这将是在服务器上关闭流水线支持的原因(违反标准),但我找不到任何理由在客户端关闭它.
但是,默认情况下,它会在Android浏览器和Chrome移动设备上启用.
为什么Chrome,Firefox,IE,Opera和Safari在桌面(有时是移动)版本中没有使用流水线式HTTP请求？关闭它背后的理由是什么？
Pau*_*tte 10
由于以下原因,禁用管道传输:
坦率地说,更大的问题是线路阻塞及其对性能和稳健性的影响.天真的管道只会让性能变得更糟.
启用流水线操作的选项已从Chrome中删除,因为已知崩溃错误和已知的队列前阻塞问题.在启用流水线操作时,还有大量服务器和中间件行为严重且不一致.在解决这些问题之前,建议没有人使用流水线技术.目前这样做需要自定义构建Chromium.
一般来说:
Buggy代理仍然很常见,这些代码导致了Web开发人员无法轻易预见和诊断的奇怪和不稳定的行为.
流水线操作很难正确实现:传输的资源大小,将要使用的有效RTT以及有效带宽直接影响管道提供的改进.如果不了解这些,重要信息可能会延迟到不重要的信息之后.重要的概念甚至在页面布局中发展!因此,HTTP流水线操作仅在大多数情况下带来了微小的改进.
流水线操作受HOL问题的影响.
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的风险.
参考
| 归档时间： |
|
| 查看次数： |
5959 次 |
| 最近记录： |