HTTP2如何解决线头阻塞(HOL)问题

HTTP2如何解决行头阻塞(HOL)问题？

这个问题在http1.1中非常频繁,但我听说HTTP2已经解决了这个问题.有人可以解释HTTP2究竟是如何解决这个问题的？

HTTP术语中的行阻塞主管通常指的是每个浏览器/客户端与服务器的连接数量有限,并且通过其中一个连接执行新请求必须等待之前完成的请求才能触发它关了.

行头请求阻止后续行.

HTTP/2通过引入多路复用解决了这个问题,因此您可以通过同一连接发出新请求,而无需等待先前的请求完成.

从理论上讲,HTTP/1.1的流水线操作也为HOL提供了一种方法,但它在实践中很难实现并且非常容易出错.这使得它直到今天才在网络上得到广泛使用.

然而,HTTP/2确实仍然受到另一种HOL的影响,即在TCP级别上.TCP流中的一个丢失数据包使所有流等待,直到重新发送和接收该数据包.这个HOL正在通过QUIC协议解决......

QUIC是在UDP上实现的"类TCP"协议,其中每个流是独立的,因此丢失的数据包仅停止丢失数据包所属的特定流,而其他流可以继续.

HTTP/1基本上是一个请求和响应协议:浏览器请求资源(无论是HTML页面,CSS文件,图像......等等),然后等待响应.在此期间,该连接无法执行任何其他操作 - 阻止等待此响应.

HTTP/1确实引入了流水线技术的概念,因此您可以在等待时发送更多请求.这应该会改进,因为现在发送请求没有延迟,服务器可以提前开始处理它们.响应必须仍然按照请求的顺序返回,因此它不是真正的多请求协议,但是是一个很好的改进(如果它有效 - 见下文).这在连接上引入了行头阻塞(HOLB)问题:如果第一个请求需要很长时间(例如,它需要进行数据库查找,然后进行一些其他密集处理来创建页面),那么所有其他请求排在后面排队,即使他们准备好了.事实上,事实上,HOLB已经是一个问题,即使没有流水线,因为浏览器必须排队请求,直到连接可以自由发送 - 流水线只是使连接级别上的问题更加明显.

除此之外,HTTP/1中的流水线技术从未得到支持,实施起来很复杂并且可能导致安全问题.因此,即使没有HOLB问题,它仍然没有那么有用.

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

另一方面,HTTP/2具有从一开始就烘焙的双向多路复用流的概念.我已经详细解释了它们的内容:多路复用在HTTP/2中意味着什么.这消除了HTTP/1请求的阻塞性质,引入了更好的,功能完备的,完全支持的流水线版本,甚至允许将部分响应与其他响应混合发送回来.所有这些共同解决了HOLB - 或者更准确地防止它成为一个问题.

应该注意的一点是,虽然这解决了HTTP HOLB,它仍然建立在TCP上,并且它有自己的TCP HOLB问题,在HTTP/2下可能会更糟,因为它是单个连接!如果单个TCP数据包丢失,则TCP连接必须请求重新发送并等待该数据包成功重新传输,然后才能处理后续TCP数据包 - 即使这些数据包用于其他HTTP/2流,理论上也是如此,在那段时间内处理(就像在HTTP/1下的真正单独连接下发生的那样).Google正在尝试在非保证UDP上使用HTTP/2而不是在一个名为QUIC的协议中保证TCP来解决此问题,而且这也正在被设置为Web标准(就像SPDY - 最初是Google实现 - 被标准化为HTTP/2).