TLS 性能：QUIC 与 HTTP/3

HTTP/2 在单个 TCP 连接上复用多个流，解决了 HTTP/1.1 中每个连接的队头阻塞问题。然而，TCP 本身会在传输层造成队头阻塞：如果一个 TCP 数据段丢失，队列中位于其后的所有数据都必须等待重传，从而同时阻塞所有 HTTP/2 流。1% 的丢包率就可能使 HTTP/2 的性能低于使用多个连接的 HTTP/1.1。QUIC（快速 UDP 互联网连接）通过在 UDP 上实现多路复用流解决了这一问题：流级别的丢包恢复不会阻塞其他流。

QUIC 是一种构建在 UDP 之上的传输协议，由 Google 开发（2012—2015 年），并由 IETF 标准化为 RFC 9000（2021 年）。QUIC 将 TLS 1.3 集成在传输层中——QUIC 之上不存在单独的 TLS 握手；TLS 本身融入了 QUIC 握手。QUIC 提供以下功能：不会发生队头阻塞的多路复用流、连接迁移（切换网络时保持连接，例如从 WiFi 切换到 LTE）、用于重复连接的 0-RTT 连接建立，以及内置的丢包检测和拥塞控制。HTTP/3（RFC 9114）是在 QUIC 流之上实现的 HTTP 语义。

QUIC 握手将连接建立与 TLS 协商结合在一起。在第一批数据包中（按 QUIC 术语为 0 RTT），客户端发送包含 TLS ClientHello 的 Initial 数据包。服务器回复自己的 Initial（ServerHello）以及 Handshake 数据包（加密扩展、证书、Finished）。客户端发送 Handshake Finished，随后即可发送应用数据——这就是 1-RTT。对于 0-RTT 连接，客户端会使用从上一会话的恢复密钥派生出的密钥，在发送 ClientHello 的同时发送 0-RTT 数据包（应用数据），使缓存会话无需额外的往返通信即可建立连接。

QUIC 使用四种不同的加密级别，分别对应 TLS 密钥调度的不同阶段：Initial（使用已知常量密钥的 QUIC 派生 AEAD——可提供完整性，但无法为复杂攻击者提供机密性保护）、Handshake（从 TLS handshake_secret 派生——为 TLS 握手消息提供机密性）、0-RTT（从上一会话的 early_secret 派生——加密 0-RTT 应用数据）以及 1-RTT（从 TLS master_secret 派生——加密所有应用数据）。QUIC 标头会被部分加密：数据包编号和载荷会被加密，但部分路由信息（Connection ID）仍对负载均衡器可见。

QUIC 连接通过 Connection ID（CID）而不是四元组（源 IP、源端口、目标 IP、目标端口）来标识。这使连接能够经受网络变化：移动客户端从 WiFi 切换到 LTE 时，IP 地址会改变，但 CID 保持不变。客户端在新路径上发送 PATH_CHALLENGE 帧；服务器使用 PATH_RESPONSE 回复，以验证新地址。连接无需重新协商即可无缝继续。TCP 无法支持这一点——TCP 连接绑定到其四元组，网络变化时必须重新建立，因此需要新的 TLS 握手。QUIC 迁移能显著提升移动用户感知到的性能。

HTTP/3 将 HTTP 语义映射到 QUIC 流。每个 HTTP 请求—响应对都占用一个独立的双向 QUIC 流。QUIC 流彼此独立：流 3 上的丢包不会阻塞流 7。HTTP/3 使用 QPACK 进行标头压缩（取代 HTTP/2 的 HPACK）；QPACK 经过重新设计，无需按序传送即可工作。两个专用的单向控制流承载设置以及解码器/编码器指令。HTTP/3 中的服务器推送使用推送流（单向）。总体而言，在丢包条件下（移动网络、拥塞路径），HTTP/3 的性能优势最为明显，因为此时 TCP 的队头阻塞危害最大。

