启用AES-NI硬件加速并精简ssl_ciphers为AEAD+PFS子集是最有效的静态站点HTTPS性能优化组合，可显著降低加解密开销、减少握手次数并提升CPU指令效率。
直接启用硬件加速 + 精简 ssl_ciphers 是提升静态站点 HTTPS 性能最有效的组合手段。关键不是堆算法，而是让 CPU 少干活、让硬件多分担——特别是 AES-NI 这类内建指令集，能把对称加解密开销压到接近零。
确认并启用 AES-NI 硬件加速
Nginx 本身不直接控制 AES-NI，它依赖底层 OpenSSL 是否启用该特性。需两步验证：
- 检查 CPU 是否支持：
grep -m1 -o aes /proc/cpuinfo—— 有输出即支持 - 确认 OpenSSL 已编译启用：
openssl version -a | grep -i "aesni\|engine"，若含aesni或显示enable-ec_nistp_64_gcc_128类标志，说明已就绪 - 无需额外配置 Nginx，只要 OpenSSL 版本 ≥1.0.2（推荐 ≥1.1.1），AES-GCM 套件会自动走 AES-NI 路径
ssl_ciphers 必须锁定 AEAD + PFS 的最小安全子集
硬件加速只对特定算法生效。AES-GCM 和 CHACHA20-POLY1305 可被 AES-NI 或 CPU 向量单元加速；而 CBC、RC4、3DES 等不仅慢，还无法被现代硬件优化。因此要主动剔除所有非 AEAD 套件：
- 推荐精简配置（兼顾 TLS 1.2 兼容性）：
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; - 完全放弃 DHE、CHACHA20（后者无 AES-NI 加速）、以及任何含
CBC、SHA1、MD5、3DES的套件 - 搭配 ssl_protocols TLSv1.2 TLSv1.3，TLS 1.3 默认仅用 AEAD 套件，无需再设 ssl_ciphers
配合会话复用与零拷贝减少上下文切换
加密只是瓶颈之一。静态文件服务中，I/O 和内存拷贝常比加解密更耗时：
- 启用高效会话缓存：ssl_session_cache shared:SSL:50m; ssl_session_timeout 4h; —— 减少 70%+ 的完整握手次数
- 开启 sendfile on; 和 tcp_nopush on;，让内核直接从磁盘页缓存发送加密后数据，绕过用户态内存拷贝
- 若部署在 openEuler 等优化系统上，可进一步启用 io_uring（需 Nginx ≥1.21.0 + 内核 ≥5.10），将 SSL 加密与文件读取异步协同
验证是否真正跑在加速路径上
不能只看配置生效，要实测确认硬件在工作：
- 用
openssl speed -evp aes-128-gcm对比启用/禁用 AES-NI 时的吞吐差异（通常差 3–5 倍） - 压力测试时监控
perf stat -e cycles,instructions,cache-misses -p $(pgrep nginx)，若 instructions/cycle 接近 2–3，说明流水线饱满，AES-NI 正在满载运行 - 对比相同 QPS 下的 CPU 使用率：启用优化后，nginx worker 进程的用户态 CPU 应下降 40% 以上（尤其在高并发小文件场景）
