如何优化Nginx的http2_max_concurrent_streams以平衡单连接并发度与服务器内存开销？

本文共计825个文字，预计阅读时间需要4分钟。

直接调高 `http2_max_concurrent_streams` 不会提升实际并发性能，反而容易引发内存暴增和CPU查找开销；它只是为单个 HTTP/2 连接设置了流数上限，真实瓶颈往往在后台的吞吐、哈希表大小或连接生命周期管理上。

为什么设成 256 反而让 Chrome 加载变慢

浏览器确实会尝试在一个连接里并行发 200+ 请求（比如画廊页加载高清图），但 Nginx 并不只靠这个值“放行”。若同时没调大 http2_streams_index_size，每个连接的流索引哈希表太小，就会频繁哈希冲突——ngx_http_v2_lookup_stream 函数 CPU 占比飙升，请求卡在查找阶段，页面反而更卡。

• 设 http2_max_concurrent_streams 为 256 时，http2_streams_index_size 至少得配成 128 或 256（必须是 2 的幂）
• 每连接内存开销 ≈ http2_streams_index_size × 8 字节；128 → 约 1 KB，1 万并发连接就多占 10 MB
• Chrome DevTools 中看到多个请求共享同一 Connection ID 且协议列为 h2，才说明多路复用真在跑；否则只是“假 h2”

后端不支持 HTTP/2 时，调这个参数毫无意义

反向代理场景下，Nginx 能开 256 个流，不代表后端能接住。