QUIC 与 HTTP/3 抓包调试——UDP 流量仍然能看出问题

QUIC 和 HTTP/3 使数据包捕获分析变得更加困难，因为传输通过 UDP 运行，并且大多数应用程序数据都是加密的。熟悉 TCP 序列号的工程师可能会打开 QUIC 捕获并感觉有用的证据消失了。

它并没有消失。证据发生了变化。

QUIC 捕获可以显示什么

即使不解密应用程序数据，PCAP 通常也可以显示：

• 发送至端口 443 的客户端 UDP 数据包
• 服务器UDP响应
• 连接 ID
• 数据包大小
• 握手时间
• UDP 数据包级别的类似重传的行为
• 路径改变
• 回退到 TCP/TLS
• ICMP 错误
• 防火墙或 NAT 丢弃

如果客户端发送 QUIC 初始数据包而服务器从未响应，则问题可能是 UDP 阻塞、服务器策略、路由或中间件行为。如果 QUIC 失败并且客户端回退到 TCP/TLS，则该回退是重要的证据。

UDP 443 的阻止方式通常与 TCP 443 不同

许多网络允许 TCP 443 但限制 UDP 443。站点可能通过 HTTP/2 工作，但通过 HTTP/3 失败或降级。从用户方面来看，这可能看起来像是随机的浏览器缓慢或连接失败。

捕获问题：

• 客户端是否尝试使用 UDP 443？
• 服务器有回复吗？
• ICMP 报告无法访问吗？
• 客户端重试了吗？
• 客户端是否回退到 TCP 443？
• 回退之前损失了多少时间？

这就是数据包捕获如何证明“HTTPS 有效”与“HTTP/3 有效”不同的方式。

QUIC 时机仍然很重要

由于 QUIC 处理加密 UDP 数据包内的可靠性，因此经典 TCP 分析标签不直接应用。但数据包计时仍然很重要：

• 重复类似大小的数据包
• 服务器响应之前的间隙
• 丢失后爆发
• 数据包大小的变化
• 路径之间的迁移
• 回退之前的长时间延迟

即使不解密流，这些模式也可以支持网络诊断。

PCAP 手术适合的场合

PCAP 手术应该帮助工程师隔离相关的 UDP 流、保留时序并准备可共享的捕获。 QUIC 案例通常需要有关回退的上下文：

• DNS查询
• UDP 443 尝试
• 服务器响应或缺席
• TCP 443 回退
• 回退后的 TLS 握手
• 时间影响

如果捕获经过清理，连接 ID 和数据包大小可能仍然有用。仅当隐私政策要求时才删除它们，并记录更改的内容。

对于“QUIC 数据包捕获”、“HTTP/3 UDP 443 被阻止”或“QUIC 回退到 TCP”等搜索，答案不是放弃，因为有效负载是加密的。传输时间和后备路径仍然讲述了一个有用的故事。