摘要

  • QUIC Version Negotiation 数据包携带一份未受密码学保护的版本列表，表示发送方声称愿意接受哪些版本。
  • 连接 ID 的回显只能在有限程度上表明发送方看到了客户端 Initial，不能认证指定服务器或其生产策略。
  • 可用的运营回执必须把原始数据包、客户端后续选择以及握手中经过认证的 Version Information 连成一条证据链。

兼容性面板在某个边缘地址旁列出三个 QUIC 版本。依据只有一段抓包：客户端尝试一个版本，收到 Version Negotiation，响应中列出三个值。面板随即把它们标成“服务器已支持”。这个结论比抓包本身多走了一步。

RFC 9000 §6.1 规定，当客户端选择的版本不可接受时，服务器以 Version Negotiation 响应，并列出它愿意接受的版本。服务器无需保留连接状态即可生成响应，也可以限制响应数量。因此，没有看到响应并不等于得到一份完整的“不支持”清单。

数据包格式只建立了狭窄关联。RFC 9000 §17.2.1 要求 Version 字段为零，响应的 DCID 复制客户端 SCID，响应 SCID 则复制 Initial 的 DCID。规范称，这种回显使客户端在一定程度上确信发送方观察过 Initial。其余部分是一组 32 位版本值。

观察过 Initial 不等于通过服务身份认证。RFC 9000 §12.1 明确指出，Version Negotiation 数据包没有密码学保护。路径上的系统能够看到需要回显的连接 ID。原始响应不携带 TLS 证书、Finished 验证或经过认证的传输参数，不能把版本声明绑定到指定对端。

客户端规则排除了一些明显歧义，却没有提高证明等级。RFC 9000 §6.2 要求，仅支持 QUIC v1 的客户端收到符合条件的 Version Negotiation 后必须放弃当前连接尝试，但有两个例外：若此前已成功处理其他数据包，应丢弃该包；若列表包含客户端原先选择的版本，也应丢弃。这些规则有助于抵御直白的注入或过期响应，但不会把剩余列表变成签名策略文件。

更强的证据位于握手内部。RFC 9368 §3 定义包含 Chosen Version 和 Available Versions 的 Version Information，并要求双方通过受认证的握手机制交换。在 QUIC v1 中，它由 version_information 传输参数承载。RFC 9368 §9 进一步说明，这套机制的安全性依赖 Version Information 的真实性，而 QUIC v1 的传输参数提供相应认证。

由此得到的不是一个布尔值，而是一层层的证据。首个 Initial 记录客户端尝试的版本；未受保护的数据包记录某个发送方在该上下文中公布的列表；下一个 Initial 记录客户端的新选择；受认证握手记录最终选择，并在使用兼容版本协商时记录受认证的可用版本；完成的连接才说明哪种组合真正工作。

这条链可以解释一次重试、放弃或版本字段变化。它不能证明所有 anycast 边缘都返回同一列表，不能证明这些版本目前仍在生产中启用，不能证明每个版本都完成应用请求，也不能单凭早期数据包认定发送方就是指定服务。

真正的能力盘点需要在多个授权边缘和路径上探测，保存 TLS 身份与受认证 Version Information，记录软件和配置身份，并区分“公布可用”与“应用交换成功”。随时间重复观察，才可能形成部署证据；一包未受保护的列表不够。

运营回执应保存：客户端提供的版本、时间、五元组、Initial DCID/SCID、Version Negotiation 原始字节、回显 ID、列表原始顺序、丢弃规则结果、下一次尝试版本、握手所选版本、version_information、TLS 对端身份、边缘或发布版本以及最终结果。若后来使用了更低版本，也只能先记录为观察；判定降级还需要受认证 transcript、双方实际可用集合与选择规则。

这份数据包的价值恰恰来自边界清楚：它标出一次连接尝试中的兼容性分叉。它不是服务器证书、发布清单或全网支持承诺。