Nginx Worker进程不直接加速SSL握手，而是通过会话复用、TLS 1.3协议、异步OCSP装订、高效密码套件及CPU绑定等协同优化，降低单次握手CPU开销、提升并发处理能力。
Nginx 的 Worker 进程本身不直接“处理”SSL握手的全部逻辑，而是通过 OpenSSL（或 BoringSSL/LibreSSL）库调用完成 TLS 协商；真正关键的是：Worker 如何高效、安全、可扩展地参与并卸载握手开销。核心不在“谁执行”，而在“怎么减负、怎么复用、怎么隔离”。
Worker 进程在 SSL 握手中的角色定位
- Worker 是事件驱动模型下的工作单元，每个 Worker 独立监听连接、接收 ClientHello、触发 OpenSSL 握手流程；
- 握手的密码学运算（如 ECDHE 密钥交换、证书签名验证、会话密钥生成）由 OpenSSL 在 Worker 进程内同步执行——这意味着CPU 密集型操作默认发生在 Worker 主线程中；
- 若未优化，高并发 HTTPS 请求会导致 Worker CPU 飙升、响应延迟上升、吞吐下降。
提升 Worker 处理 SSL 握手效率的三大方向
启用会话复用，减少全握手频率
全握手（Full Handshake）需 2-RTT（TLS 1.2）或 1-RTT（TLS 1.3），且含非对称加密运算；而复用可降为 0-RTT（PSK）或 1-RTT（Session ID / Ticket）。
- 使用共享内存缓存会话：
ssl_session_cache shared:SSL:10m;
（10MB ≈ 支持约 4 万个活跃会话，所有 Worker 共享，避免本地缓存分裂） - 启用 Session Ticket 并轮换密钥：
ssl_session_tickets on;ssl_session_ticket_key /etc/nginx/ticket.key;
（支持跨 Worker、跨进程甚至 Nginx 重启复用，比 Session ID 更灵活） - 设置合理超时：
ssl_session_timeout 4h;
（太短→复用率低；太长→内存积压；建议 2–8 小时，依业务会话特征调整）
卸载 CPU 密集型子任务，释放 Worker 主线程
- 开启 OCSP Stapling：
ssl_stapling on; ssl_stapling_verify on;resolver 8.8.8.8 valid=300s;
（OCSP 查询异步进行，结果缓存后随 ServerHello 一起 stapling 发送，避免每次握手都远程吊销检查） - 选用高效密码套件：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:...;
（禁用 RSA 密钥交换，优先 ECDHE + AEAD 加密，降低计算开销） - 强制 TLS 1.3：
ssl_protocols TLSv1.3;
（1-RTT、无 Server Key Exchange、内置前向安全，握手路径更短、更可靠）
配合系统层减少干扰，提升单 Worker 效率
- 绑定 Worker 到专用 CPU 核心：
worker_cpu_affinity auto;或显式指定（如worker_cpu_affinity 0001 0010 0100 1000;）
（减少上下文切换，提升 L1/L2 缓存命中率） - 调整
worker_processes数量：worker_processes auto;
（通常设为 CPU 物理核心数，避免过多 Worker 争抢 OpenSSL 共享资源） - 启用
http_v2和长连接：listen 443 ssl http2;keepalive_timeout 70;
（减少连接重建频次，间接降低握手总次数）
补充说明：为什么不能简单“多开 Worker”解决 SSL 压力？
因为 SSL 握手中的非对称运算（如 ECDSA 签名验签、RSA 解密）是强 CPU 绑定操作，不是 I/O 密集型任务。单纯增加 Worker 数量，反而可能加剧 OpenSSL 内部锁竞争（如 SSL_CTX_lock）、共享内存争用、以及 CPU 缓存失效，导致整体吞吐不升反降。真正有效的扩容方式是：单 Worker 更轻量 + 复用更充分 + 卸载更彻底。
不复杂但容易忽略。
