Nginx 中 TLS 优化如何在全站启用后评估网络吞吐量的提升效果

全站TLS优化效果评估需聚焦连接建立效率、CPU卸载程度、TTFB和长连接稳定性四维度：握手耗时P95应≤25ms，%us下降15–40%，ESTAB占比上升，且须配合keepalive/HTTP/2验证端到端收益。

全站启用 TLS 优化后，评估网络吞吐量提升效果不能只看“QPS 上涨了多少”，而要聚焦在连接建立效率、CPU 卸载程度、首字节延迟（TTFB）和长连接稳定性这四个可量化维度上。TLS 本身不加速数据传输，它加速的是连接建立与密钥协商过程——这部分开销在高频短连接或 HTTPS API 场景中占比极高。

重点观测连接建立阶段的吞吐贡献

TLS 握手是吞吐瓶颈最常发生的环节，尤其在客户端并发高、RTT 大（如跨地域访问）时。优化后应验证：

1. 用 openssl s_client -connect example.com:443 -reconnect -servername example.com 手动测试，对比优化前后“CONNECTED”到收到首个响应头的时间，下降 30%+ 属有效
2. 通过 Nginx 日志记录 $ssl_handshake_time（需开启 log_format 自定义字段），统计 P95 握手耗时：从 80ms 降至 25ms 以内，说明会话复用与 OCSP Stapling 已生效
3. 检查 ss -s 输出中的 SYN-RECV 和 ESTAB 比值：优化后 ESTAB 占比应明显上升，SYN-RECV 堆积减少，表明握手不再卡在队列里

验证 CPU 资源释放是否转化为并发能力

TLS 加解密占 CPU 是吞吐上不去的隐性原因。优化目标不是让 CPU 更“闲”，而是把省下的 cycles 转为更多并行连接处理能力：

1. 压测时监控 top -p $(pgrep nginx) 中 worker 进程的 %us（用户态）和 %sy（系统态）：SSL 优化后 %us 应下降 15–40%，且 QPS 在相同 CPU 使用率下提升
2. 对比开启 ssl_session_cache shared:SSL:10m 前后，在相同并发数下，worker_connections 的实际利用率（可通过 nginx_stub_status 的 Active connections / Accepts ratio 推算）是否更接近理论值
3. 若使用 OpenSSL 3.0+ 和支持 AES-NI 的 CPU，可用 openssl speed -evp aes-128-gcm 验证硬件加速是否启用；未启用时吞吐提升会受限

结合 keepalive 与 HTTP/2 看端到端链路收益

TLS 优化只有配合连接复用才能放大吞吐价值。单独提速握手，但每次请求仍新建连接，收益几乎归零：

1. 客户端侧确认：浏览器 DevTools → Network → Headers → 查看请求的 Connection 是否为 keep-alive，HTTP/2 或 HTTP/3 协议是否启用
2. Nginx 侧验证：在 upstream 对应 location 中启用 proxy_http_version 1.1 和 proxy_set_header Connection "" 后，用 ss -tnp | grep :backend_port 观察后端 ESTABLISHED 连接数是否稳定在 20–60（而非秒级波动）
3. 对比开启 http2_max_field_size 和 http2_max_header_size 合理值（如 16k）前后，大 header 场景（含 JWT、多 Cookie）下失败率是否下降，因 header 解析失败导致的重试会直接吃掉吞吐

排除干扰项，确认真实提升来源

很多“吞吐提升”其实是其他配置变更带来的，TLS 优化可能被掩盖或抵消：

1. 关闭 gzip 后再测：因为 gzip on 与 TLS 压缩存在叠加开销，且部分旧版本 OpenSSL 在启用压缩时会禁用会话缓存
2. 临时注释掉所有 add_header、sub_filter 和 auth_request 指令，避免它们引入同步阻塞，干扰 TLS 路径的纯性能表现
3. 确认未同时开启 ssl_buffer_size 过小（如 4k）：这会导致小响应被拆成多个 TLS 记录，增加加密调用次数，反而拉低吞吐；建议设为 8k 或 16k