OpenSSL 在 Linux 下的 SSL/TLS 性能优化
一 硬件与基础环境优化
- 启用 CPU 指令集加速：优先使用支持 AES-NI 的 CPU，可显著加速 AES-GCM 等对称加密；使用命令
grep -o aes /proc/cpuinfo | wc -l 检查是否支持。若输出大于 0，说明已启用 AES-NI。
- 选择高效证书：在相同安全强度下，优先 ECDSA P-256 证书（证书更小、握手计算更轻），必要时与 RSA 证书并存以兼容旧客户端。
- 升级到新版本：保持 OpenSSL ≥ 1.1.1 / 3.x，可获得协议与性能改进（如 TLS 1.3、更快椭圆曲线与 AEAD 实现）。
- 可选硬件加速：在具备 QAT 等加速卡时，配置 OpenSSL 引擎（如 QAT engine）以卸载 RSA/ECDSA/AES-GCM 计算，降低 CPU 占用。
二 协议与密码套件优化
- 协议优先：启用 TLS 1.3（仅需 1-RTT 握手），同时按需保留 TLS 1.2 以兼容旧客户端。
- 套件策略：优先前向安全（ECDHE），移动端优先 ChaCha20-Poly1305，高安全场景选 AES-256-GCM，兼容性兜底选 ECDHE-ECDSA-AES128-GCM。示例（Nginx）：
ssl_protocols TLSv1.3 TLSv1.2;ssl_ciphers TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256;ssl_prefer_server_ciphers on;
- 证书与签名：优先 ECDSA 证书；若使用 RSA 证书，确保密钥长度 ≥ 2048 位。
- 会话恢复：启用 Session Tickets 或 Session ID 复用，减少完整握手次数；Nginx 示例：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 1h; ssl_session_tickets on;
- 0-RTT 谨慎启用：仅用于幂等请求（如 GET /health），避免 POST /pay 等非幂等场景，降低重放风险。
三 证书验证与会话复用优化
- OCSP Stapling：服务端预取并缓存 OCSP 响应，在握手时随证书一并返回，避免客户端外链查询，降低握手延迟。Nginx 示例：
ssl_stapling on; ssl_stapling_verify on; resolver 8.8.8.8 valid=300s;
- 会话复用：结合 Session Tickets 与 Session ID，在短连接/高并发场景显著降低握手开销与 CPU 压力。
四 系统与网络栈优化
- TCP 快速打开：启用 TCP Fast Open（TFO） 减少握手往返后的首包等待。
- 缓冲区与队列：适度增大网络缓冲与队列（如
net.core.netdev_max_backlog），提升高并发下连接接收能力。
- 端口与 TIME_WAIT 复用：开启 net.ipv4.tcp_tw_reuse，加速连接回收与复用。
- 持续监控：使用
top/mpstat/pidstat 观察 CPU、软中断与上下文切换；用 openssl s_client 验证协议与套件，用 wrk 进行吞吐与延迟压测。
五 验证与压测步骤
- 协议与套件验证：
openssl s_client -connect api.example.com:443 -tls1_3- 输出应含：
Protocol : TLSv1.3 与目标套件（如 TLS_AES_256_GCM_SHA384）。
- 抓包分析：用 Wireshark 过滤
tls.handshake，确认 TLS 1.3 的 1-RTT 握手、key_share 扩展与证书链完整性。
- 吞吐与延迟压测：
wrk -t4 -c100 -d30s https://api.example.com/data（对比 TLS 1.2/1.3 的 QPS 与延迟）。
- 引擎与硬件加速检查：
openssl engine -t -c 查看可用引擎与状态，确认 AES-NI/QAT 是否被调用。