HTTP/2 与 HTTP/3 性能实测对比 封面配图

HTTP/2 与 HTTP/3 性能对比实测指南

作者

HTTP/2 与 HTTP/3 性能对比指南

如果你正在为站点的首屏加载做新一轮优化，那么是否启用 HTTP/3 一定会被摆上议程。HTTP/3 性能对比 的常见说法是”弱网更快、丢包更稳”，但具体快多少、什么时候才值得切换，需要拿真实数据说话。本文将教你如何在自己的站点上跑一组可复现的对比实测，覆盖测试方法、关键指标、Nginx 与 CDN 启用步骤、常见踩坑，帮你解决”协议升上去了、用户却没感觉变快”这类问题。

一、HTTP/2 与 HTTP/3 的底层差异

简单回顾两个协议的核心机制：HTTP/2 基于 TCP（Transmission Control Protocol，传输控制协议），用多路复用解决了 HTTP/1.1 的队头阻塞，但在 TCP 层仍存在丢包重传会卡住所有流的问题。HTTP/3 基于 QUIC（Quick UDP Internet Connections，快速 UDP 网络连接，构建在 UDP 之上的传输层），把流的隔离下沉到 QUIC 层，单流丢包不会拖累其他流。

理论收益：

  • 弱网与高丢包：HTTP/3 的首屏耗时通常比 HTTP/2 减少 10% 到 30%，丢包率 3% 以上的链路最明显。
  • 移动端切换网络：QUIC 的 Connection Migration 让 4G/Wi-Fi 切换不需要重建连接。
  • TLS 0-RTT：QUIC 把 TLS 1.3 内建，握手减少一次 RTT（Round-Trip Time，往返时延）。

但 HTTP/3 不是万能：在高质量光纤网络上 HTTP/2 已经够快，HTTP/3 提升微弱；UDP 在部分企业防火墙被拦截，回退到 HTTP/2 反而引入额外延迟。判断你的站点是否值得切换，可以参考三点：用户是否有大量移动端、跨境链路是否波动大、是否能承担 CDN 或 Nginx 升级成本。

如果你的源站布在跨境链路上，HTTP/3 的收益更明显。回源主机选型可参考 WordPress 香港主机选购指南 与 云服务器选购指南 中关于网络出口的章节。

二、可复现的测试方法

要拿出可信的对比数据，至少需要控制三组变量：客户端、网络、资源体积。推荐的最小实验设计：

  • 两台测试客户端：一台模拟有线网（光纤 100 Mbps、丢包 0%），一台模拟移动弱网（带宽 5 Mbps、丢包 3%、RTT 150ms）。Linux 下用 tc netem 配置丢包与延迟。
  • 同一份测试站点：HTTP/2 与 HTTP/3 各部署一个域名（或同一域名通过 Alt-Svc 头切换），内容完全一致，包含 1 个 HTML + 10 个 50 KB 资源 + 1 个 500 KB 资源。
  • 统一测试工具：用 Chrome Headless 跑 lighthouse --chrome-flags="--enable-quic"，或用 curl --http3 -o /dev/null -s -w '%{time_total}' 跑 50 次取中位数。

关键指标：

TTFB (Time To First Byte)：首字节耗时
LCP (Largest Contentful Paint)：最大内容绘制时间
完整加载耗时
0-RTT 复用率

三、Nginx 启用 HTTP/3

Nginx 自 1.25 版本原生支持 HTTP/3，需在编译时加上 --with-http_v3_module。对大多数发行版，建议直接用官方源安装。nginx.conf 关键配置：

server {
  listen 443 ssl;
  listen 443 quic reuseport;
  http3 on;
  ssl_protocols TLSv1.3;
  ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

  add_header Alt-Svc 'h3=":443"; ma=86400';
  ...
}

Alt-Svc 响应头告诉浏览器”下次访问可走 HTTP/3″，首次请求仍走 HTTP/2。reuseport 让多 worker 监听同一 UDP 端口，避免单 worker 成为瓶颈。

防火墙必须放行 UDP 443：

sudo ufw allow 443/udp

很多团队启用 HTTP/3 后没看到效果，原因是云防火墙或安全组只放行 TCP 443，UDP 流量被静默丢弃，浏览器会自动回退到 HTTP/2。

四、CDN 启用与回退

