如何配置 ssl_session_cache 开启会话复用 规避高并发 HTTPS 路径请求时频繁握手导致的 CPU 性能黑洞

开启会话复用需协同配置ssl_session_cache、超时策略与session tickets：cache须置于http块顶层共享，大小按真实新建会话速率×超时×0.5KB计算，tickets须启用并定期轮换密钥，超时应匹配业务重连特征。

开启会话复用不是加一行配置就能解决的事，关键在于让 ssl_session_cache、超时策略和 session tickets 三者匹配真实流量节奏。否则缓存形同虚设，CPU 该飙还是飙。

缓存必须声明在 http 块顶层，且只声明一次

shared 缓存要跨 worker 进程共享，只能写在 http { } 最外层，与所有 server 块并列。写进某个 server 里，就变成局部缓存，各 worker 互不可见，复用率基本为零。

• ✅ 正确写法：http { ssl_session_cache shared:SSL:20m; ssl_session_timeout 10m; }
• ❌ 错误写法：server { ssl_session_cache shared:SSL:20m; }（仅对该域名生效，且不跨进程）
• ❌ 更错写法：server { ssl_session_cache builtin:1024; }（每个 worker 自己维护，高并发下几乎无复用）

按真实新建会话速率算大小，别套默认值

不是看 QPS，而是统计每秒真正触发全新握手的连接数（Nginx 日志中 $ssl_session_reused 值为 n 的条目）。静态资源、CDN 回源、爬虫探测这类场景，新建会话速率常是 QPS 的 2–5 倍。

• 公式：缓存大小（MB）≈ 新建会话数/秒 × 超时秒数 × 0.5KB ÷ 1024
• 举例：CDN 回源峰值 3500 new/sec，超时设 600 秒（10 分钟），理论需约 820MB → 实际配 shared:SSL:512m + tickets 兜底更稳妥
• 小站点起步建议 10m，中高流量建议 20–30m；超大集群可上 50m，但要同步监控共享内存使用率

必须启用 ssl_session_tickets 并定期轮换密钥

仅靠 shared 缓存无法应对突发洪峰或客户端不支持 session ID 的情况（如微信内置浏览器、部分爬虫）。tickets 是无状态兜底：加密票据由客户端携带，服务端不存状态，天然支持跨 worker、跨重启、甚至跨机器（密钥同步后）。

• 开启：ssl_session_tickets on;
• 指定密钥：ssl_session_ticket_key /etc/nginx/ssl/ticket.key;（必须是二进制文件，至少 32 字节，可用 openssl rand 48 > ticket.key 生成）
• 轮换建议：每月 reload 一次新密钥，旧票据仍可解密复用，新连接自动使用新密钥，全程无感
• ⚠️ Windows 环境不支持 shared，只能设 worker_processes 1 + ssl_session_cache builtin:1024，并关闭 tickets（兼容性差）

超时时间要贴合业务访问特征

设太短（如默认 5 分钟），用户还没关页面就过期；设太长（如 4 小时），大量失效条目长期占位，挤占有效空间。应根据客户端典型重连窗口调整：

• Web 页面类（含浏览器刷新、标签切换）：推荐 ssl_session_timeout 10m
• 移动端 App 或长连接 API：可设 30m
• 高频短连接（健康检查、爬虫探测）：设 2m 更合适
• 启用 OCSP Stapling 或带长证书链时，单条开销可达 2–3KB，需按实测占用上调缓存大小