mod_ssl性能损耗本质是OpenSSL在TLS各阶段对密码套件的CPU与延迟表现：握手阶段ECDHE最优，传输阶段AES-GCM或ChaCha20-Poly1305高效，签名推荐ECDSA，TLS 1.3显著提升性能。
Apache 的 mod_ssl 本身不执行加密运算，实际加解密由底层 OpenSSL（或 BoringSSL）完成。Java 应用与 mod_ssl 无代码耦合——前者走 JSSE，后者运行在 C 层反向代理环节。因此，“mod_ssl 对不同加密算法的性能损耗”本质是 OpenSSL 在 TLS 握手和数据传输阶段对各类密码套件的 CPU 消耗与延迟表现，需结合协议版本、密钥交换、对称加密和签名算法综合评估。
握手阶段：密钥交换算法决定首因开销
TLS 握手中的非对称运算最耗 CPU，影响新建连接延迟：
- ECDHE（椭圆曲线 Diffie-Hellman 密钥交换）：推荐首选。256 位曲线（如 secp256r1）计算快、安全性高，比同等强度 RSA 快 3–5 倍，且天然支持前向保密（PFS）
- RSA 密钥交换：已淘汰。需服务端用私钥解密预主密钥，CPU 占用高；不支持 PFS；TLS 1.3 已彻底移除
- DHE（传统 DH）：安全但慢。大素数模幂运算开销显著高于 ECDHE，尤其在高并发短连接场景下易成瓶颈
传输阶段：对称加密影响吞吐与延迟
会话建立后，数据加解密由对称算法承担，其效率取决于硬件支持与实现优化：
- AES-GCM（如 AES128-GCM-SHA256）：现代主流选择。支持硬件 AES-NI 指令集时吞吐极高，且认证加密（AEAD）免去额外 HMAC 计算
- ChaCha20-Poly1305：在无 AES-NI 的低端 CPU（如 ARM、旧 Intel Atom）上比 AES-GCM 更快，Google 和 Cloudflare 广泛采用
- CBC 模式套件（如 AES128-CBC-SHA）：已不推荐。需单独 HMAC 计算、易受填充预言攻击（POODLE），软件实现无加速，延迟明显更高
- RC4、3DES、DES：禁用。RC4 存在偏置漏洞；3DES 吞吐不足 AES 的 1/3，且密钥长度不足
签名算法：证书验证链中的隐性成本
客户端验证服务器证书时，需用公钥验签；若证书链含中间 CA，该过程逐级执行：
立即学习“Java免费学习笔记（深入）”；
- ECDSA 签名（如 ecdsa-with-SHA256）：256 位密钥即可达 RSA 3072 安全强度，验签速度快，证书体积小，减少网络传输与解析开销
- RSA 签名（如 rsa-with-SHA256）：广泛兼容，但 2048 位 RSA 验签比 ECDSA 慢约 2–4 倍；3072/4096 位更慢，且证书更大
- SHA-1 签名：禁用。已被证实可碰撞，多数浏览器直接拒绝
协议版本：TLS 1.3 是性能跃升关键
TLS 1.3 不仅移除了所有弱算法，更重构了握手逻辑：
- 默认 1-RTT 握手（比 TLS 1.2 的 2-RTT 减少一次往返），支持 0-RTT（对重复会话）
- 取消 RSA 密钥交换、CBC、压缩、重协商等历史包袱，精简密码套件列表，降低协商失败率
- 所有密钥交换均强制前向保密，所有加密均使用 AEAD，无额外安全裁剪成本
- 实测显示：相同硬件下，TLS 1.3 握手延迟比 TLS 1.2 低 30%–50%，QPS 提升约 15%–25%
不复杂但容易忽略
