HTTP/2的多路复用与HPACK协同提升QPS：前者通过单连接并行处理降低建连与队头阻塞开销，短小API请求QPS可增20%～50%；后者压缩头部至原大小20%～40%，减轻TLS负载与带宽压力，但实际增益受后端能力、客户端支持及配置合理性制约。
HTTP/2 的头部压缩（HPACK）和多路复用（Multiplexing）是提升 Nginx 服务 QPS 的两个关键机制，但它们的影响方式不同：多路复用主要降低连接建立与队头阻塞开销，提升并发处理效率；头部压缩则减少单次请求/响应的字节量，缓解带宽与 TLS 加密负载。实际 QPS 提升幅度取决于具体场景，而非单纯开启 HTTP/2 就能显著增长。
多路复用如何影响 QPS
HTTP/1.1 每个 TCP 连接只能顺序处理一个请求（或依赖管线化，但浏览器普遍禁用），而 HTTP/2 允许在单个连接上并行发起多个请求和接收响应，避免了频繁建连、慢启动和队头阻塞问题。
- 对短小、高并发的 API 请求（如微服务间调用），QPS 可提升 20%～50%，尤其在高延迟网络中更明显
- 对大文件下载或长轮询类请求，收益有限，因带宽或后端处理成为瓶颈
- Nginx 默认启用多路复用，无需额外配置；但需确保
http2_max_concurrent_streams设置合理（默认 128，可按业务峰值适当调高） - 客户端支持至关重要——若大量旧设备（如 Android 4.x、IE11）仍占流量，真实增益会被稀释
HPACK 头部压缩的实际效果
HPACK 通过静态表 + 动态表 + 哈夫曼编码压缩 HTTP 头部，典型请求头（含 Cookie、User-Agent、Authorization 等）可压缩至原始大小的 20%～40%。
- 在 TLS 场景下，压缩直接减少加密/解密的数据量和网络传输字节数，间接降低 CPU 和 RTT 开销
- 对 header 较大的场景（如带长 JWT Token 或多段 Cookie）收益更明显；纯静态资源（header 极简）几乎无压缩空间
- Nginx 内置 HPACK 支持，无需手动开启；但注意
http2_max_field_size和http2_max_header_size应略大于业务最大 header 长度，否则触发 431 错误 - 动态表在连接生命周期内维护，不跨连接共享，因此对连接复用率低的场景（如移动端短连接）压缩率会下降
协同效应与常见瓶颈
多路复用与 HPACK 在 HTTP/2 中协同工作，但 QPS 最终受限于更底层的瓶颈：
- 后端应用处理能力（如 PHP-FPM worker 数、数据库连接池）未提升时，Nginx 层优化无法突破整体吞吐上限
- TLS 握手开销仍存在——建议启用 TLS 1.3 + 0-RTT（需客户端支持）+ OCSP Stapling，进一步释放 HTTP/2 潜力
- 过度提高
http2_max_concurrent_streams可能导致单连接内存占用上升（每个 stream 约占用数 KB），在高并发下增加 Nginx 内存压力 - 务必关闭 Nginx 的
http2_idle_timeout过短设置（默认 3m），避免客户端因空闲断连而频繁重连，抵消多路复用优势
验证与调优建议
不要仅依赖理论，应结合真实链路测量：
- 用
curl -I --http2 https://your.site/确认协议协商成功；用 Chrome DevTools 的 Network → Protocol 列观察是否全量使用 h2 - 对比开启 HTTP/2 前后，用 wrk 或 vegeta 对相同接口压测（固定连接数、总请求数），关注 QPS、P95 延迟、TLS handshake time 和 Nginx 的
http2_streams_active指标 - 检查 Nginx error log 是否出现
client sent DATA frame for closed stream类警告，可能提示客户端兼容性问题 - 对于 CDN 或中间代理（如某些 WAF），确认其完整支持 HTTP/2 并透传，否则降级为 HTTP/1.1
