QUIC 生产调优实录：BBR、0-RTT 和连接迁移，每个都有代价

QUIC 和 HTTP/3 在 2026 年的生产部署已经越过了“要不要上”的阶段。阿里云 ALB 的 QUIC 监听可以通过 AlbConfig 开启，支持自动发现证书和 Secret 证书，文档明确说明在移动网络等不稳定环境下 HTTP/3 能显著减少重传和通信延迟。一个生产就绪的 PR 给出了 HTTP/3 从实验走向生产需要实现的五个验收项：BBR 拥塞控制、连接迁移、0-RTT、HTTP/2 回退和每请求性能指标，预期的收益是 30% 到 50% 的延迟降低和更好的移动网络表现。

这些能力每一个都有真实的工程代价，而不是配置开关。

BBR 拥塞控制在 QUIC 实现里需要显式设置 cc_algo，同时要调整流控窗口——默认的流控如果太小，BBR 的带宽探测会被窗口卡住，看不到应有的收益。PR 里把连接级流控调到 10 MB、流级调到 1 MB，这不是一个可以忽略的默认值。

0-RTT 允许客户端在恢复连接时立即发送应用数据，不需要等待完整握手。但 0-RTT 数据有重放风险：服务端必须确保 0-RTT 请求是幂等的，或者拒绝非幂等操作在 0-RTT 上执行。PR 里用 SSL_set_quic_early_data_enabled 控制开启，并在 metrics 里记录 zero_rtt_used，这意味着团队需要有能力按连接观察 0-RTT 的使用情况，而不是假设它“总是更快”。

连接迁移是 QUIC 相比 TCP 的结构性优势：客户端 IP 变化时，连接可以基于 Connection ID 而不是四元组继续存活。实现需要在 handler 里维护 CID 到 session 的二级索引，在路径迁移时重新绑定 session 并记录 migration_count。但连接迁移不是免费的：迁移后的路径可能拥塞窗口更小、RTT 更长，服务端需要决定是否重置拥塞状态，而不是简单地“续上”。

HTTP/2 回退是最容易被低估的一项。QUIC 在部分网络环境里会被 UDP 阻断或限速，如果服务端只提供 HTTP/3，这些客户端会直接失败。PR 的实现是：对 QUIC 握手失败的客户端 IP 记录失败次数，超过阈值后在 Alt-Svc 里抑制 h3 广告，让客户端回退到 HTTP/2；失败计数有恢复窗口，过期后重新尝试 QUIC。这意味着 HTTP/3 的生产部署不是“开启 QUIC 就完事”，而是需要一套按客户端健康状态动态调整广告策略的机制。

一个务实的上线顺序是：先同时提供 HTTP/2 和 HTTP/3，用 Alt-Svc 广告 h3 但不强制；观察 QUIC 握手失败率和回退比例，校准失败阈值和恢复窗口；在确认客户端池健康之后，再考虑对支持的客户端优先 h3。性能指标要按连接维度采集——握手耗时、首字节延迟、0-RTT 使用率、迁移次数——而不是只看全局平均。QUIC 的收益在移动和弱网场景最明显，在稳定的数据中心内部，HTTP/2 可能仍然是更简单的选择。