摘要

  • PADDING 是仅含一个字节的帧，没有内容和语义价值；它增加报文字节，却不携带应用、STREAM 或 CRYPTO 数据。
  • 只有 PADDING 的数据包属于在途数据，会占用拥塞窗口，却不会产生打开窗口所需的确认；RFC 9000 规定发送方 SHOULD 定期加入其他 ack-eliciting 帧。
  • 客户端 MUST 将每个承载 Initial 的 UDP 数据报扩展到至少 1200 字节；服务器 MUST 对承载 ack-eliciting Initial 数据包的数据报执行同样要求。两项规则都不能证明传输进展。

一个运维面板显示 UDP 数据报长度为 1200 字节，另一个面板显示在途字节上升。若二者被合并成“握手已推进”，证据边界就被破坏了。UDP 数据报长度、QUIC 数据包边界和类型、PADDING 字节数、是否存在 ack-eliciting 帧、在途字节、拥塞窗口变化、ACK、握手状态和应用结果必须分开记账。

QUIC PADDING 帧的类型是 0x00，只包含标识字节。它没有内容，也没有语义价值。它可以增加数据包大小，把 Initial 扩展到要求的大小，并减少部分流量分析可见信息。但它不携带应用、STREAM 或 CRYPTO 数据，也不携带收据、结果或完成信号。因此，PADDING 字节本身不能证明对端处理了有用内容，不能证明握手取得进展，也不能证明应用收到了数据。

一个数据报可以携带包含 PADDING 的 Initial 和其他帧，也可以携带通过数据包合并形成的多个 QUIC 数据包。只观察长度，无法判断哪些字节推动了握手；需要在授权端点解析数据包边界和受保护的帧结构。包含 PADDING 的数据包仍可能同时包含 ack-eliciting 帧并收到 ACK。这个 ACK 只提供受 QUIC 确认语义限制的数据包处理证据，不会把 PADDING 变成握手或应用内容。

RFC 9000 将包含 ACK、PADDING 和 CONNECTION_CLOSE 以外帧的数据包定义为 ack-eliciting。只有 PADDING 不会使接收方发送 ACK。包含 PADDING 的数据包却仍计入拥塞控制意义上的在途数据；只有 PADDING 的数据包会消耗拥塞窗口，却不会产生能够打开窗口的确认。因此发送方 SHOULD 定期加入其他 ack-eliciting 帧。在途字节增加，不等于取得有用进展。

1200 字节规则的范围很明确。客户端 MUST 将每个承载 Initial 的 UDP 数据报扩展到至少 1200 字节，可以加入 PADDING，也可以进行数据包合并。服务器 MUST 对承载 ack-eliciting Initial 数据包的数据报执行同样操作。该规则用于检验对合理路径最大传输单元的支持；客户端扩展还会减少地址未验证时服务器可用的放大空间。它不是 1200 字节握手内容的最低要求，也不能说明每个 Initial 都使用 PADDING。

地址验证前，服务器三倍反放大记账会计算所有可唯一归属于该连接的 UDP 负载字节，包括 PADDING。没有语义价值不等于不占预算。PADDING 可以改变可观察长度、减少部分流量分析信息，但不保证隐私，也不隐藏时间、方向、数据包数量或所有长度信息。隐私安全的证据保留和分离记账是编辑建议，不是 QUIC 要求。