摘要

  • draft-liu-sidrops-rpki-rtr-over-quic-04 的导言称已连接过的客户端可以实现“0-RTT”恢复，但连接建立条款要求客户端、服务端与 TLS 配置全部禁用或拒绝 Early Data。
  • QUIC 可以保护并并行传送 RTR 数据，却不能独自证明缓存视图已经完整；完成事实仍取决于协议版本、Session ID、Serial Number、参与的数据流集合与最后一份预期 End of Data。

第 04 版发布于 2026 年 9 月 7 日。它是个人 Internet-Draft，页眉写着 Standards Track，但 Datatracker 没有给它 RFC stream、工作组采纳、负责的 Area Director 或 telechat。这里不能借用同领域工作组草案的地位：8210bis 是 SIDROPS 的基础协议工作，RTRoQUIC 映射仍是个人提案，不是 IETF 决定，也不是部署、互通或性能证据。

草案导言给出了非常具体的速度叙事。QUIC 把 TLS 1.3 纳入传输层，又允许多条独立流并行前进。导言称，若客户端以前连接过同一服务端，它可以在首个数据包中携带 RTR 会话请求，实现“0-RTT”恢复，从而几乎立即重新同步 RPKI 验证数据库并缩短路由安全信息的空窗期。

但第 3.1 节采用了相反的规范性规则。RTRoQUIC 实现 MUST NOT 使用 Early Data；客户端 MUST NOT 在 ClientHello 中加入 early_data；服务端遇到它 MUST 拒绝；TLS 1.3 栈 MUST 配置为禁用 0-RTT。第 03 与第 04 版同时保留了宣传段落和禁用条款，这不是旧版本残留已经被后文修正，而是当前文本内部尚未闭合的契约。

“恢复”和“0-RTT”不能混成一个词。RFC 9001 明确指出，即使关闭 0-RTT，TLS 会话恢复仍可使用。普通恢复可以减少握手工作，但应用数据仍需等待相应安全边界；QUIC 0-RTT 则让客户端在握手完成前，用旧连接保留的参数发送应用数据。导言许诺的首包 RTR 请求正是后者，而规范条款把后者关闭了。

禁用并非没有理由。Early Data 缺少与普通应用数据相同的重放保护与前向保密属性。草案认为 RPKI 数据会影响 BGP 起源与路径判断，因此不接受这项交换。这个安全选择可能完全合理；问题在于，管理层不能一边把 0-RTT 当作迁移收益，一边把“必须禁用”当作实施细节。容量规划必须以规范允许的握手和事务为准。

第二条边界来自多流。最简单的映射把所有 RTR PDU 放进一条由路由器创建的双向 QUIC 流。每个字节都有同一条顺序。可选设计则把 Serial Notify、Serial Query、Reset Query、Cache Reset 与 Error Report 放到 Control Channel，把 Cache Response、载荷与 End of Data 放到一条或多条 Data Channel。

载荷又可以按 IPv4 Prefix、IPv6 Prefix、Router Key 与 ASPA 分成四条流。QUIC 的确能让一条流上的丢包不阻塞另一条流。这是传输层收益，却没有取消应用层的提交点。若 IPv4、IPv6 与 Router Key 三条流已经结束，而 ASPA 流仍因丢包滞后，前三个绿色指标并不等于完整缓存。

第 04 版试图以跨流规则恢复提交边界：每条 Data Channel 都必须收到 Cache Response 与 End of Data；跨 n 条流，最先收到的 Cache Response 被视为有效，最后收到的 End of Data 被视为有效。于是，参与本次响应的流集合本身成为事务状态。“最后”只有在双方都知道总共有哪几条流、哪一条尚未结束时才有意义。

QUIC 保证的是单条流内部顺序，不是连接内所有流的统一全序。若实现把首个 End of Data 当成完成，它可能安装混合快照；若等待最后一条预期流，它必须知道 Data Channel 的创建、归属、关闭、重置和错误如何绑定到这一轮查询。草案中的图能说明意图，却还不能替代可审计的事务标识。

