HTTP3 (QUIC) 协议

为什么会有http3?

我们知道 http2 已经极大地提高了网络性能，但它还是有问题的。有一个问题是它无论无何也无法解决的，根源在于 http2 是基于 TCP 协议的，也就是说它无法解决TCP层面的弊端！

那么TCP层面的弊端是什么呢？
队头阻塞。啥？TCP 层面也有队头阻塞吗？不是HTTP队头阻塞吗？
没错，为什么这么说呢？因为TCP 协议在处理包时是有严格顺序的，为了保证可靠性，我们知道TCP每发一个包都会等待一个ACK，虽然有累计应答（SACK），但是当连续收到三个相同的 ACK 报文时，会在定时器过期之前，重传丢失的报文段。

也就是说当其中一个数据包遇到问题，TCP 连接需要等待这个包完成重传之后才能继续进行。虽然 http2 通过多个 stream，使得逻辑上一个 TCP 连接上的并行内容，进行多路数据的传输，然而这中间并没有关联的数据在TCP层面也是一前一后，前面 stream 2 的帧没有收到，后面 stream 1 的帧也会因此阻塞。这也就是TCP层面的队头阻塞问题。

HTTP3(QUIC) 协议

HTTP3 有一个关键的改变，那就是它把下层的 TCP换成了 UDP。
UDP你一定不陌生吧，它是一个简单、不可靠的传输协议，只是对 IP 协议的一层很薄的包装，和TCP 相比，它实际应用的较少，常用于直播，IM消息等。不过正是因为它简单，不需要建连和断连，通信成本低，也就非常灵活、高效，“可塑性”很强。

而因为 UDP 是无序的，包之间没有依赖关系，所以就从根本上解决了TCP队头阻塞。

所以，QUIC 就选定了 UDP，并在它之上把实现了 TCP 的那一套连接管理、拥塞窗口、流量控制等机制，打造出了一个全新的可靠传输协议。

QUIC 的特点

QUIC 基于 UDP，而 UDP 不需要三次握手，四次挥手，它是无连接的，所以天生就要比 TCP 快。

我们知道一条 TCP 连接是由四元组标识的，分别是源 IP、源端口、目的 IP、目的端口。一旦一个元素发生变化时，就需要断开重连，重新连接。在移动互联情况下，当手机信号不稳定或者在 WIFI 和 移动网络切换时，都会导致重连，从而进行再次的三次握手，导致一定的时延。
而QUIC不再以四元组标识，而是以一个 64 位的随机数作为 ID 来标识，而且 UDP 是无连接的，所以当 IP 或者端口变化的时候，只要 ID 不变，就不需要重新建立连接。

为了实现可靠性，QUIC 也有个序列号，是递增的。任何一个序列号的包只发送一次，下次就要加一了。即使丢包重传，序列号也会加一，并且QUIC 定义了一个 offset 概念。QUIC 既然是面向连接的，也就像 TCP 一样，是一个数据流，发送的数据在这个数据流里面有个偏移量 offset，可以通过 offset 查看数据发送到了哪里，这样只要这个 offset 的包没有来，就要重发；如果来了，按照 offset 拼接，还是能够拼成一个流。

为了防止网络上的中间设备识别协议的细节，QUIC 全面采用加密通信，而且QUIC 直接应用了 TLS1.3，顺便也就获得了 0-RTT、1-RTT 连接的好处。但 QUIC 并不是建立在 TLS 之上，而是内部“包含”了 TLS。它使用自己的帧“接管”了TLS 里的“记录”，握手消息、警报消息都不使用 TLS 记录，直接封装成 QUIC 的帧发送，省掉了一次开销。

TCP 的流量控制是通过滑动窗口协议。而QUIC 的流量控制也是通过 window_update，来告诉对端它可以接受的字节数。但是 QUIC 的窗口是适应自己的多路复用机制的，不但在一个连接上控制窗口，还在一个连接中的每个 stream 控制窗口。

HTTP3 没有指定默认的端口号，也就是说不一定非要在 UDP 的 80 或者 443 上提供 HTTP/3 服务。
HTTP3 通过 HTTP2 里的“扩展帧”了。浏览器需要先用 HTTP2 协议连接服务器，然后服务器可以在启动 HTTP2 连接后发送一个“Alt-Svc”帧，包含一个“h3=host:port”的字符串，告诉浏览器在另一个端点上提供等价的 HTTP/3 服务。浏览器收到“Alt-Svc”帧，会使用 QUIC 异步连接指定的端口，如果连接成功，就会断开HTTP2 连接，改用新的HTTP3 收发数据。

目前HTTP3的应用还很少，目前各大网站其实还是以HTTP1.1为主，但是HTTP3各种优良特性还需要实践证明，不过我依然很看好HTTP3，认为它是新时代的 TCP。