Ubuntu 上 OpenSSL 性能优化实操指南
一 基线检测与硬件加速验证
- 检查 CPU 是否支持并启用 AES-NI：grep aes /proc/cpuinfo 应能看到 aes 标志。
- 对比开启/关闭 AES-NI 的吞吐，确认硬件加速生效：
- 开启：openssl speed -elapsed -evp aes-128-cbc
- 关闭：OPENSSL_ia32cap=“~0x200000200000000” openssl speed -elapsed -evp aes-128-cbc
在支持 AES-NI 的 Intel i5（如 T420） 上，开启后吞吐通常约为关闭时的2 倍。若未见到提升，需优先排查是否未启用 AES-NI、被错误编译或静态链接了不带加速的 OpenSSL 版本。
二 编译与链接优化
- 使用系统仓库的最新稳定版组件：sudo apt install openssl libssl-dev；避免自行编译后替换系统库导致生态不兼容或性能回退。
- 若必须自编译（如需要特定引擎/指令集），开启汇编与平台优化，并禁用不安全协议/套件：
- ./Configure linux-x86_64 shared enable-asm no-ssl3 no-tls1 no-tls1_1
- 可选：启用 enable-ec_nistp_64_gcc_128 等常数时间椭圆曲线优化；按需禁用弱算法（如 no-md2/no-rc4 等）。
- 链接策略：
- 动态链接便于系统级安全更新；静态链接便于分发但失去更新红利。
- 使用 CMake 时固定版本并链接 OpenSSL::SSL 与 OpenSSL::Crypto，确保运行时解析到优化后的实现。
三 服务端 TLS 配置优化（Nginx/Apache 等）
- 密码套件：优先 ECDHE + AES-GCM/CHACHA20，禁用低效/不安全套件：
- ssl_ciphers ECDHE+AESGCM:ECDHE+CHACHA20:DHE+AESGCM:DHE+CHACHA20:!aNULL:!MD5:!DSS;
- 协议版本：仅启用 TLSv1.2/1.3。
- 会话复用：开启共享会话缓存，显著降低握手开销：
- ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;
- 密钥长度：在相同安全等级下，RSA 2048 位通常较 4096 位有更好的性能/延迟折中，建议基准测试后选择。
- 变更后用基准工具与真实流量回归验证，避免因“套件过重”或“未启用加速”导致吞吐骤降。
四 内核与用户态加速路径
- 优先使用 CPU 指令集加速（如 AES-NI）；无需额外内核模块。
- 如需统一利用内核 CryptoAPI（如 IPsec、某些硬件引擎），可在用户态通过两种方式接入：
- Cryptodev：加载 cryptodev 内核模块后，重编译 OpenSSL 启用 CRYPTODEV 引擎，并使用 -engine cryptodev 测试；
- AF_ALG：使用 OpenSSL 的 AF_ALG 插件，基于内核 AF_ALG 接口（自 Linux 2.6.38 起提供），无需额外模块。
- 测试方法：openssl speed -evp aes-128-cbc -engine cryptodev -elapsed（Cryptodev 场景）。注意：启用内核路径可能引入额外上下文切换开销，实际收益依硬件与负载而定。
五 回归测试与常见陷阱
- 基准测试组合建议：
- 算法/引擎：openssl speed -elapsed -evp aes-128-cbc；对比 -engine cryptodev 与基线；
- 协议/套件：用实际客户端对 TLS1.2/1.3 与选定套件做吞吐/延迟压测（如 wrk/ab/自定义脚本）。
- 常见陷阱与排查：
- 错误编译或静态链接到“无 SIMD/无引擎”的 OpenSSL，导致 AES-NI 未被利用、吞吐显著下降；
- 套件过“重”（如仅启用高开销套件）或未启用会话复用，握手与 CPU 占用飙升；
- 自编译替换系统库引发依赖与性能回退，优先使用发行版提供的优化包，或在自编译后做 A/B 回归。