3. 会话复用策略：Session ID、Session Ticket的原理与配置

TLS握手为什么慢？说白了，就是公钥运算太费时间。尤其是RSA握手，服务端要做一次私钥解密，客户端要验证证书链，一来一回几百毫秒就没了。在高并发场景下，这开销扛不住。

我早年维护过一个电商平台，双十一流量峰值时，Nginx的CPU直接飙到90%。查了半天，发现一半以上的CPU时间花在了TLS握手上。后来上了会话复用，CPU直接降到40%。嗯，这就是我们今天要聊的东西。

3.1 会话复用的两种机制

TLS协议设计了两种复用方式：Session ID和Session Ticket。它们的目标一样——跳过完整的握手流程，但实现思路完全不同。

特性	Session ID	Session Ticket
存储位置	服务端内存/缓存	客户端（加密后）
服务端开销	高（需要维护会话缓存）	低（无状态）
扩展性	差（多节点需共享缓存）	好（无状态，天然支持水平扩展）
安全性	依赖服务端缓存安全	依赖Ticket密钥安全
TLS版本支持	1.0+	1.2+

3.2 Session ID：老派但可靠

Session ID是TLS 1.0就有的机制。第一次握手时，服务端生成一个32字节的随机ID，连同会话密钥一起存到自己的缓存里。客户端拿到这个ID后，下次重连时直接带上它。服务端一查缓存，ID对得上，就直接复用之前的密钥参数，跳过证书验证和密钥交换。

流程大致是这样：

ClientHello (携带Session ID)
    ↓
ServerHello (确认复用)
    ↓
ChangeCipherSpec
    ↓
Finished (直接使用之前的对称密钥)

你看，从7步握手变成了3步。省掉的是Certificate、ServerKeyExchange、ClientKeyExchange这些重量级步骤。

3.2.1 服务端配置（Nginx示例）

# 启用Session ID缓存
ssl_session_cache shared:SSL:10m;  # 10MB共享缓存，约能存40000个会话
ssl_session_timeout 10m;           # 会话超时时间

# 可选：设置Session ID的票据
ssl_session_tickets off;           # 先关掉Ticket，后面再讲

这里有个坑——shared:SSL:10m是Nginx worker进程间共享的。如果你用builtin模式，每个worker各存各的，负载均衡一转发，Session ID就失效了。我曾经踩过这个坑，排查了半天才发现是缓存模式没选对。

3.3 Session Ticket：无状态的优雅方案

Session Ticket是TLS 1.2引入的。它把会话状态加密后交给客户端保存。服务端不存任何会话数据，只保存一个Ticket密钥。客户端下次连接时把Ticket发回来，服务端解密验证通过就直接复用。

这解决了Session ID最大的痛点——水平扩展。你想想看，如果我有10台Nginx后端，Session ID需要Redis或Memcached共享缓存，而Session Ticket完全不需要。

3.3.1 Ticket密钥管理

Ticket密钥是Session Ticket的安全基石。密钥泄露，所有历史会话都能被解密。我见过有人把密钥写死在配置文件里，一用就是三年……

正确的做法：

• 定期轮换：每24小时换一次密钥
• 多密钥共存：保留上一周期的密钥用于解密旧Ticket
• 密钥分发：多节点间通过安全通道同步密钥

# Nginx配置Session Ticket
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ticket.key;

# 生成密钥（建议用cron定期执行）
# openssl rand 48 > /etc/nginx/ticket.key

3.4 两种机制的对比与选型

我整理了一张决策表，方便你根据场景选择：

场景	推荐方案	理由
单机部署	Session ID	简单，无需额外配置
多节点负载均衡	Session Ticket	无状态，天然支持水平扩展
兼容老旧客户端	Session ID	TLS 1.0/1.1不支持Ticket
高安全合规	Session ID + 共享缓存	密钥管理更可控
移动端/物联网	Session Ticket	减少服务端存储压力

3.5 会话复用的核心流程

下面这张图展示了两种复用方式的完整流程对比：

3.6 实战配置建议

最后，我结合多年经验，给出一套经过生产验证的配置模板：

# Nginx 完整会话复用配置
http {
    # Session ID 配置
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 10m;
    
    # Session Ticket 配置
    ssl_session_tickets on;
    ssl_session_ticket_key /etc/nginx/ticket.key;
    
    # 建议同时开启两种机制
    # 客户端优先使用Ticket，不支持则回退到Session ID
    
    server {
        listen 443 ssl;
        server_name example.com;
        
        ssl_certificate /etc/nginx/cert.pem;
        ssl_certificate_key /etc/nginx/key.pem;
        
        # 其他SSL配置...
    }
}

嗯，会话复用这块就讲到这里。记住一个原则：能复用就别重握。在复杂网络环境下，每一次完整的TLS握手都是对性能和用户体验的消耗。合理配置会话复用，往往是最简单、最有效的优化手段。