直接测 tls 握手吞吐量需绕过 http 层，用 openssl s_time 测得每秒新建握手次数（如 328 次/秒），结合 wrk 关闭 keepalive 压测、日志字段 $ssl_session_reused 和 $ssl_protocol 分析复用率与协议降级，并通过 pidstat、openssl speed 和 stub_status 定位 cpu 不均衡、硬件加速失效或握手失败等瓶颈。
直接测 TLS 握手吞吐量，不能只压 HTTP 请求，得绕过应用层，聚焦在 TCP 连接建立 + TLS 握手完成这个原子过程。Nginx 本身不提供“每秒多少次完整握手”的内置指标，但可通过组合工具、日志字段和系统观测，真实反映极端压力下的 TLS 处理能力。
用 openssl s_time 做轻量级握手吞吐基准测试
这是最贴近底层、开销最小的实测方式，不走 HTTP 协议栈，只测 SSL/TLS 层：
- 命令示例：
openssl s_time -connect example.com:443 -new -time 30 -n 10000，表示 30 秒内发起 10000 次全新握手（-new 强制不复用） - 结果中关注 “handshakes done” 和 “avg time”：比如 9850 次 / 30s ≈ 328 次/秒，平均耗时 3.05ms，就代表当前配置下理论上限
- 注意加
-cipher 'ECDHE-ECDSA-AES128-GCM-SHA256'固定套件，排除协商开销干扰；若用 TLSv1.3，加-tls1_3
用 wrk 或 weighttp 配合 TLS 参数模拟真实 HTTPS 新建连接洪峰
这类工具能控制并发连接数和连接复用策略，更贴近业务场景：
- wrk 示例：
wrk -c 2000 -d 60s --latency -H "Connection: close" https://example.com/，关键加--latency并禁用 keepalive（-H "Connection: close"），确保每次请求都触发新握手 - 观察输出中的 Requests/sec（即 TPS），它实际就是“每秒完成的 HTTPS 握手+请求处理数”，若该值远低于 s_time 测出的握手吞吐，说明瓶颈不在 TLS 层，而在 Nginx 请求处理或后端
- 配合
ss -s | grep tls实时看 ESTABLISHED 连接数是否持续堆积，超过 5000 就需警惕短连接风暴
通过 Nginx 日志反推握手效率与复用率
在高并发压测中，日志里的两个字段是核心判断依据：
-
$ssl_session_reused：值为 0 表示全新握手，1 表示复用。压测后统计
awk '$12==0' ssl-debug.log | wc -l，若占比 >70%，说明会话缓存没生效或超时太短 - $ssl_protocol：大量出现 TLSv1.2 + RSA 套件，而服务器支持 TLSv1.3，说明客户端降级或服务端未强制启用——此时 TPS 会被拖累 30%~50%
- 建议日志格式含：
'$ssl_session_reused $ssl_protocol "$ssl_cipher" $request_time'，便于快速 awk 分析
结合系统指标确认 CPU 是否真成瓶颈
握手吞吐上不去，未必是算法慢，可能是资源没跑满：
- 运行
pidstat -u -p $(pgrep nginx) 1，看各 worker 进程 CPU 是否均衡；若单核打满而其他闲置，说明没配worker_cpu_affinity auto - 执行
openssl speed ecdhp256，对比本地 ECC 吞吐。若低于 3000 ops/sec，说明 AES-NI 或 OpenSSL engine 未启用，硬件加速失效 - 检查
stub_status输出：若handled ，说明握手失败率高，不是吞吐问题，而是证书链、OCSP 或协议兼容性故障
