协议分析

QUIC 观测入门：为什么 UDP/443 让网络测量更复杂

从 QUIC、HTTP/3、UDP/443 和被动观测出发，解释现代应用链路为什么不能只靠传统 TCP 测试。

2026/5/13 #QUIC#HTTP3#Network#Methodology

QUIC 改变了测量方式

过去分析网站链路，TCP 握手、TLS 握手、SNI、连接复用都比较容易分层观察。QUIC 把传输和加密更紧密地结合在 UDP/443 上，HTTP/3 又进一步改变了浏览器和 CDN 的行为。

结果是：传统 TCP ping、三次握手耗时和 TLS 指标，不能完整代表用户体验。

国外研究为什么关注 QUIC backscatter

APNIC 关于 QUIC backscatter 的文章展示了一个有意思的方向：即使不主动探测目标，仅观察无意到达的 QUIC 流量，也能推断大型平台的部署方式。这说明 QUIC 已经足够普及，也说明传统“只看 TCP”的观测方式会漏掉越来越多信息。

对 VPS 和网站运营者来说，QUIC 的问题更直接：很多 CDN 默认支持 HTTP/3，浏览器也会自动尝试。你以为用户在走 TCP/443，实际可能已经走 UDP/443。如果机房或防火墙对 UDP 策略很差，网站体验会出现难以解释的波动。

国外运维讨论里常见的建议是：HTTP/3 应该被单独监控。不要把 HTTPS 可用性等同于 HTTP/3 可用性。

防火墙和安全组检查

开启 HTTP/3 前，检查：

  • 云安全组是否允许 UDP/443。
  • 主机防火墙是否允许 UDP/443。
  • 反向代理是否支持 HTTP/3。
  • CDN 是否已经向客户端发布 Alt-Svc。
  • 监控是否能区分 HTTP/2 和 HTTP/3。

Nginx、Caddy、Cloudflare、Fastly 等方案的默认行为不完全一致。尤其是通过 CDN 开启 HTTP/3 时，源站可能仍是 HTTP/2 回源，这会让排障路径变复杂。

用户侧问题怎么判断

如果用户反馈“网页偶尔打不开”，可以让他分别测试：

curl --http2 -I https://example.com/
curl --http3 -I https://example.com/

如果 HTTP/2 正常、HTTP/3 失败，优先怀疑 UDP/443、CDN 边缘、运营商 UDP 策略或客户端 QUIC 实现。

如果两者都慢，再回到普通 TCP、DNS、TLS 和服务端性能排查。

VPS 测试里的误判

常见误判包括：

  • TCP 443 很稳，就认为 HTTP/3 一定稳。
  • ICMP 丢包高，就认为 QUIC 一定差。
  • UDP 被限速，却只做 TCP speedtest。
  • 防火墙允许 443/TCP，但忘了 443/UDP。

QUIC 对丢包和路径变化有自己的恢复机制，但如果 UDP 被运营商、机房或防火墙策略限制，体验会明显下降。

应该怎么测

最简单的方式是同时测 TCP 与 HTTP/3：

curl --http1.1 -w "%{time_connect} %{time_starttransfer}\n" -o NUL -s https://example.com/
curl --http2 -w "%{time_connect} %{time_starttransfer}\n" -o NUL -s https://example.com/
curl --http3 -w "%{time_connect} %{time_starttransfer}\n" -o NUL -s https://example.com/

如果本地 curl 没有 HTTP/3 支持，可以用浏览器开发者工具、qlog、quiche、ngtcp2 或在线测试服务辅助。

对建站和 CDN 的影响

开启 HTTP/3 前，建议确认：

  1. 源站或 CDN 是否真的支持 QUIC。
  2. UDP/443 是否被安全组放行。
  3. Anycast CDN 在目标地区的 UDP 质量。
  4. 回源是否仍走 TCP，是否会成为瓶颈。
  5. 监控系统是否能区分 TCP 与 QUIC 错误。

如果你的用户主要来自网络环境复杂的地区，HTTP/3 应该灰度开启，并保留 HTTP/2 回退。

结论

QUIC 让应用层更快，也让网络测量更难。未来 VPS 和线路测评不能只给 TCP speedtest，需要把 UDP/443、HTTP/3、丢包恢复和 CDN 边缘调度一起纳入观察。

参考来源