会话恢复省下了什么
会话恢复省掉一次完整的密钥交换与证书校验：TLS 1.2 用会话标识或会话票据，TLS 1.3 用预共享密钥。把完整握手与会话恢复的耗时分布分开统计，就能量化这份收益。收益大小与链路往返时间强相关，RTT 越大、并发越高，省下的往返与 CPU 越明显；在低延迟内网里收益相对有限。
基本信息
| 关键字段 | tls.handshake.type、tls.handshake.session_id、预共享密钥相关扩展 |
|---|---|
| 分组口径 | 完整握手（含 Certificate）与恢复握手（无 Certificate） |
| 相关机制 | TLS 1.2 的会话标识与票据（RFC 5077）、TLS 1.3 的 PSK |
| 统计方式 | 两类各取 P50 与 P95，附上链路 RTT 基线 |
典型使用场景
- 评估开启会话恢复后的实际延迟收益
- 解释恢复率低的系统为什么调握手参数没有效果
- 为跨地域服务的 TLS 调优提供数据支撑
- 对比不同服务端实现的恢复效率
- 观察升级到 TLS 1.3 后握手开销的变化
分组统计
分组统计
# 先按 TCP 流或 SNI 分组，再判断每个握手是否携带证书
tshark -r a.pcap -Y "tls.handshake.type==11" -T fields -e tcp.stream | sort -u | wc -l
# 带 Certificate 的流数量，用来估算完整握手的比例
tshark -r a.pcap -Y "tls.handshake.type==2" -T fields -e tcp.stream -e tls.handshake.session_id
# 1.2 恢复握手会复用非空 session_id，可与完整握手区分
tshark -r a.pcap -Y "tls.handshake.type==2" -q -z io,stat,60
# 按分钟统计握手数量，观察恢复与完整握手在不同时段的分布分组对照
| 口径 | 特征 | 差值来源 |
|---|---|---|
| 完整握手 | 含 Certificate 与密钥交换 | 作为参照 |
| 恢复握手（1.3 PSK） | 无 Certificate，走预共享密钥 | 省去证书校验与密钥交换 |
| 恢复握手（1.2 票据） | 无 Certificate，带会话票据 | 省去一次往返与证书校验 |
| 恢复失败转完整握手 | 票据过期或被服务端拒绝 | 多一次往返后仍要走完整流程 |
恢复率低时优化重点在会话复用配置，而不是握手参数：票据密钥轮换周期、恢复窗口、多台服务端是否共享票据密钥都会直接影响命中率。服务端各自持有密钥时，负载均衡把恢复请求分散到不同实例，命中率自然上不去。
会话恢复伴随安全权衡：票据密钥需要定期轮换，恢复窗口过长会削弱前向保密的收益。用 CPU 换延迟的取舍要结合服务端负载评估，不能只看单请求耗时。
排查顺序
- 先分组统计完整握手与恢复握手的耗时分布
- 再确认恢复率，低命中率时先查配置而不是参数
- 核对多实例之间的会话票据共享方式
- 记录链路 RTT 基线，收益数值必须与 RTT 一起呈现
- 调整后复测同一口径，确认收益来自恢复而不是流量波动