http2 动态表，如何保持服务器与浏览器双方一致？

Question

网络上对 http2 的动态压缩表只介绍了压缩的原理，未谈及服务器与浏览器动态表协商的过程，如
浏览器发起一个请求，携带了一个自定义表头，accessToken: aaaa，按照规则，传输给服务器以下格式。存在以下问题

1，上图中，未罗列该自定义头在浏览器动态表中的索引值，那自定义头的索引值是多少？
1.1 是递增吗? 如果是递增，则在浏览器中记录为 n+1，倘若浏览器同时发了第二个请求，携带另一个自定义表头 authentication: bbb。在浏览器中记录为 n+2。这时，如果服务器先收到第二个请求，则会错误地将 authentication: bbb 标记为 n+1，将 accessToken: aaaa 标记为 n+2，与浏览器中的动态表不一致

2，浏览器第一次发送请求 携带了一个自定义表头，accessToken: aaaa，在服务器未接收到的情况下，发送第二次请求，也携带该表头，但这次由于该表头已经在浏览器动态表中，仅发送标识为 n+1。服务器先接受到 第二次请求，无法识别 n+1，导致二者不一致。

鉴于存在以上问题，头部压缩应该是存在协商过程的，具体的协商过程是怎么样的？有朋友可以接受一下吗？

Answer 1

http2 在分帧中有明确规则，请求头与响应头的分帧，中间不能插入其他分帧。从而保证完整的请求头和响应头是按顺序传输的。故不会存在竞速问题。

• stackoverflow 中对应的讨论
• 在 HTTP2 中的 CONTINUATION 帧有相关的介绍，对应中文文档
• 

Answer 2

continuation 帧连续的，多个请求发送 header 的先后顺序，在接收端还是有序的，tcp 层面 seq 保证的，就算先收到晚请求的了，也会阻塞到前面的也收到。

Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream. The last frame in a sequence of HEADERS or CONTINUATION frames has the END_HEADERS flag set.The last frame in a sequence of PUSH_PROMISE or CONTINUATION frames has the END_HEADERS flag set. This allows a header block to be logically equivalent to a single frame.

一个 connection，bidirectional 通讯双方都会维护 2 个动态表，分别用于编码、解码。