3、TLS会话复用技术：Session ID复用、Session Ticket机制、会话缓存与Ticket密钥轮换策略
聊到TLS连接优化，有一个话题绕不开——会话复用。
你想想看，一个完整的TLS握手，光是来回交换就要2-RTT（如果是首次连接，还得算上TCP的1-RTT）。如果每次请求都来一遍全握手，那延迟就太感人了。尤其在高并发场景下，服务端CPU光算非对称密钥就得烧掉一大截。
所以，TLS设计了一套复用机制。说白了就是：第一次握手完成后，把协商好的会话信息存起来，后续连接直接复用，跳过大部分计算和交互。
这套机制主要有两种实现方式：Session ID 和 Session Ticket。我一个个说。
3.1 Session ID 复用
这是最老牌的复用方式，从SSLv2时代就有了。原理很简单：
- 服务端在第一次握手时生成一个唯一的Session ID，发给客户端。
- 服务端自己把会话信息（密钥、加密套件等）存到本地缓存里。
- 客户端下次连接时，把Session ID带上。
- 服务端查一下缓存，如果ID还在，就直接跳过证书验证和密钥交换，进入加密通信。
嗯，这里要注意：Session ID复用的前提是服务端得有缓存。而且这个缓存是服务端本地的，不跨进程、不跨机器。
核心特点：
- 服务端需要维护会话缓存，占用内存。
- 不支持跨服务器复用（除非共享缓存，比如用Redis）。
- Session ID本身是明文传输的，但会话密钥是安全的。
我在项目中遇到过一个问题：某次压测时，服务端Session ID缓存设得太小，导致大量连接被迫走全握手。后来把缓存大小从默认的2万调到了10万，情况才好转。但内存也涨了不少，这是个trade-off。
3.2 Session Ticket 机制
Session ID的痛点很明显——服务端要存状态。对于分布式系统来说，这简直是噩梦。你想想，如果客户端两次请求落在不同的后端服务器上，Session ID就废了。
于是，Session Ticket 应运而生。它把会话信息加密后交给客户端保存，服务端自己不留状态。
流程大概是这样的：
- 第一次握手完成后，服务端生成一个Ticket（包含会话密钥等），用只有自己知道的密钥加密，发给客户端。
- 客户端保存这个Ticket（通常是Cookie形式）。
- 下次连接时，客户端把Ticket发回给服务端。
- 服务端解密Ticket，取出会话信息，直接复用。
说白了，就是把存储压力从服务端转移到了客户端。而且因为Ticket是加密的，客户端无法篡改，安全性有保障。
个人建议：如果你的服务是分布式部署，优先考虑Session Ticket。Session ID在单机场景下还行，但一旦上了负载均衡，就得搞共享缓存，麻烦得很。
3.3 会话缓存与Ticket密钥轮换策略
不管是Session ID还是Session Ticket，都涉及一个关键问题：缓存和密钥的管理。
3.3.1 会话缓存
对于Session ID，服务端需要维护一个缓存。这个缓存有几个参数需要关注：
| 参数 | 说明 | 建议值 |
|---|---|---|
ssl_session_cache |
缓存类型（内置/共享） | shared:SSL:10m |
ssl_session_timeout |
会话超时时间 | 5-10分钟 |
| 缓存大小 | 最多存储的会话数 | 根据并发量调整，一般几万到几十万 |
我曾经踩过一个坑：把 ssl_session_timeout 设成了1小时，结果缓存里堆积了大量过期会话，内存占用飙升。后来改成10分钟，配合合理的缓存大小，问题就解决了。
3.3.2 Ticket密钥轮换
Session Ticket的安全性完全依赖于服务端的加密密钥。如果这个密钥泄露了，所有历史会话都能被解密。所以，密钥必须定期轮换。
轮换策略一般有两种：
- 定时轮换：比如每24小时生成一个新密钥。旧密钥可以保留一段时间（比如1小时），用于解密还在有效期内的旧Ticket。
- 按需轮换：检测到安全事件时立即轮换。这个比较激进，但安全性更高。
注意：密钥轮换时，一定要保留上一代密钥。否则所有使用旧Ticket的连接都会失败，导致大量全握手，瞬间把服务端打垮。我曾经见过一个线上事故，就是因为轮换时直接丢弃了旧密钥，结果客户端全部重新握手，CPU直接飙到100%。
在Nginx中，配置Ticket密钥轮换大概是这样：
# 生成一个32字节的随机密钥
openssl rand 80 > ticket.key
# Nginx配置
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ticket.key;你可以准备多个密钥文件，按时间顺序加载。Nginx会自动使用最新的密钥加密，但会尝试用所有密钥解密。
3.4 两种机制的对比
| 特性 | Session ID | Session Ticket |
|---|---|---|
| 服务端状态 | 需要缓存 | 无状态 |
| 分布式支持 | 需要共享缓存 | 原生支持 |
| 安全性 | 依赖服务端缓存安全 | 依赖密钥安全 |
| 性能开销 | 查缓存（内存操作） | 加解密（CPU操作） |
| 客户端支持 | 几乎所有客户端 | 主流浏览器均支持 |
我个人更倾向于Session Ticket，尤其是在微服务架构下。但如果你用的是老旧的客户端（比如某些嵌入式设备），Session ID可能更稳妥。
3.5 核心流程图
下面这张图展示了两种复用机制的完整流程对比：
3.6 避坑指南
最后，分享几个我踩过的坑：
- Session ID缓存不要设太大：我曾经设了100M的共享缓存，结果内存占用高得离谱。后来根据并发量算了一下，10M就够用了。
- Ticket密钥轮换要保留旧密钥：前面说过，这个坑我踩过。建议保留至少2-3个历史密钥。
- 注意客户端兼容性：有些老旧的客户端不支持Session Ticket，会回退到Session ID。所以最好两种都开启。
- 监控复用率：如果发现复用率突然下降，可能是缓存满了或者密钥轮换出了问题。建议加上监控告警。
嗯，会话复用这块就聊到这儿。说白了，就是让TLS握手少跑几趟，省点时间省点电。但具体用哪种方式，得看你的架构和场景。