QUIC

为什么要在 UDP 上重造传输层

TCP 深度嵌入操作系统内核，修改牵一发动全身，而且全球部署的中间件（防火墙、NAT、负载均衡）对 TCP 语义了如指掌，任何非标准修改都可能被它们干扰。QUIC 运行在用户空间，基于 UDP，可以快速迭代而不需要等待操作系统升级。

QUIC 自己实现了流量控制、可靠传输、拥塞控制，并把 TLS 1.3 握手合并进去，首次连接只需 1-RTT，会话恢复可达 0-RTT。更关键的是，QUIC 的多路复用在流级别处理，某个流的包丢了只阻塞那一个流，其他流继续正常传输，彻底解决了 HTTP/2 在 TCP 上遭遇的队头阻塞。[1]

部署现状

Google 在 2013 年开始在 Chrome 和自家服务器上灰度测试 gQUIC，到 2017 年 Google 搜索、YouTube 的相当一部分流量已走 QUIC。IETF 接手后重新设计了协议，与 gQUIC 不完全兼容，于 2021 年发布 RFC 9000。

Cloudflare 是最早大规模部署 IETF QUIC 的 CDN，Facebook（Meta）将 QUIC 用于移动 App 的 API 请求，测试显示在移动网络下延迟下降约 30%。目前 Chrome 约 40% 的流量走 HTTP/3（即 QUIC）。