如何配置 ssl_session_cache 来开启 HTTPS 会话缓存复用 规避高并发下频繁握手的 CPU 算力黑洞

直接开启并配对合理的ssl_session_cache是规避高并发HTTPS握手CPU算力黑洞最有效手段，必须在http块顶层配置shared:SSL:10m、ssl_session_timeout 10m–4h（依场景）、ssl_session_tickets on及定期轮换的ticket.key，Linux支持shared而Windows仅支持builtin且需worker_processes 1。

直接开启并配对合理的 ssl_session_cache，是规避高并发 HTTPS 握手 CPU 算力黑洞最有效、最落地的手段。它不依赖协议升级或硬件扩容，而是让大多数连接跳过密钥交换、证书验证等密集计算，把完整握手（2-RTT）降为简短复用（1-RTT 或 0-RTT），实测可降低 TLS 层 CPU 消耗 60% 以上。

必须用 shared 缓存，且声明在 http 块顶层

builtin 缓存每个 worker 进程独占一份，无法跨进程共享——真实部署中连接被随机分发到不同 worker，复用率通常低于 5%，形同虚设。真正起作用的是进程间共享内存：

• 在 http{} 块开头统一写：ssl_session_cache shared:SSL:10m;（名称 SSL 不可省略，用于日志与监控标识）
• 10MB 可容纳约 4–8 万个会话（受证书链长度和 TLS 版本影响），适合日均百万级请求；峰值新建会话超 2000/sec 的场景建议直接设 20m 或按公式计算
• 严禁在多个 server{} 块里重复定义同名缓存，否则各站点互不共享，资源浪费且复用率归零

超时时间要匹配真实访问节奏，不是越长越好

默认 5m 太短，用户切网络、APP 后台唤醒、HTTP/2 空闲重连常已超时；但设成数小时又易滞留失效条目、挤占内存：

• 普通 Web 页面（含移动端）：推荐 ssl_session_timeout 10m 或 20m
• 内网 API 网关、可信后台系统：可设 4h，复用窗口更宽，实测延迟下降 40%+
• 高频短连接（健康检查、爬虫探测）：可压至 2m，配合更大缓存容量防淘汰

必须启用 session tickets 并轮换密钥

shared 缓存是服务端有状态存储，天然有容量瓶颈；session tickets 是无状态兜底机制——服务器加密生成票据下发给客户端，自身不保存会话数据：

• 开启：ssl_session_tickets on;
• 指定密钥文件：ssl_session_ticket_key /etc/nginx/ssl/ticket.key;
• ticket.key 必须是二进制文件，至少 32 字节（可用 openssl rand 48 > /etc/nginx/ssl/ticket.key 生成）
• 建议每月轮换一次密钥：生成新 key 后 reload Nginx，旧 ticket 仍可解密复用，新 ticket 自动启用新密钥，平滑无感

Linux 和 Windows 配置必须区分

系统能力决定你能不能用“共享”缓存，不能套用同一配置：

• Linux/Nginx：必须用 shared:SSL:10m，配合 ssl_session_timeout 和 ssl_session_tickets on
• Windows/Nginx：官方二进制版不支持 shared，若强行配置会启动报错 [emerg] invalid value "shared:SSL:10m"；只能用 builtin:1024，且必须设 worker_processes 1，避免多进程缓存隔离