网关层发挥HTTP/2多路复用价值的关键在于连接长期稳定复用，需确保ALPN协商成功、调优maxConcurrentStreams等参数、协同后端连接池，并通过指标与抓包验证复用效果。
网关层要真正发挥 HTTP/2 多路复用的价值，不能只靠“开了 HTTP/2”就完事，关键在于让连接被长期、稳定、高效地复用起来。多路复用本身是协议特性，自动生效；但连接数是否合理、流是否被充分利用、资源是否被过度争用，全靠配置驱动。
确认网关已启用 HTTP/2 并完成 ALPN 协商
这是所有优化的前提。HTTP/2 在 HTTPS 场景下依赖 TLS 层的 ALPN（Application-Layer Protocol Negotiation）协商出 h2 协议名（注意不是 http/2 或 HTTP/2）。常见错误包括：
- 证书无效或域名不匹配，导致 TLS 握手失败，直接降级为 HTTP/1.1
- 服务端未在 ALPN 列表中明确声明 h2（例如 Nginx 需配
http2指令且 TLS 配置完整；Envoy/Higress 需在 listener 的 transport socket 中启用 ALPN 并包含 h2） - 客户端未支持 h2 或显式禁用了 HTTP/2（如 curl 缺少
--http2，或 OkHttp 配置中误删了H2_PRIOR_KNOWLEDGE）
验证方式：用 curl -I --http2 -k https://your-gateway.com 看响应头是否含 HTTP/2 200；浏览器开发者工具 Network 标签页中 Protocol 列显示 h2。
调优核心连接与流参数
多路复用效果直接受限于网关对单连接承载能力的控制策略。默认值往往偏保守，需按实际负载调整：
- maxConcurrentStreams：单个连接允许的最大并发流数。Higress/Envoy 默认通常为 100，高吞吐场景可设为 500–1000；但不宜无限制，否则单连接可能耗尽内存或引发调度延迟
- initialStreamWindowSize 和 initialConnectionWindowSize：分别控制每个流和整条连接的初始流量控制窗口大小（单位字节）。增大可缓解小包频繁 WINDOW_UPDATE 的开销，建议从默认 65535 提升至 1MB（1048576），尤其适合 gRPC 流式响应场景
-
keepalive 参数：确保 TCP 连接空闲时不被中间设备（如防火墙、NAT）断开。Envoy 可配置
connection_idle_timeout（如 300s）和stream_idle_timeout（如 30s）
连接池与后端长连接协同管理
网关面向客户端的 HTTP/2 连接复用，必须和它连后端服务的连接池机制对齐，否则会出现“前端复用、后端爆炸”的失衡：
- 后端如果是 gRPC 服务，网关应复用同一连接池中的 HTTP/2 连接转发多个流，避免为每个前端流新建后端连接
- 在 Envoy/Higress 中，需开启
http2_protocol_options并设置allow_connect和max_concurrent_streams，同时为 upstream cluster 启用http2_protocol_options和连接池max_requests_per_connection（建议设为 0 表示不限制） - 避免使用轮询类负载均衡策略直接作用于 HTTP/2 连接——应改用“最小活跃请求数”，防止某连接因流堆积而过载
监控与验证是否真正复用
不能只看协议版本，要确认行为层面的复用效果：
- 观察网关指标：如 Envoy 的
cluster.（活跃连接数）与.upstream_cx_active cluster.（总请求数）比值是否显著低于 HTTP/1.1 时期（理想情况接近 1:100+）.upstream_rq_total - 抓包验证：Wireshark 过滤
http2，确认同一 TCP 流（相同 stream ID 基础流）中存在多个不同Stream ID的 HEADERS → DATA 帧交错出现 - 压测对比：相同 QPS 下，对比开启前后网关的文件描述符用量、TLS 握手次数（如 OpenSSL 统计）、CPU 花费在 SSL handshake vs application logic 的占比变化
