TLS 1.3 的 0-RTT 为什么不是“免费加速”？先看重放风险

TLS 1.3 的 0-RTT 常被理解成“省掉一次往返，所以一定更快”。它实际上依赖此前连接留下的 PSK 或会话票据，服务器可以接受、拒绝或要求重新握手，而且早期数据带有需要应用层处理的重放风险。

0-RTT 省掉了什么

普通首次连接需要先完成握手，再发送应用数据。恢复连接时，客户端可能在第一批消息中携带早期数据，因此在合适条件下减少等待。但 RFC 8446 规定，服务器仍可忽略早期数据并回退到常规 1-RTT，也可以通过 HelloRetryRequest 要求客户端重新开始。

所以看到“TLS 1.3”并不能证明正在使用 0-RTT；第二次访问更快，也可能来自会话恢复、连接复用、DNS 缓存或浏览器缓存。

为什么有重放风险

RFC 8446 明确指出，TLS 本身不为 0-RTT 数据提供固有的重放保护。攻击者可能复制早期数据，客户端重试也可能让服务器收到重复的应用消息。因此应用不得把不适合重复执行的操作随意放进早期数据。

对读者最实用的判断是：普通只读请求即使被重复，后果通常较容易控制；提交订单、修改账户或发送消息等有副作用的请求，不应因为追求少一次往返而假定可以安全重放。

机场节点测试怎样避免误判

1. 先完全关闭测试程序，做一次冷启动连接。
2. 在同一进程内连续请求同一授权目标，记录热连接结果。
3. 分别记录 DNS、TCP、TLS 和首字节时间，不只看总时间。
4. 换节点后重复同样顺序，避免把缓存命中算成线路优势。
5. 不对登录、支付或任何会改变服务器状态的接口做 0-RTT 实验。

代理协议、节点入口和目标网站的 TLS 是不同层。机场节点可能改善网络往返，但是否启用 0-RTT 由客户端、服务器和应用协议共同决定。

验收结论怎么写

测评应分别报告首次连接和连续访问，不把“第二次更快”直接归因于 0-RTT，也不把 0-RTT 写成服务商独有能力。确认不了早期数据是否被接受时，就只描述可观察到的握手与请求时间。

来源：RFC 8446：TLS 1.3 早期数据与 0-RTT 重放风险。