HTTP2 设置协商是什么
HTTP/2 连接建立后双方立即交换 SETTINGS 帧，用它协商连接级参数：最大并发流数、初始流控窗口、最大帧大小、头部列表大小上限等。这些参数决定后续的并发能力与流控基线，应用侧观察到并发上不去或大对象传输被切得过碎时，第一步就该核对这里协商出的取值。SETTINGS 帧必须被对端确认，长期收不到确认属于协议层面的异常。另外流控窗口分连接级与流级两层，分别计算，只看一层会估错实际可用的发送窗口。
基本信息
| 协议依据 | RFC 9113（HTTP/2） |
|---|---|
| 抓包字段 | http2.type == 4 即 SETTINGS 帧 |
| 常见参数 | 最大并发流数、初始窗口大小、最大帧大小、头部列表大小 |
| 确认机制 | 对端必须回复带确认标志的 SETTINGS |
| 窗口层级 | 连接级与流级分别计算 |
典型使用场景
- 并发能力核对：确认服务端允许的并发流数是否符合预期
- 流控排查：初始窗口大小直接影响单个流的传输节奏
- 版本对比：升级或调整配置前后参数是否发生变化
- 协议异常识别：SETTINGS 长期未被确认说明实现存在问题
- 大对象分片分析：最大帧大小决定载荷的切分粒度
过滤与核对
过滤与核对
http2.type == 4 # SETTINGS 帧
http2.type == 4 && http2.flags.ack == 1 # 对端的确认帧
http2.settings.id == 4 # 初始窗口大小项
# 逐项核对实际协商出的连接级参数取值关键参数与影响
| 参数 | 影响 | 异常表现 |
|---|---|---|
| 最大并发流数 | 同时进行的流数量上限 | 资源请求排队而非报错，页面只是变慢 |
| 初始窗口大小 | 单流起始可发送的数据量 | 大对象传输起步阶段偏慢 |
| 最大帧大小 | 单帧载荷上限 | 大对象被切成更多帧，处理开销上升 |
| 头部列表大小 | 头部压缩表的容量上限 | 头部过多时压缩效率下降 |
服务端调低并发上限时，多资源页面表现为请求排队等待而不直接报错，用户侧看到的只是资源加载慢，需要抓包才能确认原因。
连接级与流级窗口分开计算，估算可用发送量时必须把两层都算进去，只看流级窗口会明显低估限制所在。