HTTP/2自在2015年发布到今天已经快10年了，HTTP/2的一大亮点就是解决了HTTP/1.1在应用层层面的队头阻塞(Head-of-Line blocking)问题。下面我将阐述一下什么HTTP/1.1面临怎样的对头阻塞问题，以及HTTP/2是如何缓解这一问题的。
文章导航
一、什么是队头阻塞
很难给队头阻塞下一个准确的定义，不同场景下的对头阻塞也会有所不同。我们可以简单的描述一下队头阻塞。
当一个一个缓慢的信号阻止了后面的信号继续前进，我们就认为发生了队头阻塞。
用生活中的例子来说，当你在超市排队结账时，前面的顾客如果买了很多东西，他在结账时便会花费更多的时间，那么所有在这位顾客后面的人都会被“阻塞”住。
二、HTTP/1.1面临的队头阻塞问题
HTTP/1.1最初被设计用来传输文本，如下图所示：
在上面的例子中，我们想要使用HTTP请求来传输一个js文本，我们可以看见http协议只是在原来的文本基础上添加了一些文本的“消息头”。接下来“消息头+消息体”被传输给了TCP层。我们来考虑一下传输多个文件的情景。
如上图，我们后面又开始传输了一个css文件，我们可以假定js文件比css文件大了很多。在传输的过程中，虽然css文件能够很快的被发送出去，但是由于有js文件在前面阻塞住，也只能等到全部的js文件发送完成后才开始发送css文件，这就造成了队头阻塞。
三、HTTP/2 如何解决
在HTTP/2中，使用流来传输数据，相较于HTTP/1.1能够实现多路复用。
流 (Stream)：HTTP/2 使用流来管理并发通信，每个流都有一个唯一的标识符。一个连接可以有多个流，每个流都可以独立地发送和接收数据。
帧 (Frame)：数据被分割成较小的帧，每个帧都包含其所属流的标识符。这样，来自不同流的帧可以交织在一起发送，而不必按顺序等待前一个请求完成。
每个请求/响应对通过独立的流进行管理，帧可以交错发送，客户端和服务器都可以同时处理多个流，不必等待某个流完成才能开始下一个。
三、HTTP/3
HTTP/2解决了在HTTP协议层面的队头阻塞问题，但是队头阻塞在其使用的传输层协议TCP中依然存在。后面提出的HTTP/3协议采用UDP来实现的QUIC来解决了这一问题。
HTTP/3 基于 QUIC 协议，而不是 TCP。QUIC 是由 Google 开发的一种新的传输层协议，使用 UDP 来实现具有 TCP 类似的可靠性和控制流量特性，但加入了更多的优化以解决 TCP 的固有问题。
延展阅读：
CAP理论与Raft协议如何在分布式系统中确保一致性和可用性？
咨询方案
获取更多方案详情
