HTTP2如何解决线路阻塞（HOL）问题

HTTP2如何解决线路阻塞（HOL）问题

这个问题在http1.1中非常常见，但我听说HTTP2已经解决了这个问题。有人能解释一下HTTP2是如何解决这个问题的吗？

HTTP行首阻塞 HTTP术语中的行首阻塞通常指的是，每个浏览器/客户端与服务器的连接数量有限，通过其中一个连接执行新请求必须等待这些连接完成，然后才能启动

行首请求阻止后续请求

HTTP/2通过引入多路复用来解决这个问题，这样您就可以在同一个连接上发出新的请求，而不必等待前面的请求完成

理论上，HTTP/1.1的流水线也提供了一种绕过HOL的方法，但在实践中实现起来很棘手，而且很容易出错。这使得它直到今天还没有在网络上得到广泛的应用

TCP线路头阻塞 然而，HTTP/2仍然受到另一种HOL的影响，即在TCP级别上。TCP流中的一个丢失的数据包使所有流等待，直到该数据包被重新发送和接收。此HOL正在通过QUIC协议解决

QUIC是一种通过UDP实现的“类似TCP”的协议，其中每个流都是独立的，因此丢失的数据包只停止丢失的数据包所属的特定流，而其他数据流可以继续

---

HTTP/3是通过QUIC而不是TCP和TLS完成的。

HTTP/1基本上是一种请求和响应协议：浏览器请求一个资源（可以是HTML页面、CSS文件、图像……等等），然后等待响应。在此期间，连接无法执行任何其他操作-它在等待此响应时被阻止

HTTP/1确实引入了管道化的概念，因此您可以在等待时发送更多请求。这应该会有所改善，因为现在发送请求没有延迟，服务器可以更早地开始处理它们。响应仍然必须按照请求的顺序返回，因此它不是一个真正的多请求协议，但是一个很好的改进（如果它有效-请参阅下文）。这在连接上引入了一个行首阻塞（head-of-line blocking，HOLB）问题：如果第一个请求需要很长时间（例如，它需要执行数据库查找，然后执行其他一些密集处理来创建页面），那么所有其他请求都会在它后面排队，即使它们已经准备就绪。事实上，说实话，即使没有管道，HOLB也已经是一个问题，因为浏览器无论如何都必须排队请求，直到连接可以自由发送它——管道只是让问题在连接级别上更加明显

除此之外，HTTP/1中的管道从未得到过那么好的支持，实现起来很复杂，可能会导致安全问题。因此，即使没有霍尔布问题，它仍然没有那么有用

为了解决所有这些问题，HTTP/1使用到服务器的多个连接（通常为6-8），因此它可以并行发送请求。这需要客户端和服务器端的努力和资源来进行设置和管理。此外，由于各种原因，TCP连接效率非常低，需要时间才能达到最高效率——到那时，您可能已经完成了繁重的工作，不再需要多个连接

另一方面，HTTP/2从一开始就具有双向多路传输流的概念。我有一个详细的解释，他们在这里：。这消除了HTTP/1请求的阻塞性质，引入了一个更好、功能齐全、完全受支持的流水线版本，甚至允许将部分响应与其他响应混合发送回。所有这些一起解决了HOLB——或者更准确地说，防止它成为一个问题

---

需要注意的一点是，虽然这解决了HTTP HOLB，但它仍然构建在TCP之上，并且它有自己的TCP HOLB问题，在HTTP/2下可能更糟糕，因为它是一个单一连接！如果单个TCP数据包丢失，则TCP连接必须请求重新发送该数据包，并等待该数据包成功重新传输，然后才能处理后续的TCP数据包-即使这些数据包是用于理论上可以在此期间处理的其他HTTP/2流（在HTTP/1下的真正独立连接下也会发生这种情况）。谷歌正在试验在一个名为QUIC的协议中使用HTTP/2，而不是在一个名为QUIC的协议中使用HTTP/2来解决这个问题，这也正在被设置为一个web标准（就像SPDY——最初是谷歌的一个实现——被标准化为HTTP/2）.

重复？SPDY和HTTP2是一样的吗？不确定SPDY！SPDY是HTTP/2的前身。协议非常相似，对于HOL问题，它们可以被同等对待。SPDY的答案也适用于HTTP/2。到目前为止，我在谷歌搜索后发现，SPDY是一个实验性协议，用于在现实中测试东西，以驱动forward在HTTP/2标准上的工作。SPDY从未用于在现实世界中测试数据。现在它也被弃用。这是正确的。但是，这里的HOL讨论也适用于HTTP/2。我认为即使使用QUIC，丢失的数据包也可能导致阻塞。HTTP/2头压缩基于动态字典（重复的标题替换为速记参考），这意味着如果请求#1在传输过程中丢失，有时服务器将无法解码请求#2的标头。QUIC上的HTTP称为HTTP/3，它使用QPACK，这是一种与HTTP/2的HPACK类似但不完全相同的自适应标头压缩。QPACK而不是HPACK的主要原因是确保它在h独立的流，不会导致HOLB。