现实场景中的 QUIC 和 HTTP/3 性能测量显示，结果取决于网络条件，情况各不相同。在高质量网络上（低延迟、低丢包率），HTTP/3 和 HTTP/2 的表现相近——QUIC 的开销（更大的标头、UDP 处理开销）甚至可能使 HTTP/3 略慢。在高丢包率网络上（丢包率超过 1%，移动网络和卫星网络中很常见），HTTP/3 的性能会显著优于 HTTP/2。Google 报告称，YouTube 切换到 QUIC 后，重新缓冲减少了 7%—8%。Facebook（Meta）报告称，Instagram 信息流通过 QUIC 传输时，请求延迟改善了 7%—15%。这些收益在尾延迟（p95、p99）中最为明显，因为 TCP 重传造成的停顿对尾延迟影响最大。

QUIC 的负载均衡比 TCP 更复杂，因为 QUIC 基于 UDP，而无状态 UDP 负载均衡器无法实现连接亲和性。IETF 草案 draft-ietf-quic-load-balancers 定义了一种解决方案：服务器将路由信息编码到 Connection ID 中，使负载均衡器无需跟踪每个连接的状态，就能将同一连接的数据包路由到同一台服务器。Connection ID 使用负载均衡器与服务器之间共享的密钥，携带经过加密的服务器 ID。Cloudflare、Fastly 和 Nginx 都实现了这种方案的不同变体。NAT 穿透是另一个需要考虑的问题：QUIC 连接必须经受 NAT 重新绑定，这由连接迁移机制处理。

主要 CDN 已大规模部署 QUIC 和 HTTP/3。Cloudflare 自 2019 年起提供 HTTP/3 服务，并报告称，在客户端和服务器都支持 QUIC 的情况下，约 20% 的流量使用 QUIC。Fastly、Akamai 和 AWS CloudFront 在其边缘节点支持 HTTP/3。Google 自有基础设施（Search、YouTube、Gmail）自 2013 年起就在内部使用 QUIC，并向公众提供 HTTP/3。CDN 部署受益于 QUIC 的 0-RTT 会话恢复：回访用户可以更快建立连接，而连接迁移则能改善内容传输期间移动用户在接入点之间漫游时的性能。

QUIC 基于 UDP 的设计带来了特定的安全注意事项。放大攻击：攻击者可以伪造源 IP 并发送少量 Initial 数据包，使服务器向受害者发送大量 Handshake 响应——QUIC 通过限制服务器响应量来缓解这一问题：在地址验证完成之前（通过 RETRY 机制），响应量最多为已接收数据的 3 倍。连接泛洪：QUIC 服务器必须限制来自同一 IP 的新连接尝试速率。通过在受密码保护的握手中包含版本号，可以防止版本协商攻击。QUIC 的内置加密意味着检查设备无法分析 QUIC 载荷，除非它位于服务器所在的通信路径上并拥有服务器证书；与可被检查的 TCP 流量相比，这提高了隐私性。

部署 HTTP/3 需要：(1) 支持 QUIC 的服务器（nginx 1.25+、Caddy、HAProxy 2.6+、LiteSpeed，或通过 quic-go、aioquic、ngtcp2 库在应用层实现）。(2) 在防火墙上开放 UDP 443 端口——许多企业防火墙会阻止 UDP 443，使 QUIC 回退到 TCP/TLS。(3) 通过 Alt-Svc 响应标头公布 HTTP/3 支持：Alt-Svc: h3=":443"; ma=86400，促使 HTTP/2 客户端升级。(4) 支持 QUIC 的负载均衡器，或 L4 UDP 直通。(5) 监控 QUIC 特有的指标：连接迁移事件、0-RTT 接受率、协议回退率。采用渐进式发布并回退到 HTTPS，对不支持 QUIC 的客户端是透明的。

QUIC 在 UDP 之上的传输层集成 TLS 1.3，通过按流独立进行丢包恢复，消除了 TCP 队头阻塞。Connection ID 支持连接在网络变化时迁移，无需重新协商。HTTP/3 使用 QPACK 标头压缩，将 HTTP 映射到 QUIC 流。0-RTT 连接恢复会重新使用 TLS 会话密钥。QUIC 在丢包环境（移动网络、拥塞网络）中的性能优势最为显著。QUIC 负载均衡需要将服务器路由信息编码到 Connection ID 中。部署需要 UDP 443、支持 QUIC 的服务器，以及用于公布协议支持的 Alt-Svc 标头。