nginx不参与websocket数据帧加解密，仅负责tls终止、http upgrade切换和长连接代理；真实加密开销在客户端与nginx之间，吞吐瓶颈多源于连接管理、代理转发或后端处理。
直接在 Nginx 层测试 WSS 的吞吐与加密开销不现实，因为 Nginx 本身不参与 WebSocket 数据帧的加解密——它只做 TLS 终止（即卸载 SSL），后续 ws 流量走明文转发给后端。真正的加密开销发生在客户端与 Nginx 之间，而吞吐瓶颈往往出现在连接维持、代理转发或后端处理环节。所以测试重点应是：验证 WSS 握手成功率 + 长连接稳定性 + 端到端有效吞吐，而非单独剥离“Nginx 的加密耗时”。
明确测试目标和边界
WSS 场景下，Nginx 不加密数据帧，只负责：
- TLS 握手（含证书校验、密钥交换）
- HTTP Upgrade 协议切换（101 响应）
- 长连接代理（保持 TCP 连接，透传帧）
- 后端 ws:// 转发（无 TLS 开销）
因此，所谓“加密开销”实际是客户端 ↔ Nginx 的 TLS 层开销；“吞吐”取决于并发连接数、消息频率、帧大小、proxy_read_timeout 设置及后端响应能力。
用 wrk + websocket 插件测握手与连接建立性能
wrk 本身不支持 WebSocket，需配合 Lua 脚本或改用专用工具：
- 推荐使用 autocannon（Node.js）或 wrk2 配合 WebSocket Lua 模块，发起大量 wss:// 连接请求
- 脚本中模拟真实行为：建连 → 发送 Sec-WebSocket-Key → 等待 101 → 发送小帧 → 保持连接 30s+
- 关注指标：连接建立成功率、平均 handshake time（TLS + HTTP Upgrade 总耗时）、失败连接是否集中在 handshake 阶段
- 对比测试：相同压测参数下，wss:// vs ws://（绕过 Nginx 直连后端），差值可近似反映 TLS 握手开销
用真实业务流量+监控定位瓶颈
单纯工具压测易失真。更可靠的方式是结合生产级观测：
- 开启 Nginx access_log 与 error_log，添加
$upstream_response_time $request_time $status，筛选 101 响应行，统计握手延迟分布 - 用 nginx-module-vts 或 Prometheus + nginx-exporter 监控活跃连接数、每秒新建连接、upstream queue 时间
- 检查系统层：
ss -s查 ESTAB 连接总数，netstat -s | grep -i "retransmit"看重传率，高重传说明网络或 TLS 参数（如 TLS record size）不合理 - 后端日志同步打点：记录从收到 Upgrade 请求到返回 101 的耗时，排除后端阻塞导致的假性“Nginx 加密慢”
针对性调优与验证项
影响 WSS 高并发表现的关键配置不是加密算法本身，而是连接生命周期管理：
- proxy_read_timeout 必须足够大（如 86400），否则空闲连接被 Nginx 主动断开，引发客户端频繁重连
- ssl_buffer_size 设为 4k 或 8k，避免小帧拆成多个 TLS record，降低 CPU 和延迟
- ssl_session_cache shared:SSL:10m + ssl_session_timeout 4h，复用会话减少完整 TLS 握手次数
- 启用 ssl_early_data on（需 TLS 1.3）和 ssl_stapling on，缩短首字节时间
- worker_connections 和 worker_rlimit_nofile 需匹配预期最大连接数（例如 10 万连接，至少设为 102400）
