ARTICLE DETAIL

资讯详情

深耕网站建设、视觉设计与SEO优化的一线实战洞察。

HTTP/3 上线三个月,我把它关了:QUIC 不是所有场景都更快

HTTP/3 上线三个月,我把它关了:QUIC 不是所有场景都更快 去年年底 CDN 服务商来推 HTTP/3问我们要不要切。我当时的第一反应是那句老话这玩意儿现在能用了对方笑了说 Cloudflare、Google、Meta 早就全量跑 QUIC 了。我回去查了下数据切了。业务是 H5 页面加 App 内嵌 WebView弱网用户占比两成多理论上正是 HTTP/3 的主场。跑了三个月A/B 各 50%、相同 CDN 节点数据我全留着。今天把真实结果写出来——包括那些让 HR 想让我把这次实验从绩效里删掉的部分。先搞清楚 HTTP/3 到底改了什么不展开协议只说三个和性能直接相关的点一、握手从 2–3 个 RTT 压到 1 个重连甚至 0 个。TCP 要三 次握手再叠一层 TLS 握手数据才敢发。QUIC 把传输和加密合到一起首次 1-RTT老连接 0-RTT拿上次的会话恢复。二、真正干掉的是队头阻塞。HTTP/2 在一个 TCP 连接上多路复用看着很美可 TCP 要求按序交付——任何一个包丢了整条连接上所有流一起等重传。QUIC 在 UDP 之上自己实现流A 流丢包只卡 A 流B、C、D 照跑。三、连接迁移。TCP 连接是按 IP 端口认的WiFi 切 4GIP 一变连接就断。QUIC 用 connection ID 认连接网络切换时能续上。弱网和跨国这部分是真的赢先看好消息我们三个月的数据场景HTTP/2HTTP/3变化首屏 WiFi820ms760ms-7%首屏 4G1.4s1.1s-21%首屏 3G3.8s2.6s-32%首屏 跨国国内→新加坡2.1s1.5s-29%网络切换时请求失败率4.2%0.7%-83%视频起播 4G580ms410ms-29%规律很干净RTT 越大、丢包越多QUIC 的收益越大。跨国线路 RTT 300ms 以上一次握手省下的就是实打实的时间。视频起播快了 30%对应的秒开率涨了 12 个百分点这是能直接换成 GMV 的。顺带一个反直觉的观察iOS 用户的提升比 Android 明显。一是 Safari 的 QUIC 实现优化得早二是 iPhone 网络切换更频繁地铁、电梯、WiFi 自动断连接迁移的收益更容易被吃满。但高速网络上它反而更慢这是我想说的重点也是很多人不愿意提的部分。2024 年 ACM Web Conference 有篇论文叫《QUIC is not Quick Enough over Fast Internet》测出来的结论很扎眼在 1Gbps 链路上Chrome 里 QUIC 的吞吐比 HTTP/2 低最多 45.2%而且性能差距从500–600 Mbps就开始出现了。根因有两个都不是能靠调参解决的小毛病QUIC 的 ACK 处理在用户态。内核 TCP 那套 ACK 是几十年打磨出来的QUIC 得在用户态一条条处理包一多 CPU 先撑不住。内核缺 UDP GRO 支持。主流内核没给 UDP 做通用接收分段卸载大包收进来要靠软件合并CPU 直接起飞。翻译成人话QUIC 拿 CPU 换延迟。你网络好、CPU 紧这笔买卖可能是亏的。再加上一个信号采用率的曲线也不好看。不同统计口径差异很大Cloudflare 系一路测在 20% 上下另一些来源给到 30%但共同点是——增长明显放缓甚至比 2023 年的峰值回落了。回落的解释里高速网络下的吞吐劣势是排得上号的一条。落地时踩的四个坑坑一UDP 被中间网络丢掉。这是最大的坑。企业 NAT、老式路由器、部分运营商的 QoS 策略对 UDP 443 不友好大概 5%–10% 的网络环境有问题。QUIC 设计了 Happy Eyeballs 双栈竞速同时试 HTTP/2 和 HTTP/3谁先通用谁但浏览器实现有差异App 内嵌 WebView 的行为更不稳定。坑二负载均衡器不认 UDP。很多老 LB 只做 TCP 转发。我们一开始把 QUIC 流量直送 LVS结果连接迁移直接失效——LVS 按 IP 端口转发IP 一变就送到错的后端去了。要上 QUIC先确认你的 LB 支不支持 UDP 转发和 connection ID 哈希。坑三日志和监控得重做。TLS 跑在 QUIC 内部Nginx 日志里那些$ssl_protocol之类的字段对 HTTP/3 全是空的。0-RTT 命中率、连接迁移次数、每连接流数这些指标老的监控里根本没有。坑四CDN 计费口径会变。部分厂商的 UDP 流量单价比 TCP 贵 10%–20%。我们算过总账UDP 贵 15% × HTTP/3 占流量 60% ≈ 总成本上涨 9%。另外服务端是有代价的。有团队实测QUIC 协议栈跑在用户态没有内核 TCP 那么多年的优化加持服务端 CPU 15%、内存 20%后来上 BBR 加调大缓冲区才把 CPU 增幅压到 10% 以内。到底该不该切我的判断表你的情况建议移动端用户占比高、有跨国流量、有视频/直播立刻切收益明显电商、支付这类会话跨网络的场景切连接迁移能救命纯 PC Web、企业内网、稳定专线缓一缓收益小、复杂度涨高带宽大流量传输大文件、内网数据同步别切很可能更慢预算紧、流量小直接开 CDN 的 HTTP/3 开关别自建 Nginx要自建的话核心配置就两行listen 443 quic reuseport;加上add_header Alt-Svc h3:443; ma86400;同时保留 HTTP/2 监听——永远是并存不是替换。记得防火墙开 UDP 443这一步漏了的话前面全白干。最后HTTP/3 不是更快的协议它是一个在烂网络上表现更好的协议。它把互联网最难受的几个体验问题——弱网慢、切网断、跨国卡——实实在在缓解了代价是吃 CPU、运维复杂度上升。所以别听上了就起飞那套。先问自己三个问题用户是不是在移动端有没有跨国流量链路质量稳不稳三个都答是再切否则你很可能只是给自己加了一个新的故障面。我们最后没关 HTTP/3但把 UDP 流量切成了按场景灰度——App 内 WebView 和海外节点全量开内网和桌面端继续走 HTTP/2。把它当手术刀别当保健品。
返回列表