HTTP/2窗口与缓冲区调优需匹配真实流量特征，而非盲目调大：http2_max_concurrent_streams建议大图站设256–512、API网关设384；http2_max_field_size和http2_max_header_size分别设16k、64k防414错误；配合ssl_buffer_size 16k、keepalive_timeout 300s及系统级TCP缓冲优化，并通过Chrome DevTools或curl验证h2实际生效率。
HTTP/2 的窗口大小与缓冲区调优，核心不是“改大就行”，而是匹配真实流量特征——尤其是大图、API 聚合、含 JWT 或追踪头的请求场景。盲目调高可能引发内存压力或流控异常，需在 TLS 层、帧层、连接层协同调整。
关键窗口参数：http2_max_concurrent_streams 与流控窗口
Nginx 默认 http2_max_concurrent_streams 128，对普通站点足够，但大型图片站或前端微服务聚合页（单页发起 200+ 请求）易触发流拒绝或延迟。建议按业务类型分级设置：
- 大图/电商详情页类：设为 256–512，配合客户端浏览器实际并发能力（Chrome 通常支持 100–300 流）
- 含 OpenTelemetry / Sentry 追踪头的 API 网关：设为 384，避免因头部膨胀导致流提前被阻塞
- 不建议超过 1024：Nginx 内部每流维护独立状态，过高会显著增加内存占用与调度开销
头部缓冲区：防 414 错误与 HPACK 压缩失效
JWT Token、长 Referer、多级 Cookie 或自定义追踪 header 容易突破默认限制，导致请求被截断或降级到 HTTP/1.1：
- http2_max_field_size 16k：覆盖常见 JWT（约 4–8k）和带签名的 traceparent 头
- http2_max_header_size 64k：单个请求总 header 容量，比默认 4k 更稳妥；注意该值需 ≥ 所有字段 size 之和
- 配套 client 端缓冲：client_header_buffer_size 16k 和 large_client_header_buffers 4 32k，防止 Nginx 在解析前就丢弃大头
TCP 与 TLS 层缓冲协同：避免小包碎片影响窗口利用率
HTTP/2 窗口再大，若底层 TCP 发送效率低，流控窗口也难以填满：
- ssl_buffer_size 16k（勿设为 4k）：确保 TLS 记录层能打包更多帧，减少加密/发送次数
- keepalive_timeout 300s + keepalive_requests 10000：延长连接生命周期，让窗口复用更充分
- 系统级：net.core.wmem_default 和 wmem_max 建议设为 512k–1M，配合 Nginx 的 sendfile/on 与 tcp_nopush 使用
验证是否生效：别只看 “h2” 标签
很多配置看似开启 HTTP/2，实则因缓冲不足或 TLS 不兼容导致流被静默降级：
- Chrome DevTools → Network → 右键表头勾选 Protocol 和 Connection ID，确认同 Connection ID 下存在 >100 条 h2 请求
- 用 curl -I --http2 https://yoursite.com 检查响应头是否含
alt-svc: h2=，并观察是否返回HTTP/2 200 - Nginx 日志中开启
$http2变量，统计http2=on占比，低于 95% 就说明有隐性降级
