HTTP/2 流控基础：流控原理、窗口更新机制、初始窗口大小

2.1 为什么需要流控？

HTTP/2 的多路复用允许单个连接上同时传输数十甚至数百个流。如果没有流控机制，一个发送方可能以远超接收方处理能力的速度推送数据帧，导致接收缓冲区溢出、内存耗尽甚至进程崩溃。流控的核心目标是：防止快速发送方压垮慢速接收方，同时不阻塞其他流的正常传输。

2.2 流控原理：基于信用额的滑动窗口

HTTP/2 采用基于信用额（Credit-Based）的滑动窗口模型。每个流（Stream）和整个连接（Connection）都维护一个独立的窗口大小。发送方只能发送不超过当前窗口剩余字节的数据。接收方通过发送 WINDOW_UPDATE 帧来增加窗口信用额。

2.3 窗口更新机制

窗口更新是流控的核心反馈回路。接收方处理完数据后，通过 WINDOW_UPDATE 帧通知发送方可以继续发送的字节数。更新机制分为两个层级：

2.4 初始窗口大小

初始窗口大小（SETTINGS_INITIAL_WINDOW_SIZE）是 HTTP/2 连接建立时，通过 SETTINGS 帧协商的默认信用额。RFC 7540 定义的默认值为 65,535 字节。这个值直接影响并发流的吞吐量和延迟。

2.4.1 默认值的影响

• 低并发场景：65,535 字节足够覆盖大多数小请求（如 API 调用），不会产生额外延迟。
• 高并发或大对象场景：如果单个流需要发送 1 MB 数据，默认窗口需要至少 16 次 WINDOW_UPDATE 才能完成传输，增加了往返延迟。
• 多租户场景：租户之间共享连接级窗口，一个慢速租户可能耗尽全局信用额，影响其他租户。

2.4.2 调优方向

2.5 窗口更新与性能的权衡

窗口更新频率直接影响 CPU 开销和延迟：

• 窗口过小：频繁的 WINDOW_UPDATE 帧交互增加 CPU 和网络开销，降低有效吞吐。
• 窗口过大：接收方需要分配更多缓冲区，内存压力上升；一旦发生丢包或重传，惩罚更大。
• 理想状态：窗口大小应至少等于 带宽延迟积（BDP），使发送方可以连续发送，无需等待窗口更新。

2.6 Envoy 中的流控配置入口

在 Envoy 的 HTTP 连接管理器（HCM）中，流控参数通过 HttpConnectionManager 的 http2_protocol_options 字段配置：

static_resources:
  listeners:
  - name: ingress_listener
    address:
      socket_address: { address: 0.0.0.0, port_value: 8080 }
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: HTTP2
          http2_protocol_options:
            initial_stream_window_size: 1048576        # 1 MB
            initial_connection_window_size: 16777216   # 16 MB
          # ... 其他配置