摘要

  • 接受 QUIC 0-RTT 是 TLS 与传输层的决定，不是应用只执行一次的证明。
  • 数据包 ACK 只能证明传输处理，不能证明抗重放、持久提交、客户端身份或业务成功。
  • 应用协议必须规定早期数据的可接受用途，并分别记录执行、幂等判断、副作用和结果。

QUIC 0-RTT 允许客户端复用上一次连接关联的配置，包括 TLS 会话票据，在新的握手完成前发送应用数据。服务器通过 EncryptedExtensions 中的 TLS early_data 扩展接受这种数据，随后处理并确认收到的 0-RTT 数据包。如果服务器不发送该扩展，0-RTT 就被拒绝，相关数据包不得继续按已接受的早期数据处理。

这条链路的证据边界很窄。它不能证明应用处理程序恰好执行了一次，也不能证明请求到达下游服务、跨过持久化提交边界或形成客户结果。握手完成前，它也不能单独证明客户端仍然在线或已经完成身份认证。地址验证可以提供额外信息，却不会把可重放请求变成唯一的业务动作。

QUIC 0-RTT 继承 TLS 早期数据的重放暴露。TLS 层的缓解措施必要但并非应用保证。QUIC 核心传输帧处理具有幂等性，因此重放传输帧本身不会制造无效的连接状态。真正的持久风险来自帧中承载的应用语义。STREAM、RESET_STREAM、STOP_SENDING 和 CONNECTION_CLOSE 都可能传递应用含义，在 0-RTT 中具有潜在危险。使用 QUIC 的应用协议必须定义可接受的用途；客户端只有在应用明确允许时才应发送 0-RTT 应用数据。

HTTP 给出了清晰的信号。没有更好信息时，客户端可以在早期数据中使用安全方法，不得使用不安全或安全性未知的方法。Early-Data 表示中间设备在早期数据条件下转发了请求。425 Too Early 表示服务器不愿冒险处理可能被重放的请求；后续重试本身不得再次使用早期数据。中间设备已经标记 Early-Data 后，即使等待握手完成，也不会让原请求追溯性地变安全。分布式实例必须采用一致的处理规则。

证据台账应分别记录会话票据与记住的配置；0-RTT 已尝试、已接受或已拒绝；数据包确认；Early-Data 的传播与 425 的处理；请求身份与幂等键；应用执行尝试；副作用；持久提交回执；重试或重放观察；客户或财务结果。幂等键、交易日志、分布式重放台账和业务回执是依据证据边界提出的运营建议，除非应用协议另有规定，并非 QUIC 的要求。

因此，正确做法不是一律关闭 0-RTT，而是只把它用于重放后果明确受限的操作。关闭 0-RTT 是最有效的重放防线，但有限度的安全操作仍可使用。接受早期数据只能证明传输层对早期数据的接受决定，不能被写成交易已经提交。