摘要

  • 报头中的 Packet Number 只有 1 至 4 个最低有效字节，并且受到 header protection 保护。
  • 接收端依据同一 packet-number space 中已成功处理的最大编号和下一预期值选择候选编号。
  • 重复低位、数字跳跃、回绕或解密失败本身，都不能证明丢包、重放、攻击或应用影响。

被动抓包很容易制造一种错误的确定性：两个报头看起来携带相同的 16 位数，于是报告重放；数值突然跳跃，于是报告大量丢包。RFC 9000 与 RFC 9001 要求把三个状态分开。第一是线路上实际出现的受保护字节；第二是移除 header protection 后得到的清晰截断值；第三是接收端根据状态重建的完整 Packet Number。完整编号是 0 到 2^62-1 的整数，但 long header 或 short header 中的 Packet Number 字段只传输 1 至 4 个字节的最低有效位。字段长度也受到保护。

编号没有连接级全局范围。QUIC 使用 Initial、Handshake 和 application data 三个 packet-number space；application-data space 同时包括 0-RTT 和 1-RTT。每个空间都从零开始。发送和接收方向也分别维护编号。因此同一个数字可能属于不同的包，跨空间或跨方向做差不能得到连接总序号。Retry 与 Version Negotiation 不携带 Packet Number，也不通过普通 ACK 确认。

发送端的编码宽度取决于状态。在某个空间尚未收到 ACK 时，发送端使用完整编号。收到 ACK 后，它选择足够的编码位，使其覆盖发送编号与 Largest Acknowledged 之间差值的两倍以上。RFC 中关于连续未确认编号的示例是算法说明，不是生产阈值，也不保证所有严重延迟的包都能被正确解码。

接收端必须先移除 header protection，才能得到清晰的截断值和字段长度。示例重建算法使用三个输入：当前空间中成功处理的最大 Packet Number、截断字段值以及字段位数。下一预期编号是最大成功接收编号加一。接收端在编码窗口内选择最接近该预期值的完整候选。没有这段状态，观察者无法仅凭抓包字节完成可信重建。

延迟包说明了窗口的边界。如果许多更高编号的包已经到达，迟到包的低位可能更接近错误候选。因此，deprotection 或认证失败不能单独证明对端违反协议或遭到攻击。重建的完整编号会参与 AEAD nonce；移除 packet protection 时，从报头开始直到 Packet Number 的未保护内容会作为 associated data 被认证。脱离这一流程猜测编号，不是经过认证的解码。

ACK 的证据性质不同。Largest Acknowledged 是完整的可变长度整数，不是报头中受保护的截断字段。ACK ranges 表示 ACK 所在包的 packet-number space 内哪些包已被接收和处理。它们可以支持端点侧的认证事实，却不能事后填补被动抓包的缺口，也不能跨空间解释。重复包的处理发生在保护移除、编号恢复和认证之后；相同低位还不是已认证的重复。

独立证据账本应分别记录连接身份与方向、包类型与空间、受保护字节与抓包完整性、密钥上下文与 deprotection 结果、编码长度与清晰低位值、同空间最大已处理编号、下一预期值与重建窗口、完整重建编号与包认证结果，以及携带 ACK 的空间、完整 ACK 值和 ACK ranges。丢包、重传、乱序、重放、注入、攻击、路径变化和应用交付必须另有证据。抓包缺口可能来自采集位置、抽样、截断、解密状态或实际流量，RFC 并未把缺口等同于协议丢包。

这也不同于 TR-038 的 spin bit 抽样、TR-042 的 key phase、TR-045 的 ACK 交付语义、TR-049 的报文合并以及 TR-051 的 PTO 探测。本议题只处理受保护编号如何在正确状态中重建。