【计算机网络】HTTP/3如何实现可靠传输？

首先要明确一个核心概念：HTTP/3 本身并不直接实现可靠传输，这个任务被下放给了其底层的传输协议------QUIC。

所以，问题就转化为：QUIC 协议是如何实现可靠传输的？

为了深刻理解 QUIC 的做法，我们最好先回顾一下 HTTP/1.1 和 HTTP/2 的处境，因为它们都基于 TCP。

在 HTTP/1.1/2 中：

这个经典组合非常成功，但也带来了几个固有的问题：

队头阻塞 ：TCP 保证字节流的按序交付。如果一个数据包在传输中丢失，即使后续的数据包已经到达接收端，接收端的 TCP 缓冲区也必须等待丢失的包重传成功后才能将数据递交给应用层。这就像只有一个车道的公路，一辆车抛锚，后面的车全都得等着。
建立连接延迟高：建立一个 TCP 连接需要"三次握手"，再加上 TLS 加密（通常是 TLS 1.2 及以上）又需要 1-2 个 RTT，总共需要 2-3 个 RTT 才能开始传输应用数据。
僵化的连接迁移：TCP 连接由四元组（源IP、源端口、目的IP、目的端口）标识。当你的网络从一个 WiFi 切换到 4G/5G（IP 地址改变）时，所有的 TCP 连接都会中断，需要重新建立。

QUIC 的目标就是解决这些问题，同时保留 TCP 的可靠性。

QUIC（Quick UDP Internet Connections）是一个基于 UDP 的传输协议。它把 TLS 1.3 作为其内在组成部分，并在用户空间（而非内核）实现了自己的可靠传输逻辑。其可靠传输的实现借鉴并改进了 TCP 的许多思想。

这是解决队头阻塞的关键。

TCP 是面向字节流的：应用层交给 TCP 的是一串无边界的数据流，TCP 将其拆分成多个报文段。接收端根据序列号将这些报文段重组回原始的数据流。
QUIC 是面向流的，但传输单位是包：QUIC 内部允许多个独立的流（Stream）同时存在。每个流有自己的序列号，保证其内部数据的顺序。但 QUIC 的封装和传输单元是一个个 QUIC 包。

如何解决队头阻塞？

当一个 QUIC 包丢失时，只有依赖于这个包中数据的流需要等待。其他流上的数据，只要它们所在的包没有被丢失，就可以继续被应用层读取和处理。

例子：一个 QUIC 包包含了 Stream 1 和 Stream 2 的数据。如果这个包丢了，Stream 1 和 Stream 2 都会暂停。另一个 QUIC 包只包含了 Stream 3 的数据，这个包成功到达，那么 Stream 3 的数据可以立即被处理，而不会被 Stream 1 或 2 的丢包所阻塞。

这相当于把"单车道公路"（TCP）升级为了"多车道高速公路"（QUIC）。一条车道发生事故，其他车道仍然可以通行。

QUIC 使用与 TCP 类似的超时重传（RTO） 和快速重传（Fast Retransmit） 机制，但有重要优化。

使用 Packet Number 而非 Sequence Number：
- TCP 的序列号是字节流的偏移量，重传的包使用相同的序列号。
- QUIC 的每个包都有一个单调递增且唯一的 Packet Number，即使是重传的包，其 Packet Number 也会是新的。
- 优势：
  1. 消除重传歧义：在 TCP 中，如果接收方对一个 ACK 的确认丢失，发送方可能会重传数据。当接收方收到重传包（相同序列号）和后续的新包时，它无法判断这个 ACK 是针对第一次传输还是重传的，这会影响 RTT 计算的准确性。QUIC 因为每个包的 PN 都不同，完全消除了这种歧义，能更精确地计算 RTT。
  2. 增强安全性：递增的 PN 使得流量加密模式更简单，减少了被攻击的风险。
显式确认与帧机制：
- QUIC 包内部包含一个或多个"帧"（Frame），真正的数据在 STREAM 帧里。
- 确认信息通过 ACK 帧 来传递。ACK 帧包含了接收到的最大 Packet Number 以及一个指示哪些包已被接收的"确认范围"信息。
- 这种基于帧的、结构化的确认方式比 TCP 的 SACK（选择性确认）更灵活和高效。

这是一个可选的、超越 TCP 的特性。QUIC 可以对一组包进行异或运算，生成一个 FEC 包。如果传输中只丢失了一个包，接收方可以利用收到的其他包和 FEC 包直接恢复出丢失的数据，而无需等待重传。这在一定程度的随机丢包环境下能显著降低延迟。但为了不增加过多开销，这个特性在实际部署中并不常用。

安全性是可靠传输不可分割的一部分。QUIC 将 TLS 1.3 深度集成：

握手即加密：QUIC 的连接建立和 TLS 握手是合并进行的。在第一个 RTT 里，客户端发送一个"初始"包（Initial Packet），其中就包含了 TLS 的 ClientHello 信息。服务端回复时也包含了 TLS 的 ServerHello 等信息。
减少延迟：得益于 TLS 1.3 的简洁性，QUIC 通常只需 1 RTT 就能完成连接建立（0-RTT 在某些情况下甚至可能），对比 TCP+TLS 的 2-3 RTT，延迟大大降低。
全面加密：除了少数用于建立连接的元数据，QUIC 的几乎所有报文头和信息（包括 ACK 帧、拥塞控制信号）都被加密。这防止了中间网络设备（如路由器、防火墙）的篡改和干扰，使得协议演进更加灵活。

QUIC 连接由一个 64 位的 Connection ID 来标识，而不是 IP 和端口。当你的设备切换网络导致 IP 地址变化时，只要能够提供相同的 Connection ID，QUIC 连接就可以继续保持，所有的流都不会中断。这对于移动设备体验至关重要。

QUIC 实现了与 TCP 类似的流量控制和拥塞控制。

流量控制：在流级别和连接级别都有，防止发送方过快地发送数据淹没接收方。
拥塞控制 ：QUIC 内置了 NewReno 等经典算法，但其设计使得拥塞控制算法可以在用户空间实现和更新，而无需等待操作系统内核升级。这意味着 Google 或 Cloudflare 可以快速地部署和测试新的拥塞控制算法（如 BBR），从而更好地适应不同的网络环境。