4. 会话复用的概念与重要性
先说个我早年踩过的坑。那时候给一个电商平台做 HTTPS 改造，白天压测 QPS 死活上不去，一看 CPU 全耗在 SSL 握手上了。一条连接建一次握手，用户点个商品详情就得重新握一次，这谁顶得住？后来才意识到：会话复用这东西，不是锦上添花，是刚需。
会话复用，说白了就是让客户端和服务器跳过完整的 TLS 握手，直接用上次协商好的会话参数建立安全连接。好比你有张 VIP 通行证，进园区不用再排队登记，亮个证就能过。
核心收益：一次完整 TLS 1.2 握手通常需要 2-RTT（两次往返），加上 TCP 的 1-RTT，总共得 3 个来回。会话复用后，能把握手压缩到 0-RTT 或 1-RTT，延迟直接从百毫秒级降到个位数毫秒。
4.1 两种主流复用机制
目前实现会话复用有两种主流方式，我按自己的理解把它们分成了「服务端存」和「客户端带」两类。
| 机制 | 原理 | 典型开销 | 适用场景 |
|---|---|---|---|
| Session ID | 服务端保存会话参数，分配一个 ID 给客户端；客户端重连时带上该 ID，服务端命中后直接恢复 | 1-RTT（加上 TCP 总共 2-RTT） | 固定连接、服务端内存充足 |
| Session Ticket | 服务端将会话参数加密成暗票发给客户端；客户端下次重连直接附上暗票，服务端解密恢复 | 0-RTT（加上 TCP 共 1-RTT） | 移动端、高频短连接、负载均衡场景 |
我个人的习惯：对内网服务偏向用 Session ID，因为机器稳定、内存充裕；对外暴露的高并发 API 一定开 Session Ticket，能省一个往返，用户体验直接起飞。
4.2 为什么非用不可？
你想想看，没有会话复用时，每次新连接都得走一遍证书链验证、密钥协商、密码套件协商……这中间有好几对大数运算和签名验证。移动端用户在地铁隧道里信号本来就弱，多一次往返，页面加载时间就多一个 RTT。我一个做手机银行的朋友跟我说，他们上线 Session Ticket 后，首屏加载时间降了 40%。
具体从三个维度看收益：
- 延迟：完整握手 2-RTT → 复用握手 0~1-RTT
- 服务端运算：省掉非对称加密（RSA/ECDHE），CPU 负载能降到原来的 1/5 甚至更低
- 连接密度：同样的服务器配置，复用后每秒能处理的连接数翻几倍
注意避坑：我曾经遇到过 Session ID 撞哈希导致服务端内存泄漏的问题——并发上去后，OOM 直接把实例打挂了。解决方案是加 LRU 淘汰 + 限制单 IP 的最大缓存数量。
4.3 会话复用的生命周期
不管是 Session ID 还是 Session Ticket，会话参数都是有寿命的。我记得刚接触时犯过一个错误：把会话超时时间设成了 24 小时，结果第二天早上上班，一堆客户端拿着过期的暗票来撞，服务端还得额外花时间验证失败再回退完整握手。
标准建议是：
- Session ID 超时：10~30 分钟
- Session Ticket 超时：1~8 小时（取决于安全策略）
- 同时配合最大缓存量限制（比如 50 万条）
# Nginx 配置示例：启用 Session Ticket
ssl_session_cache shared:SSL:50m; # 共享缓存，50MB
ssl_session_timeout 10m; # 超时 10 分钟
ssl_session_tickets on; # 开启 Session Ticket
ssl_session_ticket_key /etc/ssl/ticket.key; # 指定加密密钥文件
嗯，这里要注意：Session Ticket 的密钥必须定期轮换，否则一旦泄露，攻击者就能解密所有历史会话流量。我参与的一个网关项目里，我们每 4 小时换一次密钥，同时保留上一个密钥用于解密老票，保证平滑过渡。
4.4 安全权衡
会话复用虽然快，但安全上要做取舍。Session ID 依赖服务端内存，多实例部署时如果客户端被路由到不同节点，就得做会话同步；Session Ticket 把状态推到客户端，但加密密钥如果被窃，攻击者就能伪造会话。好在 TLS 1.3 通过 0-RTT 模式对 Ticket 做了更大的限制——只有幂等请求才允许重复用，非幂等请求强制走完整握手。
避坑指南：我曾经在微服务网关里发现，服务端同时开了 Session ID 和 Session Ticket，结果客户端优先用 Session ID（老浏览器行为），导致 Ticket 一直没用起来。解决方案是在配置里显式禁用 Session ID，强制客户端走 Ticket。具体要看你的用户代理分布。
总而言之，会话复用是现代 TLS 握手的核心优化手段。哪怕你只在 Nginx 里加两行配置打开 Ticket，压测数据都能让你眼前一亮。下一件事就是如何跟 OCSP Stapling 配合，把证书状态验证也一并优化掉——这个我们待会儿细聊。