8210bis 说明了提交标记为何重要。Serial Number 是某一个缓存的逻辑版本，Session ID 标识它的序号空间。判断两个序号是否对应，需要同时看 Protocol Version、Session ID 与 Serial Number。缓存更新未完成前不得发出新数据；在普通有序交换中，路由器收到 End of Data 后，才能认为已取得该缓存的全部当前数据，并把本地缓存序号推进到该 PDU 给出的值。

把载荷拆到四条流上，不能悄悄降低这项原子语义。先到达的 Router Key 可能格式和密码学都正确，但它未证明同一版本的 ASPA 或前缀变更已经齐全。前缀撤回与公告也不能简单按照墙上时钟的到达顺序写入；它们必须服从协商版本的交易和排序规则。

三个标识的权力都很窄。Serial Number 在不同缓存或不同协议版本之间没有可比性，缓存重置后也不必延续。基础草案警告，错误复用 Session ID 时，若后续增量刚好不与旧状态冲突，路由器可能长期不同步。QUIC 加密无法修复错误的缓存 epoch；TLS 握手成功只能说明所配置的对端认证条件成立，不能证明序号空间生成正确。

多缓存又增加一层。按照 8210bis，只要任一当前首选缓存提供某个 VRP，它就对路由器生效；直到最后一个首选缓存撤回，它才消失。因此，一条 RTRoQUIC 会话完成，不等于路由器的全局 RPKI 视图完成。运营者仍需按缓存保存独立凭据，再记录合并规则与结果。

后续链条也不能被传输成功吞并。收到 IPv4 Prefix PDU 不等于所有受影响 BGP 路由已经重新计算。本地安装 VRP 不等于某一条路由必然变成 Valid、Invalid 或 NotFound。策略判断不等于选路结果，RIB 变化不等于 FIB 写入，更不等于报文交付。QUIC 可以缩短其中一个区间，却没有后续层的决定权。

草案还把 TCP 回退写进真实路径：若 UDP 被阻断导致 QUIC 无法建立，路由器应该尝试基于 TCP 的 RTR 会话。这个安排保护连续性，却要求监控分开记录 QUIC 成功、QUIC 失败、TCP 回退开始、基础握手完成和缓存事务完成。一个笼统的“RTR connected”会掩盖真正的空窗期。

Running-Code Primacy 提供了更严格的评估方法。应测试两个独立实现能否选择同一 RTR 版本、认证预期对端、按要求拒绝 0-RTT、对参与流集合达成一致、承受某一流丢包、识别最后一份预期 End of Data，并且只提交一个缓存版本。四条并行箭头不是运行事实，重复可验证的故障与恢复记录才是。

最小互通契约不必接管所有本地选择。流数量、证书政策、缓存优先级、重试时间和 TCP 回退都可以由运营者决定。但事务身份不能靠口头约定。映射需要说明：一次查询如何绑定所有 Data Channel；重复 Cache Response 如何比较；End of Data 字段若冲突怎么办；一条流被重置后是重试、回退还是整个事务失败；哪个确切凭据允许推进 Serial Number。

因此，“完全消除队头阻塞”也必须收窄。QUIC 能消除不同流之间由单一传输字节序造成的阻塞。应用仍可能等待最慢的必需流、耗尽流额度、遭遇连接重置、版本不匹配、坏数据错误或本地安装延迟。并行改变了等待形状，并未消灭提交屏障。

领导者真正要问的不是“QUIC 还是 TCP”，而是“哪一份凭据关闭旧视图空窗”。受保护的快速连接很有价值，独立流也有价值；最终事实仍是路由器能够指出缓存身份、协议版本、会话、序号、完整流集合和已提交载荷，并继续说明路由策略怎样使用它。

来源