HTTP/2中HEADERS/CONTINUATION帧交织及HPACK相关技术疑问

1. 帧交织限制：为何其他流的DATA帧也不能插入HEADERS/CONTINUATION序列？ #

虽然DATA帧本身不直接修改HPACK动态表，但HTTP/2要求头块（HEADERS+后续CONTINUATION）必须作为连续的逻辑单元传输，核心原因有两点：

• 从HPACK状态同步角度：接收端是严格按帧的传输顺序维护动态表的。如果在头块序列中插入其他流的DATA帧，接收端会被迫中断头块解析流程，转而处理DATA帧，这会导致接收端无法确定头块是否已完全接收，进而可能出现动态表状态更新不及时或错误的情况——毕竟头块的解析是连续的状态累积过程，中途切换会破坏状态连续性。
• 从实现复杂度角度：强制头块连续传输可以大幅简化接收端的状态机设计，不需要在解析头块的过程中处理其他类型帧的切换逻辑，降低了边界错误的出现概率。

2. 收发双向限制：发送HEADERS/CONTINUATION的连续要求是否影响接收？ #

这个限制仅针对发送方向，完全不影响接收端的多路复用能力。
客户端发送某流的HEADERS/CONTINUATION时，必须保证这些帧连续发送、不插入同流或其他流的帧，但这和客户端同时接收其他流的帧是两个独立操作——HTTP/2的连接是双向的，发送和接收的帧序列相互独立。比如客户端在连续发送流1的头块时，完全可以同时接收服务器推送的流2的DATA帧或流3的响应头块，两者互不干扰。

3. 跨流HPACK上下文维护：流2的动态表更新会破坏流1的响应上下文吗？ #

不会，因为HPACK动态表的状态是基于连接上的帧传输顺序同步的，所有头块的处理严格遵循先到先处理的规则：

• 假设客户端先发送流1的请求头块（HEADERS+CONTINUATION），服务器接收后会先解析这个头块并更新动态表，再处理流1的请求并准备响应；
• 客户端后续发送流2的请求头块，服务器会在处理完流1的请求（或至少处理完流1的请求头块）之后，按顺序解析流2的头块并更新动态表；
• 服务器发送流1的响应头块时，使用的是处理完流1请求头后的动态表状态，流2的请求头块更新动态表是后续操作，不会回溯影响之前的状态。
  只要收发双方严格按帧的传输顺序处理，连接级的动态表状态就会保持完全同步，跨流操作不会破坏已有的上下文。

依据RFC 7540第4.3节：头压缩是有状态的，每个头块需作为独立单元处理，必须连续传输且不能插入任何其他类型或其他流的帧，以保证HPACK动态表状态正确。

内容的提问来源于stack exchange，提问作者Pushkar Dureja