会话复用不生效排查
会话复用能省去完整握手，直接降低握手延迟与 CPU 开销。不生效时，先用 s_client 两次连接对比是否出现复用标记，再排查服务端是否启用了缓存或票据、集群内票据密钥是否一致。需要特别注意的是，TLS 1.3 的票据在握手完成后才下发，第一次连接不可能复用，这一点常被误判成「复用没生效」。
基本信息
| TLS 1.2 | 会话 ID 或票据；nginx 用 ssl_session_cache 与 ssl_session_tickets |
|---|---|
| TLS 1.3 | 票据在握手完成后下发，先完成一次连接再复用 |
| 常见原因 | 多节点票据密钥不同、缓存过小、客户端禁用复用 |
| 验证方式 | s_client 的 -sess_out 与 -sess_in 组合 |
| 影响 | 复用率低会推高握手开销与首包延迟 |
典型使用场景
- 排查稳定性问题之外的延迟异常：握手开销常被忽略
- 集群部署后复用率偏低的问题定位
- 滚动发布期间票据密钥变化导致的复用失效
- 评估缓存容量是否足够（命中率与并发连接量相关）
- 与 CDN 或负载均衡配合时确认票据是否能正常透传
两次连接验证复用
两次连接验证复用
# 第一次连接保存会话
openssl s_client -connect example.com:443 -servername example.com -sess_out sess.pem </dev/null >/dev/null
# 第二次连接复用，观察是否出现 Reused
openssl s_client -connect example.com:443 -servername example.com -sess_in sess.pem </dev/null 2>&1 | grep -iE 'reused|Session-ID'
# 连续握手观察 New 与 Reused 的比例
openssl s_client -connect example.com:443 -servername example.com -reconnect </dev/null 2>&1 | grep -E 'New|Reused' | head -8复用机制对比
| 机制 | 存储位置 | 跨实例效果 |
|---|---|---|
| 会话 ID 缓存 | 各实例内存 | 跨实例无效，需要会话保持 |
| 会话票据 | 服务端密钥加密，客户端保存 | 各实例共享密钥时有效 |
| TLS 1.3 票据 | 握手完成后下发 | 首次连接不可能复用 |
| 客户端策略 | 客户端侧 | 部分客户端主动禁用复用 |
反向代理集群应让所有节点共享同一份票据密钥文件，否则复用率会长期偏低；密钥本身按私钥标准保护，一旦泄漏会使相关会话流量可被解密。
观测建议：把复用率、握手耗时与 CPU 使用率放在同一张图上观察，比单独看复用率更容易发现规律。若复用率在发布后才下降，优先检查票据密钥与配置变更，而不是先去查客户端。