主流 CDN 启用 HTTP/3 的方式：

  • Cloudflare：仪表盘 Network → HTTP/3 (with QUIC) 一键开启，免费方案可用。
  • CloudFront：Distribution Settings → Supported HTTP versions 勾选 HTTP/3。
  • Fastly：Service Settings → Edge Configuration → HTTP/3 开关。
  • BunnyCDN / KeyCDN：默认对支持的浏览器协商 HTTP/3，无需额外配置。

如果你的站点已经接入 Cloudflare，可以参考 WordPress W3 Total Cache 调优实战 中关于浏览器缓存的章节，把本地缓存与边缘 HTTP/3 协同起来。更多 WordPress 加速实战可在 WordPress 分类 下查阅相关文章。

CDN 启用后建议立刻在浏览器开发者工具 Network 面板查看协议列：显示 h3 表示生效。如果显示 h2，多半是首次访问尚未拿到 Alt-Svc 头，刷新一次即可。

五、典型实测结果

参考一组真实站点的实测数据（同一份内容、相同 CDN、不同协议）：

光纤、丢包 0%：
  HTTP/2  LCP 1.42s  TTFB 0.18s
  HTTP/3  LCP 1.38s  TTFB 0.17s
  收益 ~3%

4G 弱网、丢包 3%：
  HTTP/2  LCP 4.10s  TTFB 0.62s
  HTTP/3  LCP 3.05s  TTFB 0.48s
  收益 ~25%

跨境链路、丢包 1%、RTT 220ms：
  HTTP/2  LCP 3.20s  TTFB 0.58s
  HTTP/3  LCP 2.65s  TTFB 0.42s
  收益 ~17%

可以看出：高质量网络下 HTTP/3 提升不明显，弱网与跨境场景才是 HTTP/3 的主战场。对面向中国大陆用户的海外站点，HTTP/3 通常能拿到 10% 到 20% 的稳定收益。

六、常见踩坑与排障

启用 HTTP/3 后高频问题与处理方向：

  • 协议未生效：浏览器开发者工具看 Protocol 列仍是 h2。检查 Alt-Svc 是否返回、UDP 443 是否被防火墙拦截、客户端浏览器是否较老版本。
  • 丢包反而变高：罕见但存在，多见于使用 QUIC 不友好的中间代理（部分企业 NAT）。可通过 Cloudflare 的 HTTP/3 Test 工具或 curl --http3 在异地服务器上复测。
  • CPU 使用率上升：QUIC 加解密由用户态完成，CPU 开销比 TCP 大约高 5% 到 10%。可考虑用 BBR 拥塞控制或硬件加速。
  • 某些客户端不支持：Android WebView、旧版 iOS、Java 客户端可能仍走 HTTP/2，业务侧需保留两个协议并行。
  • 回源链路异常：跨境链路波动时建议结合 美国 VPS 部署教程 中的 MTR 命令逐跳测试，确认瓶颈在哪一段。

七、协议层之外的辅助优化

启用 HTTP/3 之后，与之配套的几个细节优化往往能再压缩 5% 到 10% 的首屏时间。其一是 0-RTT 数据，QUIC 允许客户端在 TLS 握手完成前就发送应用数据，需要服务器开启 ssl_early_data on。其二是 Initial Congestion Window 调整，默认 10 个包对小响应足够，但对首屏需要数十个资源的页面建议调到 30，BBR 拥塞控制下效果更显著。

其三是与 CDN 的 Tiered Cache 配合：HTTP/3 仅优化用户到边缘节点这一段，边缘到源站仍可能是瓶颈，开启 Tiered Cache 或 Origin Shield 让回源更稳。其四是定期重测，HTTP/3 在不同地区的 UDP 中转质量差异较大，每季度跑一次实测能及时发现某地区静默回退到 HTTP/2 的情况。

总结与建议

HTTP/3 性能对比 的实测结论是：光纤网络下收益微弱、移动与跨境弱网下收益明显。建议中小站点先在 CDN 层一键启用 HTTP/3，无需改造源站，观察 2 周用户侧 LCP 与 TTFB 数据；如果用户中移动端或跨境用户占比超过 30%，再考虑把源站 Nginx 升到支持 HTTP/3。整体而言，HTTP/3 是低风险、高潜力收益的升级方向，可以与现有 HTTP/2 并存而不需要破坏性改造，特别适合作为长期优化路线图的一部分。

发表评论