启用 TLS 1.3 的 0-RTT（ssl_early_data on）可降低 TTFB，但仅当满足全部前提：客户端缓存有效 PSK、相同域名/ALPN/参数、PSK 未过期、浏览器支持且 Nginx 正确配置；须限制 early data 仅用于幂等操作，防范重放风险，并通过抓包与日志验证生效。
启用 TLS 1.3 的 0-RTT（通过 ssl_early_data on）确实能显著降低 HTTPS 首字节时间（TTFB），尤其对重复访问用户，但必须清醒认识其安全边界与适用场景——它不是“无条件加速”，而是“有约束的快速重连”。
0-RTT 真正起效的前提条件
只有满足全部以下条件，客户端才会发送 early data，服务端才可能提前响应：
- 客户端之前已与该服务器完成过 TLS 1.3 握手，并缓存了有效的 PSK（Pre-Shared Key）
- 本次请求使用相同域名、相同 ALPN 协议（如 h2 或 http/1.1）、相同签名算法和密钥交换参数
- PSK 尚未过期（Nginx 默认缓存 48 小时，可通过
ssl_session_timeout调整） - 客户端浏览器支持且启用了 0-RTT（Chrome 72+、Firefox 76+、Safari 15.4+ 默认开启）
nginx 中正确启用 ssl_early_data 的关键配置
仅写 ssl_early_data on 不够，需配套加固与兼容性处理：
- 必须启用 TLS 1.3：
ssl_protocols TLSv1.3;（禁用 TLS 1.2 及以下可进一步提效，但需权衡兼容性） - 显式开启 early data：
ssl_early_data on; - 在 server 块中用
if ($ssl_early_data = "1") { ... }区分 early data 请求，避免缓存污染或状态冲突 - 对 early data 请求，建议只响应幂等操作（如 GET /static/xxx、GET /api/status），禁止处理登录、下单、表单提交等非幂等动作
- 搭配
ssl_buffer_size 4k;减少小包开销，配合 early data 更快发出首响应
务必规避的典型风险与误用
0-RTT 数据不提供前向安全性，且可能被重放——这不是性能缺陷，而是协议设计使然：
- 切勿在 early data 中处理任何带副作用的操作（如 POST /login、PUT /profile），否则攻击者可截获并重放请求，导致重复扣款、重复提交等
- Nginx 不会自动拒绝重放请求，需应用层校验（如一次性 token、时间窗口、请求指纹去重）
- CDN 或中间代理若不识别
Early-Data: 1头，可能错误缓存 0-RTT 响应，造成内容错乱 - HTTP/2 下 0-RTT 效果更明显；HTTP/1.1 因队头阻塞，收益有限
验证是否真正生效的实操方法
不能只看配置，要抓包+日志交叉验证：
- 用 Chrome DevTools → Network → Headers 查看请求是否带
Early-Data: 1头 - Wireshark 过滤
tls.handshake.type == 11（End of Early Data），确认客户端发送了 early data - Nginx 开启
error_log /path/to/log debug;，搜索"early data"或"psk"关键词 - 对比首次访问（完整 1-RTT）与二次访问（0-RTT）的 TTFB：理想情况下可减少 50–150ms（取决于网络 RTT）
