HTTP/3 与 QUIC：为什么你的网站该考虑它了

如果你看过浏览器开发者工具的协议列，可能会发现有些请求标着 h3。这不是新标准里的噱头，而是 HTTP/3 在真实网络中的落地。

一、HTTP/2 的遗留问题

HTTP/2 用一条 TCP 连接承载多个流，看似解决了 HTTP/1.1 的队头阻塞。但它只在应用层解决了问题：TCP 本身仍然要求字节按序到达。

只要有一个 TCP 段丢了，后面所有流都要等它重传。丢包率越高，HTTP/2 的多路复用反而越吃亏——这就是所谓“TCP 层队头阻塞”。

此外，TCP + TLS 的握手需要多个往返：TCP 三次握手、TLS 1.3 一到两个往返。对跨洲访问来说，这几次往返就是几百毫秒。

二、QUIC 做了什么

QUIC 把可靠传输、拥塞控制、加密握手全部搬到了 UDP 之上，并内置 TLS 1.3：

• 0-RTT / 1-RTT 建连：复用时首包就能带数据
• 流级独立：一条流丢包不阻塞其他流
• 连接迁移：手机从 Wi-Fi 切到 4G，连接 ID 不变，会话不断
• 用户态实现：升级拥塞控制算法不再需要等操作系统

代价是：UDP 在很多企业网络和部分运营商链路上会被限速甚至封禁；服务端要在用户态处理加密，CPU 成本高于内核态 TCP。

三、什么情况下收益明显

• 用户以移动端为主、网络切换频繁
• 跨地域访问多、RTT 高
• 页面资源多、并发请求密集
• 丢包率不稳定（弱网）

如果站点只有一个机房、用户集中在同城、页面又很轻，HTTP/3 的收益可能被噪声淹没。

四、上线时的实际检查项

1. 确认 UDP 443 可达：防火墙、安全组、云厂商的四层防护都要放行
2. 保留 HTTP/2 回退：Alt-Svc 宣告，客户端不支持时自动降级
3. 观察握手失败率：部分网络会静默丢弃 UDP，需要监控而不是假设
4. 注意 0-RTT 的重放风险：非幂等请求不要走 0-RTT
5. CDN 优先：边缘节点通常已经支持，比自建更省事

五、别把它当成银弹

协议升级不会挽救一个本身很慢的后端。TTFB 的大头往往在数据库和渲染，而不是握手。先把缓存、慢查询、首屏资源处理好，再考虑 HTTP/3，顺序不会错。

但在移动互联网占比越来越高的今天，把 QUIC 作为“默认开启、可回退”的能力，已经是合理的默认值。