HTTP/2的⼀个核⼼特性是使⽤了多路复⽤技术，因此它可以通过⼀个TCP连接来发送多个URL请求。多路复 ⽤技术能充分利⽤带宽，最⼤限度规避了TCP的慢启动所带来的问题，同时还实现了头部压缩、服务器推送 等功能，使得⻚⾯资源的传输速度得到了⼤幅提升。
HTTP/3的出现也是为了解决HTTP/2的缺陷
TCP的队头阻塞
HTTP/2依然是基于TCP协议的，⽽ TCP最初就是为了单连接⽽设计的。
分析下HTTP/1.1协议栈中TCP是如何传输数据的。
从⼀端发送给另外⼀端的数据会被拆分为⼀个个按照顺序排列的数据包，这些数据包通 过⽹络传输到了接收端，接收端再按照顺序将这些数据包组合成原始数据，这样就完成了数据传输。
如果在数据传输的过程中，有⼀个数据因为⽹络故障或者其他原因⽽丢包了，那么整个TCP的连接就 会处于暂停状态，需要等待丢失的数据包被重新传输过来。
可以把TCP连接看成是⼀个按照顺序传输数据 的管道，管道中的任意⼀个数据丢失了，那之后的数据都需要等待该数据的重新传输。
我们就把在TCP传输过程中，由于单个数据包的丢失⽽造成的阻塞称为TCP上的队头阻塞。
HTTP/2的传输多路请求
在HTTP/2中，多个请求是跑在⼀个TCP管道中的，如果其中任意⼀路数据流中出现了 丢包的情况，那么就会阻塞该TCP连接中的所有请求。
这不同于HTTP/1.1，使⽤HTTP/1.1时，浏览器为每 个域名开启了6个TCP连接，如果其中的1个TCP连接发⽣了队头阻塞，那么其他的5个连接依然可以继续传 输数据。
所以随着丢包率的增加，HTTP/2的传输效率也会越来越差。甚至当丢包率超过一定值时，HTTP/1.1的传输效率反⽽⽐HTTP/2表现得更好。
TCP建⽴连接的延时
TCP的握⼿过程也是影响传输效率的⼀个重要因素。
⽹络延迟⼜称为RTT（Round Trip Time）。我们把从浏览器发送⼀个数据包到服务器，再从服务 器返回数据包到浏览器的整个往返时间称为RTT。
RTT是反映⽹络性能的⼀个重要指标
那建⽴TCP连接时，需要花费多少个RTT呢？
HTTP/1和HTTP/2都是使⽤TCP协议来传输的，⽽如果使⽤HTTPS的话，还需要使⽤TLS协议进⾏ 安全传输，⽽使⽤TLS也需要⼀个握⼿过程，这样就需要有两个握⼿延迟过程。
- 在建⽴TCP连接的时候，需要和服务器进⾏三次握⼿来确认连接成功，也就是说需要在消耗完1.5个RTT 之后才能进⾏数据传输。
- 进⾏TLS连接，TLS有两个版本⸺TLS1.2和TLS1.3，每个版本建⽴连接所花的时间不同，⼤致是需要1〜 2个RTT
在传输数据之前，我们需要花掉3〜4个RTT。如果浏览器和服务器的物理距离较近，那么1个RTT的 时间可能在10毫秒以内，也就是说总共要消耗掉30〜40毫秒。这个时间也许⽤⼾还可以接受，但如果服务 器相隔较远，那么1个RTT就可能需要100毫秒以上了，这种情况下整个握⼿过程需要300〜400毫秒，这时 ⽤⼾就能明显地感受到“慢”了。
TCP协议僵化
现在知道了TCP协议存在队头阻塞和建⽴连接延迟等缺点，那我们是不是可以通过改进TCP协议来解决 这些问题呢？
答案是：⾮常困难。之所以这样，主要有两个原因。
第⼀个是中间设备的僵化。
互联⽹是由多个⽹络互联的⽹状结构，为了能够保障互联⽹的正常⼯作，我们需要在互联⽹的各处搭建各种设 备，这些设备就被称为中间设备。
这些中间设备有很多种类型，并且每种设备都有⾃⼰的⽬的，这些设备包括了路由器、防⽕墙、NAT、交换 机等。它们通常依赖⼀些很少升级的软件，这些软件使⽤了⼤量的TCP特性，这些功能被设置之后就很少更 新了。
所以，如果我们在客⼾端升级了TCP协议，但是当新协议的数据包经过这些中间设备时，它们可能不理解包 的内容，于是这些数据就会被丢弃掉。这就是中间设备僵化，它是阻碍TCP更新的⼀⼤障碍。
操作系统也是导致TCP协议僵化的另外⼀个原因。
因为TCP协议都是通过操作系统内 核来实现的，应⽤程序只能使⽤不能修改。通常操作系统的更新都滞后于软件的更新，因此要想⾃由地更新 内核中的TCP协议也是⾮常困难的。
QUIC协议
HTTP/2存在⼀些⽐较严重的与TCP协议相关的缺陷，但由于TCP协议僵化，我们⼏乎不可能通过修改TCP协 议⾃⾝来解决这些问题，那么解决问题的思路是绕过TCP协议，发明⼀个TCP和UDP之外的新的传输协议。
但是这也⾯临着和修改TCP⼀样的挑战，因为中间设备的僵化，这些设备只认TCP和UDP，如果采⽤了新的 协议，新协议在这些设备同样不被很好地⽀持。
因此，HTTP/3选择了⼀个折衷的⽅法⸺UDP协议，基于UDP实现了类似于 TCP的多路数据流、传输可靠性等功能，我们把这套功能称为QUIC协议。
通过上图我们可以看出，HTTP/3中的QUIC协议集合了以下⼏点功能。
- 实现了类似TCP的流量控制、传输可靠性的功能。虽然UDP不提供可靠性的传输，但QUIC在UDP的基础 之上增加了⼀层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他⼀些TCP中存在的特 性。
- 集成了TLS加密功能。 ⽬前QUIC使⽤的是TLS1.3，相较于早期版本TLS1.3有更多的优点，其中最重要的 ⼀点是减少了握⼿所花费的RTT个数。
- 实现了HTTP/2中的多路复⽤功能。和TCP不同，QUIC实现了在同⼀物理连接上可以有多个独⽴的逻辑数 据流（如下图）。实现了数据流的单独传输，就解决了TCP中队头阻塞的问题。
- 实现了快速握⼿功能。由于QUIC是基于UDP的，所以QUIC可以实现使⽤0-RTT或者1-RTT来建⽴连接， 这意味着QUIC可以⽤最快的速度来发送和接收数据，这样可以⼤⼤提升⾸次打开⻚⾯的速度。
HTTP/3的挑战
挑战主要来⾃于以下三个⽅⾯
第⼀，从⽬前的情况来看，服务器和浏览器端都没有对HTTP/3提供⽐较完整的⽀持。
第⼆，部署HTTP/3也存在着⾮常⼤的问题。因为系统内核对UDP的优化远远没有达到TCP的优化程度，这 也是阻碍QUIC的⼀个重要原因。
第三，中间设备僵化的问题。这些设备对UDP的优化程度远远低于TCP，据统计使⽤QUIC协议时，⼤约有 3%〜7%的丢包率。
