评估nginx处理http/2的并发请求能力，须验证多路复用、头部压缩、连接复用是否真实生效，重点检查并发流稳定性、隐性降级及rps与延迟是否优于http/1.1；需通过alpn抓包、h2协议标识确认、长连接压测、日志流id分析及全链路业务指标比对综合判断。
评估 Nginx 处理 HTTP/2 的并发请求能力，不能只看“协议是否开启”，而要验证多路复用、头部压缩、连接复用等核心机制在真实压力下是否生效。重点是确认并发流（streams）能否稳定承载、是否被隐性降级、以及实际 RPS 和延迟是否优于 HTTP/1.1。
确认 HTTP/2 协商真实生效
压测前必须排除“假启用”：很多环境因 ALPN 配置缺失、中间设备拦截或客户端不支持，导致静默回退到 HTTP/1.1。
- 用 curl -I --http2 https://yourdomain.com 检查响应头是否明确显示 HTTP/2 200
- Chrome DevTools → Network → 右键表头勾选 Protocol，确认所有资源请求显示为 h2
- 抓包验证 TLS 握手阶段的 ALPN 协商：tshark -i any port 443 -Y "tls.alpn" -T fields -e tls.alpn.protocol，输出应为 h2
设计贴近 HTTP/2 特性的压测场景
HTTP/2 的优势体现在单连接多流、头部压缩和服务器推送（若启用），普通短连接压测无法反映其真实能力。
- 用 wrk -t8 -c200 -d60s --latency -H "Connection: keep-alive" https://yourdomain.com/ 模拟长连接+多流，-c200 表示维持 200 个 TCP 连接，每个连接内自动发起多个并发 stream
- 对比相同参数下 HTTP/1.1（curl --http1.1 或禁用 h2 配置后重测），观察 RPS 提升幅度——若无明显提升，说明多路复用未起效，可能因 upstream 不支持、large_client_header_buffers 过小触发帧拆分，或客户端限制了并发流数（如 Chrome 默认 max concurrent streams = 100）
- 加入大 Header 场景（如含 JWT Token 的请求），检查日志中 $http2 是否仍为 h2，并比对请求头字节数：HPACK 压缩应使 header 体积下降 60% 以上
监控连接与流级关键指标
HTTP/2 的瓶颈常藏在 stream 生命周期管理、idle timeout 设置或帧控制参数上，需结合日志与系统指标定位。
- 在 log_format 中加入 $http2 $http2_stream_id $upstream_http2，例如：
log_format http2log '$remote_addr [$time_local] "$request" $status $http2 $http2_stream_id $request_time $upstream_response_time'; - 压测中统计各连接的 stream 数量：awk '{print $6}' access.log | sort | uniq -c | sort -nr，若大量 stream ID 集中在低值（如 1–3），说明客户端未开启多路复用或服务端过早关闭连接
- 检查 error.log 是否出现 "stream ID is too large" 或 "client closed connection while waiting for request"，前者指向 stream 数超限（需调大 http2_max_concurrent_streams），后者常因 keepalive_timeout 或 http2_idle_timeout 过短导致连接被主动断开
分层比对全链路响应质量
HTTP/2 的性能收益最终要落在业务指标上，而非协议层面的数字。
- 用 WebPageTest 或 Lighthouse 对同一页面分别走 HTTP/1.1 和 HTTP/2，重点关注：TTFB 是否降低、资源请求数是否突破浏览器 6 连接限制、首屏完成时间是否缩短
- 对比 Nginx stub_status 输出：Active connections 数量是否显著低于 HTTP/1.1 场景（体现连接复用效果），同时 Reading/Writing/Waiting 状态分布是否更均衡（避免 Waiting 长期堆积，表明后端响应拖慢了 stream 处理）
- 若启用 http2_push，需单独压测推送资源命中率与缓存复用率，避免因推送冗余内容反而增加带宽和延迟
