优化 TLS 握手 CPU 亲和力本质是稳定 worker 进程与 CPU 核心绑定，减少跨核调度开销；需配合 worker_cpu_affinity auto、ssl_session_cache shared:SSL:10m（置于 http 块顶层）、ssl_session_timeout 4h、TLS 1.3 及精简密码套件，方能协同提升复用率与握手吞吐。
优化 TLS 握手阶段的 CPU 亲和力，本质不是让“握手本身”绑定 CPU，而是让处理 TLS 连接的 worker 进程稳定运行在指定核心上，减少跨核调度、缓存失效和上下文切换开销——这对高并发 HTTPS 场景下的握手吞吐量提升非常关键。
确保 worker 进程与 CPU 核心一对一绑定
Nginx 的每个 worker 进程独立处理连接（含 TLS 握手），若频繁在不同 CPU 核心间迁移，L1/L2 缓存无法复用，ECDHE 密钥计算、证书验证等高频操作会反复加载数据，显著拖慢握手速度。
- 启用自动亲和：直接配置 worker_cpu_affinity auto;（Nginx ≥ 1.9.10），系统会为每个 worker 分配独立核心，8 核服务器即启动 8 个 worker 并分别绑定到 CPU0–CPU7
- 手动精确绑定（适合混合负载场景）：例如 4 核服务器可写 worker_cpu_affinity 0001 0010 0100 1000;，避免多个 worker 挤占同一核心
- 必须配合 worker_processes auto;，否则亲和配置无效；不建议硬编码数字（如 worker_processes 4），以免 CPU 核数变更后失配
把 TLS 计算密集型任务“稳住”在本地缓存路径上
CPU 亲和力要起效，还需确保 TLS 相关计算真正受益于本地缓存——这依赖会话复用机制与内存访问局部性协同。
- ssl_session_cache 必须声明在 http 块顶层，如 ssl_session_cache shared:SSL:10m;，否则各 worker 自建私有缓存，复用率归零，大量完整握手被迫重复执行椭圆曲线运算
- 共享缓存命中时，密钥交换、证书校验等步骤被跳过，CPU 负载下降 70% 以上；而 cache 未命中时，绑定再好也得硬算——所以亲和力是“加速器”，不是“替代品”
- 搭配 ssl_session_timeout 4h;，延长复用窗口，尤其适配移动端后台唤醒、HTTP/1.1 短连接等真实场景，让缓存更“值得”被本地化
配合 TLS 协议与密码套件精简，降低单次握手计算深度
即使绑定了 CPU，若每次握手仍做 RSA 4096 签名或 DHE 密钥交换，单核吞吐很快见顶。CPU 亲和力需要轻量级握手来发挥价值。
- 强制启用 TLS 1.3：ssl_protocols TLSv1.2 TLSv1.3;，它将握手压缩为 1-RTT，省去 ServerKeyExchange 和 CertificateVerify 等高开销步骤
- 限定高效 AEAD 套件：ssl_ciphers 'TLS13-AES-128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256';，禁用 RSA 密钥交换、3DES、CBC 模式等老旧低效算法
- 关闭服务端票据：ssl_session_tickets off;（除非需应对突发流量兜底），避免额外 AES 加解密开销，让 CPU 更专注在复用路径上
验证是否真正生效
配置完成后，不能只看 top 显示 CPU 使用率下降——要确认优化落在 TLS 握手路径上。
- 检查 worker 绑定状态：运行 ps -eo pid,comm,psr | grep nginx，观察各 worker 进程是否长期固定在某一个 CPU ID 上
- 统计握手类型：开启 ssl_handshake_log 或通过 openssl s_client -connect your.site:443 -tls1_3 测试，确认协商结果为 TLS 1.3 + ECDHE
- 监控复用率：Nginx 日志中加入 $ssl_session_reused 变量，统计 “r”（reused）占比，理想应 > 85%；若低于 60%，说明 session cache 配置位置或大小仍有问题
