HTTP/3：甩掉TCP、TLS 的包袱，构建高效网络
HTTP/2 到底有什么缺陷？
TCP 的队头阻塞
和 HTTP/1.1 一样，HTTP/2 依然是基于 TCP 协议的，而 TCP 最初就是为了单连接而设计的。两台计算机之间传输连接看成一个虚拟管道。传输过程中会将数据拆分为一个个按照顺序排列的数据包，这些数据包通过网络传输到接收端，接收端再按照顺序将这些数据包组合成原始数据。
如果有一个数据包因为网络故障或其他原因而丢包了，那么之后的数据都需要等待该数据的重新传输。
HTTP/2 正常是多个请求跑在一个TCP管道中的，如果其中任意一路数据流中出现了丢包的情况，那么就会阻塞该TCP连接中的所有请求。
TCP 建立连接的延时
网络延迟又称为 RTT（Round Trip Time）。我们把从浏览器发送一个数据包到服务器，再从服务器返回数据包到浏览器的整个往返时间称为 RTT。RTT 是反映网络性能的一个重要指标。
HTTP/1 和 HTTP/2 都是使用 TCP 协议来传输的。
- 在建立TCP连接的时候，需要和服务器进行三次握手来确认连接成功，也就是说需要在消耗完1.5RTT之后才能进行数据传输。
- 进行 TLS 连接，TLS 有两个版本——TLS1.2 和 TLS1.3，每个版本建立连接所花的时间不同，大致是需要 1～2 个 RTT，关于 HTTPS 我们到后面到安全模块再做详细介绍。
TCP 协议僵化
通过修改TCP协议来解决问题非常困难：
第一个是中间设备的僵化。互联网之间需要各处搭建各种设备，中间设备都有自己的目的。如果我们在客户端升级了 TCP 协议，但是当新协议的数据包经过这些中间设备时，它们可能不理解包的内容，于是这些数据就会被丢弃掉。
第二个是操作系统。因为 TCP 协议都是通过操作系统内核来实现的，应用程序只能使用不能修改。通常操作系统的更新都滞后于软件的更新，因此要想自由地更新内核中的 TCP 协议也是非常困难的。
QUIC 协议
HTTP/3 基于UDP实现了类似于TCP的多路数据流，传输可靠性等功能。
实现了类似 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 提供比较完整的支持。
Chrome 虽然在数年前就开始支持 Google 版本的 QUIC，但是这个版本的 QUIC 和官方的QUIC 存在着非常大的差异。 - 第二，部署 HTTP/3 也存在着非常大的问题。因为系统内核对 UDP 的优化远远没有达到TCP 的优化程度，这也是阻碍 QUIC 的一个重要原因。
- 第三，中间设备僵化的问题。这些设备对 UDP 的优化程度远远低于 TCP，据统计使用QUIC 协议时，大约有 3%～7% 的丢包率。
此文章为4月Day27学习笔记，内容来源于极客时间《浏览器原理》，学习使我快乐，每天进步一点点💪💪
服务器托管，北京服务器托管，服务器租用 http://www.fwqtg.net
