4、TLS False Start 与 0-RTT：原理、风险控制与适用场景
聊到 TLS 握手优化，有两个技术绕不开：False Start 和 0-RTT。说白了，它们都是为了「少等一次往返」而生的。但少等一次，往往意味着多冒一分险。
我在项目中见过不少团队，一听说 0-RTT 能省时间，二话不说就开了。结果线上出了重放攻击，又急急忙忙回滚。嗯，这章我们就把它掰开揉碎，讲清楚原理，也讲清楚什么时候能用、什么时候千万别碰。
4.1 False Start：少等一次，但别乱发
先说说 False Start。这个名字其实有点误导人——它并不是「错误启动」，而是「提前启动」。
正常 TLS 1.2 握手，客户端要等 ServerHello + ServerHelloDone 之后，才能发 ChangeCipherSpec 和 Finished。但 False Start 的逻辑是：只要客户端拿到了服务器的证书，并且自己算出了加密密钥，就可以立刻发应用数据，不用等服务器的 Finished 消息回来。
你想想看，这省掉了什么？省掉了整整一个 RTT。对于高延迟网络（比如跨国、卫星链路），这个优化非常可观。
核心条件：False Start 只在客户端确认服务器身份后才会触发。如果证书验证失败，客户端不会提前发送数据。
但这里有个坑。我记得有一次排查一个线上问题，发现某些老旧客户端在 False Start 场景下，握手还没完成就开始发 HTTP 请求。服务器端还没准备好，结果请求被当成乱序包丢弃了。后来我们加了个判断：只有确认服务器支持 False Start 的密码套件，才启用这个优化。
False Start 的适用场景很明确：
- 延迟敏感：比如实时音视频、在线游戏
- 证书链较短：证书链太长会拖慢验证，抵消优化效果
- 客户端支持良好：主流浏览器和现代库都支持，但嵌入式设备可能不行
我的建议：如果你用 Nginx 或 OpenSSL 1.0.2+，False Start 默认就是开启的。但记得检查一下密码套件列表，确保没有使用 RC4 或 CBC 模式的旧套件。
4.2 0-RTT：零往返，但风险翻倍
0-RTT 是 TLS 1.3 引入的「杀手锏」。它允许客户端在第一次连接时就携带应用数据，完全不需要等待服务器响应。
怎么做到的？原理其实不复杂：
- 客户端之前和服务器完成过一次完整握手
- 服务器下发了一个 session ticket（会话票据），里面包含了加密密钥材料
- 下次连接时，客户端直接用这个票据加密数据，连同 ClientHello 一起发出去
这样一来，第一个 RTT 就省掉了。对于短连接场景（比如 HTTP 请求、API 调用），效果立竿见影。
但代价呢？代价就是——重放攻击。
注意：0-RTT 数据天然不具备「抗重放」能力。攻击者可以截获客户端的 0-RTT 请求，然后重复发送给服务器。如果服务器没有做幂等性处理，后果很严重。
我曾经在一个金融项目中遇到过这个问题。当时团队开了 0-RTT，结果测试发现，同一个转账请求被重放了三次，账户扣了三次钱。嗯，从那以后，我对 0-RTT 的态度就变成了：能用，但必须加锁。
4.3 风险控制：怎么给 0-RTT 上锁？
0-RTT 的风险控制，说白了就两件事：防重放和限范围。
4.3.1 防重放机制
TLS 1.3 规范里给了几种方案：
| 方案 | 原理 | 优缺点 |
|---|---|---|
| 单次使用票据 | 服务器记录已使用的 ticket，拒绝重复 | 简单，但需要维护状态 |
| 时间窗口 + 随机数 | 客户端携带时间戳和随机数，服务器检查窗口内是否重复 | 无状态，但依赖时钟同步 |
| 服务器端去重缓存 | 用 Bloom Filter 或 Redis 缓存已处理的 0-RTT 数据指纹 | 性能好，但可能有误判 |
我个人习惯用「时间窗口 + 随机数」的方案。原因很简单：无状态，适合分布式部署。但要注意，服务器之间的时钟偏差不能太大，否则会误杀合法请求。
4.3.2 限制 0-RTT 的使用范围
不是所有请求都适合用 0-RTT。我建议你遵循这个原则：
- 只对幂等请求启用 0-RTT：比如 GET 请求、查询类 API
- 非幂等请求（POST、PUT、DELETE）必须走完整握手：或者至少等 1-RTT 确认后再发
- 敏感操作（转账、修改密码）永远不要用 0-RTT
经验之谈：我在一个电商项目中，把 0-RTT 只开放给「商品详情页」和「搜索」接口。下单、支付这些操作，强制走 1-RTT。效果很好，延迟降低了 30%，而且没出过安全问题。
4.4 适用场景对比：什么时候选哪个？
False Start 和 0-RTT 不是互斥的，它们可以共存。但你要根据场景选对策略。
| 场景 | 推荐策略 | 理由 |
|---|---|---|
| 首次连接 | False Start | 没有 session ticket，0-RTT 用不了 |
| 重复连接（幂等请求） | 0-RTT | 省掉整个 RTT，延迟最低 |
| 重复连接（非幂等请求） | False Start 或 1-RTT | 避免重放风险 |
| 高延迟网络（>200ms） | 优先 0-RTT | 延迟收益最大 |
| 嵌入式/低性能设备 | False Start | 0-RTT 的票据管理可能增加复杂度 |
你想想看，如果是一个跨国 API 网关，客户端在欧美，服务器在亚洲。第一次请求用 False Start 省掉 1 个 RTT，后续请求用 0-RTT 再省 1 个 RTT。整体延迟能从 400ms 降到 200ms 以下。这个优化，用户是能直接感受到的。
4.5 核心逻辑图：False Start 与 0-RTT 的握手流程
下面这张图展示了两种优化在 TLS 1.3 握手中的位置和区别。你可以看到，False Start 是在 1-RTT 阶段提前发数据，而 0-RTT 是在第一个消息里就直接带数据。
4.6 避坑指南：我踩过的几个坑
最后，分享几个我亲身踩过的坑，希望能帮你少走弯路。
- 坑一：0-RTT 和 HTTP/2 的冲突。HTTP/2 的多路复用和 0-RTT 的 session ticket 管理有时会打架。我在一个项目中遇到客户端复用 ticket 但 HTTP/2 连接已经关闭的情况，导致 0-RTT 数据被丢弃。解决方案是：在应用层加一个重试逻辑，如果 0-RTT 失败，自动降级到 1-RTT。
- 坑二：False Start 在中间件环境下的兼容性。有些反向代理（比如老版本的 HAProxy）不支持 False Start，会导致握手卡死。我曾经排查了三天，最后发现是代理把客户端的提前数据当成了非法包。嗯，从那以后，我养成了一个习惯：在代理层显式关闭 False Start，只在源站开启。
- 坑三：0-RTT 的票据过期策略。session ticket 的过期时间太短，优化效果不明显；太长，又增加重放风险。我一般设置为 5 分钟，既覆盖大多数短连接场景，又把风险窗口控制在可接受范围内。
最后一句：False Start 和 0-RTT 都是好工具，但工具再好，也得看你会不会用。记住一句话：优化延迟的前提，是不牺牲安全性。