摘要

  • 接受 0-RTT 数据只证明传输层作出了一次决定，并不证明业务动作只提交一次。
  • 有效验收必须把早期数据处理、反重放范围、重试路径和应用的权威提交结果连接起来。

设想客户端恢复连接以开通一项服务，并在握手结束前发送 POST。一个边缘节点接受了早期数据，响应中断后，客户端或中间设备又经另一个节点重试。监控看见的是连接更快、请求成功；它没有回答最重要的问题：系统究竟创建了一份服务，还是两份？

这只是说明机制的假设场景，不指向任何真实事故。边界来自标准本身。RFC 8446 允许共享恢复材料的客户端与服务器发送 0-RTT 数据，同时明确指出，其安全属性弱于普通应用数据，不保证跨连接不可重放。同一连接内不能简单复制记录并让服务器重复接受，但分布式系统面对的是另一件事：不同节点是否知道同一个逻辑动作已经被接受。

部署范围内更强的反重放能力需要共享已见状态或等效机制。RFC 8446 也承认这种一致性有运营成本，并非所有部署都以同一范围维护它。因此，一个节点接受会话票据，只能证明本地允许了早期数据，不能证明另一个接受域必然拒绝同一个动作。

QUIC 没有把责任消除。RFC 9001 明确提醒，0-RTT 中的应用数据可能导致服务器多次处理，应用协议必须定义可接受的用途与缓解措施。后来完成握手可以认证并建立连接状态，却不能倒推早先的动作已经自动获得“只执行一次”的属性。

HTTP 提供了必要的路径信号。RFC 8470 定义 Early-Data: 1，让中间设备继续携带“该请求在前一跳曾以早期数据发送”这一事实。等待当前握手结束不能抹去这个事实，也不能自动让请求变得安全。服务器若不愿承担潜在重放风险，可以返回 425 Too Early；后续重试应在握手完成后发送。

请求方法的语义同样关键。RFC 9110 把幂等定义为：多次相同请求的预期服务器效果与一次请求相同。POST 不会因为附带一个键就自然变成幂等。应用可以把某类 POST 设计为安全重试，但必须真实落实键的作用范围、保存期限、冲突规则，以及所有路径都能查询的权威结果。

常见运营错误，是拿一层的指标替另一层作担保。0-RTT 接受率说明快速路径的使用；TLS 或 QUIC 日志说明连接状态；HTTP 状态码说明一条响应路径。任何一项都不能单独证明持久提交发生了几次、重试是否进入另一个反重放域，或事务之外的副作用是否已经发生。

验收记录应当连接而不混淆这些层级：请求身份或幂等键、方法和资源、恢复与早期数据决定、边缘和源站身份、反重放域、Early-Data 传播、425 与重试路径、应用事务标识、最终提交次数与结果。记录不应暴露秘密，但必须说明决定接受范围的控制域。

目的不是禁止 0-RTT。只读操作以及明确可容忍重放的动作可以从中获益。真正的纪律，是不让时延优化继承它无法承担的保证。握手可以很快；只有应用才能证明这些字节最终造成了什么结果。

来源