摘要

  • RFC 9369 故意把“QUIC version 2”这个文档名称与长头部中的 0x6b3343cf 分开；看见该字段只是某个包的有限事实，不是部署清单。
  • 支持 v2 的端点必须交换并验证经认证的版本信息。只有把它接到相应的握手收据后，才能说明一次连接的版本选择；它不能证明整个机群、应用结果或其他网络的采用义务。

版本名称很容易制造一条过于顺滑的时间线：v1 是过去，v2 已经发布，所以互联网理应已经向前走。RFC 9369 不接受这种替代证据的叙述。Martin Duke 把“version 2”称为第二个经 Standards Track 发布的 QUIC 版本的非正式叫法，却为长头部的 Version 字段指定 0x6b3343cf。这个值由哈希导出，而不是写入 2。它不是技术装饰；它用来防止中间设备把熟悉的 v1 字节模式固化为永恒规则。

因此至少有三种事实不能混写。RFC 说明共同规范；IANA 登记分配的值；抓包说明某个时间、某条路径上看到了某个字段。三者都可能正确，也各有用途。但它们都不是端点数量统计，不表示最终对端一定理解 v2，不证明 TLS 握手完成，更不表示 HTTP/3 或其他应用实际返回了结果。把其中一项压缩成“v2 已部署”，正是把尚未取得的证据提前宣布为结论。

v2 本身的变化也很克制。RFC 9369 继承大部分 v1 行为，但改换长头部包类型、Initial salt、HKDF 标签和 Retry 完整性材料。变化足以检验版本协商并暴露围绕 v1 的僵化假设，却不足以让旁观者读出某个实现的完整能力。RFC 8999 直接把“看到某个 Version 值就等于该版本正在使用”列为错误假设。字段标识的是收到或提供的协议标识符；它的运行含义需要端点及后续交换来限定。

服务器端尤其不能跳步。一枚看似 v2 的 Initial 可能先到负载均衡器，再到无状态 Retry 组件、转发层和应用服务器；这些组件未必共享同一版本支持。边缘捕获不是最终进程的配置证明。Version Negotiation 包也不足以下结论。RFC 8999 说明它没有完整性或保密保护；连接 ID 的回显只能提供发送者看见流量的有限迹象。RFC 9368 因而要求端点在因该包改用其他版本前认证语义内容。关键收据是与这次尝试绑定的、随后得到验证的握手状态，而不是一份抵达边缘的版本列表。

RFC 9369 还明确 v2 不打算废弃 v1。Alt-Svc 中的 h3 宣告并不区分 QUIC 版本，所以宣告它的源站应继续支持 v1，避免旧客户端发生不必要的不兼容或 TCP 回退。v1 与 v2 被定义为兼容版本；两者都支持的端点应支持兼容协商以减少一次往返。这些是互操作规则，不是命令运营者删除 v1、强制开启 v2，或把保留另一兼容集合的网络宣布为无效。

连 v2 会话票据也只作有限陈述。RFC 9369 说，票据表示端点有意在有效期内维持 v2 支持，同时明确支持并不保证。它可以成为关于一个端点的一项有时限信号；它不是后续连接的担保，不描述另一条边缘路径，也不能被扩张成整个平台的服务承诺。

防降级机制同样落在连接本地。v2 端点必须发送、处理并验证 RFC 9368 定义的 version_information 传输参数。客户端和服务器在经认证的交换中核对已选和可用版本。完成后可以严谨地说：这两个参与者在这次连接中通过了规定的版本选择检查。不能由此跳到人的身份、应用授权、数据保存或服务成功。

Martin Duke 的作者身份也应这样读取。IETF 个人页和 RFC 9369 证明他撰写了一份 Standards Track 规范；它们并不使他拥有 QUIC、决定 HTTP/3 的部署或自动代表每个端点背后的用户。该 RFC 的价值恰恰在于：它为将来变化留下可检验路径，却不假称出版文档可以把本地代码变成全球现实。

这与《heng.lu note》中“最小初始规范”的约束相呼应，但不应把 QUIC 强行写成治理宣言。共同层负责可确定验证的互操作与安全规则；实现、部署时点和自愿采用仍属于运行系统的参与者。非字面的线上值、明确的兼容性和经认证的协商，提供了这种克制的一个技术类比。

需要保存的不是一个版本徽章，而是一串收据：长头部值和路径、对端宣告的版本、version_information 的认证结果、最终选择、握手完成、协商的 ALPN、请求/响应结果、软件范围和观察窗口。错误和回退也应保留。只有这条链能区分登记值、观察到的包、双边协商成功和真正交付的服务。

来源