2)头部名称在字典中，更新动态字典

  1. 0 1 2 3 4 5 6 7 
  2.  
  3. +---+---+---+---+---+---+---+---+ 
  4.  
  5. | 0 | 1 | Index (6+) | 
  6.  
  7. +---+---+-----------------------+ 
  8.  
  9. | H | Value Length (7+) | 
  10.  
  11. +---+---------------------------+ 
  12.  
  13. | Value String (Length octets) | 
  14.  
  15. +-------------------------------+ 

对于这种情况，首先需要使用一个字节表示头部名称：左两位固定为 01，之后六位存放头部名称在静态或动态字典中的索引。接下来的一个字节第一位 H 表示头部值是否使用了哈夫曼编码，剩余七位表示头部值的长度 L，后续 L 个字节就是头部值的具体内容了。例如下图中索引值为 32(100000)，在静态字典中查询可得 cookie;头部值使用了哈夫曼编码(1)，长度是 28(0011100);接下来的 28 个字节是 cookie 的值，将其进行哈夫曼解码就能得到具体内容。

 incremental-index-header

客户端或服务端看到这种格式的头部键值对，会将其添加到自己的动态字典中。后续传输这样的内容，就符合第 1 种情况了。

3)头部名称不在字典中，更新动态字典

  1. 0 1 2 3 4 5 6 7 
  2.  
  3. +---+---+---+---+---+---+---+---+ 
  4.  
  5. | 0 | 1 | 0 | 
  6.  
  7. +---+---+-----------------------+ 
  8.  
  9. | H | Name Length (7+) | 
  10.  
  11. +---+---------------------------+ 
  12.  
  13. | Name String (Length octets) | 
  14.  
  15. +---+---------------------------+ 
  16.  
  17. | H | Value Length (7+) | 
  18.  
  19. +---+---------------------------+ 
  20.  
  21. | Value String (Length octets) | 
  22.  
  23. +-------------------------------+ 

这种情况与第 2 种情况类似，只是由于头部名称不在字典中，所以第一个字节固定为 01000000;接着申明名称是否使用哈夫曼编码及长度，并放上名称的具体内容;再申明值是否使用哈夫曼编码及长度，最后放上值的具体内容。例如下图中名称的长度是 5(0000101)，值的长度是 6(0000110)。对其具体内容进行哈夫曼解码后，可得 pragma: no-cache。

 incremental-index-header-newname

客户端或服务端看到这种格式的头部键值对，会将其添加到自己的动态字典中。后续传输这样的内容，就符合第 1 种情况了。

4)头部名称在字典中，不允许更新动态字典

  1. 0 1 2 3 4 5 6 7 
  2.  
  3. +---+---+---+---+---+---+---+---+ 
  4.  
  5. | 0 | 0 | 0 | 1 | Index (4+) | 
  6.  
  7. +---+---+-----------------------+ 
  8.  
  9. | H | Value Length (7+) | 
  10.  
  11. +---+---------------------------+ 
  12.  
  13. | Value String (Length octets) | 
  14.  
  15. +-------------------------------+ 

这种情况与第 2 种情况非常类似，唯一不同之处是：第一个字节左四位固定为 0001，只剩下四位来存放索引了，如下图：

 never-index-header-field

这里需要介绍另外一个知识点：对整数的解码。上图中第一个字节为 00011111，并不代表头部名称的索引为 15(1111)。第一个字节去掉固定的 0001，只剩四位可用，将位数用 N 表示，它只能用来表示小于「2 ^ N - 1 = 15」的整数 I。对于 I，需要按照以下规则求值(RFC 7541 中的伪代码，via)：

  1. PYTHONif I < 2 ^ N - 1, return I # I 小于 2 ^ N - 1 时，直接返回 
  2.  
  3. else 
  4.  
  5. M = 0 
  6.  
  7. repeat 
  8.  
  9. B = next octet # 让 B 等于下一个八位 
  10.  
  11. I = I + (B & 127) * 2 ^ M # I = I + (B 低七位 * 2 ^ M) 
  12.  
  13. M = M + 7 
  14.  
  15. while B & 128 == 128 # B 最高位 = 1 时继续，否则返回 I 
  16.  
  17. return I 

对于上图中的数据，按照这个规则算出索引值为 32(00011111 00010001，15 + 17)，代表 cookie。需要注意的是，协议中所有写成(N+)的数字，例如 Index (4+)、Name Length (7+)，都需要按照这个规则来编码和解码。

这种格式的头部键值对，不允许被添加到动态字典中(但可以使用哈夫曼编码)。对于一些非常敏感的头部，比如用来认证的 Cookie，这么做可以提高安全性。


共4页: 上一页1234下一页

相关内容