0-RTT 会话恢复：原理、配置步骤与安全风险分析
好，咱们今天聊聊 TLS 1.3 里那个让人又爱又恨的特性——0-RTT 会话恢复。说它让人爱，因为首轮就能带数据，延迟几乎减到零；说它恨，是因为稍不留神就埋下安全漏洞。
我个人接触 0-RTT 是在帮一家电商做移动端 HTTPS 加速的时候。客户端每次冷启动都要等至少一个来回，用户体验很差。后来上了 0-RTT，首屏加载快了将近 200 毫秒。但实话告诉你，刚开始我差点踩进重放攻击的坑里。今天就把这些经验掰开揉碎讲清楚。
什么是 0-RTT？原理概述
普通 TLS 1.3 完整握手需要 1-RTT，也就是一次网络往返，客户端和服务端交换密钥后才能发应用数据。但 0-RTT 允许客户端在第一次握手消息（ClientHello）之后，立即发送一段数据——这相当于客户端从上次会话中存了一张“快速通行证”，不用再等服务器回应就能先发业务请求。
这张“通行证”的核心是一个 PSK（Pre-Shared Key，预共享密钥）。服务器在之前会话结束时，会发一张加密的会话票据（Session Ticket）给客户端。客户端保存票据，下次连接时把票据放在 ClientHello 的扩展字段里，同时使用 PSK 派生 0-RTT 加密密钥，直接加密数据一起发出。
握手流程对比：1-RTT vs 0-RTT
下面这张表可以看清两种模式的差异。我在项目里经常用这张对比图说服团队使用 0-RTT。
| 特性 | 1-RTT（完整握手） | 0-RTT（会话恢复） |
|---|---|---|
| 首次数据发送节点 | 第二次往返的 Client Finished 之后 | ClientHello 之后 |
| 是否依赖之前会话 | 否 | 是（需有效 Session Ticket） |
| 往返次数（到发数据） | 1 个 RTT | 0 个 RTT |
| 安全性风险 | 较低 | 需要防范重放攻击 |
说白了，0-RTT 就是拿安全性换性能。服务器收到 0-RTT 数据时，没办法立刻确认这条数据是不是攻击者截获后重放的——因为此时握手还没完成，服务器的“状态”只来自于一个旧票据。
核心数据结构：PSK 与会话票据
要实现 0-RTT，服务器必须在首次连接时生成一个 Session Ticket。这个票据里包含一个主密钥（PSK）和其他密钥参数，然后加密发给客户端。
我建议你记住下面几个关键点：
- 票据有效期：通常由服务器配置，比如 2 小时或 24 小时。太短恢复率低，太长安全风险增加。
- 票据加密：服务器必须有独立的票据密钥（Ticket Key），不能和 TLS 握手密钥混用。否则一旦泄露，历史会话全被破解。
- PSK 大小：至少 32 字节（256 位），推荐使用 HKDF 派生而不是直接用原始票据密钥。
有意思的是，TLS 1.3 允许服务端选择是否接受 0-RTT。在 ServerHello 的扩展里有一个 early_data 指示，值为 1 表示接受。如果服务器拒绝，客户端的 0-RTT 数据会被默默忽略，客户端再按 1-RTT 重发。
配置步骤：Nginx 示例
以最常见的 Nginx 为例。开启 0-RTT 其实就是一行配置，但配套的那些安全参数才是真正的坑。
# 必须使用 TLS 1.3
ssl_protocols TLSv1.3;
# 开启 0-RTT 支持
ssl_early_data on;
# 会话票据缓存（推荐）
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;
# 设置独立的票据密钥
ssl_session_ticket_key /etc/nginx/ticket.key;我这里说个小坑：ssl_early_data on 并不是万能的。如果上游后端（比如 PHP-FPM 或 Java 应用）不幂等，0-RTT 数据的重放可能会让你背上“数据异常”的黑锅。我曾经因为这个原因，花了整整两天找到根源——原来是后端接收了两次相同的下单请求。
ssl_session_ticket_key 文件必须定期轮换。我建议至少每周换一次，并在 Nginx reload 时保留旧文件一小段时间，防止正在使用旧票据的客户端连接失败。
安全风险分析
0-RTT 最大的敌人是重放攻击。攻击者截获客户端的 ClientHello 和 0-RTT 数据包后，可以伪造源 IP 一遍又一遍地发送给服务器。服务器因为还没建立完整的会话状态，无法判断这个数据是否第一次到达。
还有几个风险点需要注意：
- 反重放机制：服务端必须实现。常见的做法是把收到的 0-RTT 数据指纹（或 ClientHello 的随机数）缓存一段时间（比如 10 秒），相同指纹拒绝第二次。云服务商比如 Cloudflare 就是这么干的。
- 数据幂等性：0-RTT 请求必须是幂等的，或者后端做好去重。GET/HEAD 通常安全，但 POST（尤其是下单、转账）就极危险。
- 票据密钥泄露：如果 ticket.key 被窃取，攻击者可以伪造任意 0-RTT 票据，所有历史会话都可能被重放。
你想想看，如果攻击者重放的是“转账 1 万元”这样的请求，那后果多严重？所以我的建议是：对于非幂等操作，要么禁用 0-RTT，要么在应用层加上幂等键（Idempotency-Key）。
一张图看懂 0-RTT 会话恢复流程
下面这张流程图展示了一次典型的 0-RTT 会话恢复。注意客户端在第一次消息中就发了 Early Data（0-RTT 数据），而服务器在验证票据后立即响应。
避坑指南：你可能会遇到的情况
我记得有一次，上线 0-RTT 后，后端日志里出现了大量“订单重复创建”的告警。排查后发现是某个第三方服务没有做去重，0-RTT 的重放导致同一个订单被提交了两次。最后我们在反向代理层（Nginx）开启了反重放缓存，同时要求业务方在关键接口上加上幂等键才解决。
另一个常见坑是会话票据过期时间设置得过长。有个团队设了 7 天，结果一周后攻击者拿着之前的抓包数据轻松重放成功。后来我强制他们改成 30 分钟——反正 0-RTT 主要用在短时间内的后续请求，比如用户浏览商品加入购物车这种场景，不需要保留太久。
① 服务端反重放缓存（至少 10 秒窗口）
② 业务数据幂等性
③ 票据密钥定期轮换
④ 票据生命周期严格控制（推荐 ≤ 1 小时）
总结一下我的个人观点：如果你做的是短连接、高频次、幂等性高的服务（比如 CDN 缓存查询、OTA 升级包下载），0-RTT 几乎无脑上。但如果涉及金融、支付、订单，务必在应用层增加去重逻辑。别像我当年那样，被线上重复订单折磨得头秃。