选对加密套件可兼顾https安全性与tls握手效率。需优先启用tls 1.3（1-rtt）、合理回退至tls 1.2，按硬件选aes-gcm或chacha20-poly1305，强制ecdhe前向保密，精简至5–7个高安全套件，并配合会话缓存与tickets实现0-rtt复用。
选对加密套件，能同时提升 HTTPS 安全性与 TLS 握手效率。关键不是堆砌“最强算法”，而是匹配硬件能力、客户端分布和业务场景。
优先启用 TLS 1.3 并合理回退
TLS 1.3 握手只需一次往返（1-RTT），大幅降低延迟。但需确保 OpenSSL ≥ 1.1.1 且客户端覆盖率足够高（当前主流浏览器均支持）。配置时明确启用 TLSv1.2 和 TLSv1.3，并禁用旧协议：
- ssl_protocols TLSv1.2 TLSv1.3;
- 禁用 SSLv3、TLSv1、TLSv1.1（已淘汰）
- 避免仅保留 TLSv1.3——部分企业内网设备或老旧系统仍依赖 TLSv1.2，直接禁用会导致连接失败
按硬件特性选择高效算法组合
现代 CPU 普遍支持 AES-NI 指令集，AES-GCM 加解密性能远优于软件实现的 ChaCha20；而移动设备或低功耗 ARM 芯片则更适配 ChaCha20-Poly1305。
- 服务器为 Intel/AMD x86_64：优先排布 AES128-GCM-SHA256、AES256-GCM-SHA384
- 面向大量移动端用户（如 App 后端）：在前面加入 CHACHA20-POLY1305 套件，提升弱硬件设备的首包响应速度
- 始终开启 ssl_prefer_server_ciphers on，防止客户端强行选用低效或不安全套件
强制前向保密（PFS）并精简套件列表
所有套件必须基于 ECDHE 密钥交换，确保即使私钥泄露，历史通信也无法被解密。同时减少候选数量，缩短协商时间。
- 剔除非 PFS 套件（如 RSA 密钥交换类）、已知弱算法（RC4、MD5、SHA1、3DES）
- 保留 5–7 个高安全性、高兼容性组合即可，例如：
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-GCM-SHA384 - 避免使用 !aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA 这类模糊排除，易遗漏边缘风险
配合会话复用机制降低握手开销
再优的套件也无法绕过完整握手的计算成本。真正降延迟靠的是复用已有会话参数。
- 启用共享内存缓存：ssl_session_cache shared:SSL:10m（支持多 worker 进程复用）
- 延长超时时间：ssl_session_timeout 4h（比默认 5m 更适合中长连接业务）
- 叠加 Session Tickets：ssl_session_tickets on，让客户端本地缓存会话票据，实现 0-RTT 恢复（注意密钥轮换策略）
