高并发HTTPS下TLS性能瓶颈在于握手频次与计算位置，核心是启用TLS1.3、双会话复用、CPU亲和及OCSP装订：ssl_protocols TLSv1.2 TLSv1.3；ssl_session_cache shared:SSL:10m；worker_cpu_affinity auto；ssl_stapling on。
高并发 HTTPS 场景下，TLS 加密计算性能瓶颈不在“加不加密”，而在“怎么加、加几次、在哪加”。核心思路是：用 TLS 1.3 减少握手开销，靠会话复用跳过重复计算，借 CPU 亲和锁定缓存热度，再配合系统级资源释放，让高强度加密不拖慢吞吐。
启用 TLS 1.3 并精简密码套件
TLS 1.3 握手只需 1-RTT，CPU 开销比 TLS 1.2 低 30%～50%，且默认强制前向保密。必须禁用老旧协议：
- 在 http 或 server 块中配置：
ssl_protocols TLSv1.2 TLSv1.3; - 确保 Nginx ≥ 1.13.0、OpenSSL ≥ 1.1.1，否则 TLS 1.3 不生效
- 只保留现代硬件加速友好的 AEAD 套件：
ssl_ciphers 'TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-CHACHA20-POLY1305'; - 添加曲线与签名算法约束，缩短协商路径：
ssl_conf_command Curves X25519:secp256r1;ssl_conf_command SignatureAlgorithms ecdsa_secp256r1_sha256:rsa_pss_rsae_sha256;
强制双会话复用机制
完整 TLS 握手需执行椭圆曲线运算，耗时高；复用可跳过密钥交换和证书验证，实测延迟下降超 70%：
- 在 http 块顶层配置共享缓存：
ssl_session_cache shared:SSL:10m;（不能写在 server 内） - 设合理超时：
ssl_session_timeout 4h;（适配移动端间歇访问，远高于默认 5 分钟） - 开启 Session Tickets 并轮换密钥：
ssl_session_tickets on;+ssl_session_ticket_key /etc/nginx/ticket.key; - 若后端也走 HTTPS（如微服务代理），加：
proxy_ssl_session_reuse on;
开启 CPU 亲和性与系统级协同调优
HTTPS 加密高度依赖 L1/L2 缓存和 TLB 热度，进程跨核迁移会导致缓存失效、分支预测重置、内存延迟激增：
- 配置
worker_processes auto;+worker_cpu_affinity auto; - 提升文件描述符上限：
worker_rlimit_nofile 100000;，并同步修改/etc/security/limits.conf和 systemd 的LimitNOFILE - 启用 TCP Fast Open：
net.ipv4.tcp_fastopen = 3（需客户端支持，加速三次握手） - 验证是否生效：运行
ps -eo pid,psr,comm | grep nginx，确认 worker PID 与 PSR（CPU 核心号）严格一一对应
启用 OCSP Stapling 消除证书验证阻塞
客户端直连 CA 查询吊销状态常卡顿 150–300ms；Nginx 主动装订可绕过该网络依赖：
- 四项配置必须同在 443 server 块中：
ssl_stapling on;ssl_stapling_verify on;ssl_trusted_certificate /path/to/full-chain-trusted.pem;（含中间 CA + 根 CA）resolver 1.1.1.1 8.8.8.8 valid=300s; resolver_timeout 2s; - 确保
ssl_certificate和ssl_trusted_certificate路径正确，否则 stapling 会静默失败
