ssl_dhparam不提升性能，仅增强dhe密钥交换的前向保密性；它使握手延迟微增（2048位约0.5–2ms，3072位2–8ms），但保障了旧客户端降级连接的安全底线。
ssl_dhparam 本身不加密数据，也不直接提升性能，它只影响 TLS 握手阶段中 DHE 类密钥交换的强度与开销。它的核心作用是增强前向保密性，而非加速或减负——实际效果往往是轻微增加握手延迟和 CPU 消耗，但换来的是关键的安全保障。
为什么说“强度提升”不等于“性能提升”
很多人误把“更强 DH 参数”等同于“更好性能”，这是概念混淆。DH 参数位长（如2048/3072）决定的是离散对数问题的计算难度，位数越高，攻击者破解越难，但服务器生成临时密钥时的运算负担也越大：
- 2048 位：握手阶段 DHE 密钥计算耗时约 0.5–2ms（现代 CPU），兼容性好，满足 PCI DSS、等保2.0 等主流合规要求
- 3072 位：计算耗时上升至 2–8ms，抗算力升级能力更强，适合高安全场景；但对低配 VPS 或高并发短连接服务（如 API 网关）可能造成微小累积延迟
- 4096 位：极少采用——生成耗时数小时，运行时握手延迟可达 15ms+，且安全增益趋近于零，Nginx 加载时还易触发超时
真实性能影响主要体现在三个环节
不是“越长越好”，而是看实际链路瓶颈：
- 首次握手（Full Handshake）：DHE 密钥协商需实时计算，3072 位比 2048 位多消耗约 3–5ms CPU 时间；若站点大量使用 DHE 套件（非 ECDHE），该开销会放大
- 会话复用（Session Resumption）：启用 ssl_session_cache 后，后续连接跳过密钥交换，dhparam 不参与运算，此时无性能差异
- 证书加载与参数校验：Nginx 启动时读取 dhparam.pem 并验证 PEM 格式与质数有效性，3072 位文件体积略大（~1.2KB vs 2048 位的 ~0.8KB），但差异可忽略
真正影响性能的其实是套件选择逻辑
ssl_dhparam 只对 DHE 生效，而现代部署应优先依赖 ECDHE（椭圆曲线 DH）。这意味着：
- 只要 ssl_ciphers 显式优先排列 ECDHE 套件（如
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256），绝大多数客户端（Chrome/Firefox/iOS/Android 5.0+）都会协商 ECDHE，完全绕过 DH 参数运算 - ssl_dhparam 的实际运行负载，只落在仍坚持用 DHE 的旧客户端上：Java 7u80 以下、OpenSSL 1.0.1e、部分嵌入式设备或 IoT 固件——它们本就占比极低，且通常连接频次有限
- 换句话说：配置了强 dhparam，但只要 cipher suite 设计合理，它几乎不拖慢主流用户，却能守住那不到 5% 的降级连接防线
压测建议：别单独测 dhparam，要测完整握手链路
想评估真实影响，不能只跑 openssl dhparam -out ...，而应模拟端到端场景：
- 用
ab或hey发起 HTTPS 请求，对比开启/关闭 ssl_dhparam 时的time per request (mean)，注意控制变量（相同 cipher suite、TLS 版本、session cache 大小） - 在 Nginx 日志中启用
$ssl_handshake_time变量，统计不同客户端 User-Agent 下的握手耗时分布 - 观察
nginx -V输出是否含--with-http_ssl_module和 OpenSSL 版本（1.1.1+ 对 EC 运算有硬件加速优化，弱化 DH 影响）
