如何优化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 个流，不代表后端能接住。如果 upstream 是 HTTP/1.1 + keepalive，默认单连接只处理 1 个活跃请求——你开了 256 个流，结果全挤在 1 条后端连接上排队，等于把队头阻塞从客户端搬到了 Nginx 和后端之间。

• 确认上游是否支持 HTTP/2：检查其 SETTINGS_MAX_CONCURRENT_STREAMS，不匹配会被 RST_STREAM
• 更稳的做法是配 proxy_http_version 1.1 + upstream keepalive 32，让 Nginx 复用固定数量的后端连接
• 压测时观察 stub_status 的 Writing 状态占比；持续高于 30%，说明后端响应慢，不是流数问题

该限制本质是防坏连接，不是扩容手段

设成 1000 看似“更宽松”，实则是放大单个恶意或缺陷客户端的杀伤力。HTTP/2 流不结束，Nginx 就得一直维护其缓冲区、窗口状态、优先级树——内存和锁竞争压力直线上升，worker 进程可能卡死。

• 默认 128 已覆盖绝大多数正常场景；电商详情页可试 192，但必须同步收紧 http2_idle_timeout 60s 和 http2_max_requests 1000
• 日志中搜 "max streams exceeded" 或 "stream not found"，能快速区分是客户端违规还是配置失当
• 用 perf top -p $(pgrep nginx) 看 ngx_http_v2_lookup_stream 占比，超 15% 就该查哈希表大小

真正卡住的从来不是流数上限，而是流背后的状态维护成本、后端承接能力、以及连接是否及时释放。调 http2_max_concurrent_streams 前，先看 http2_streams_index_size 配没配对、upstream keepalive 有没有、stub_status 里 Writing 高不高——漏掉任意一项，调了也白调。