为什么霍夫曼编码在HTTP / 2 HPACK中是可选的？

Question

我想确保我正确理解了这一点：这是从section 5.2 of RFC7451

   Header field names and header field values can be represented as
   string literals.  A string literal is encoded as a sequence of
   octets, either by directly encoding the string literal's octets or by
   using a Huffman code (see [HUFFMAN]).

     0   1   2   3   4   5   6   7
   +---+---+---+---+---+---+---+---+
   | H |    String Length (7+)     |
   +---+---------------------------+
   |  String Data (Length octets)  |
   +-------------------------------+

这意味着我可以使用Huffman编码的字符串发送H为1的Header字符串文字；或H为0且原始字符串为八位字节；或并且现有的HTTP / 2服务器/实现应正确解析它们，对吧？

Answer 1

HTTP标头基本上由ASCII码组成。 ASCII使用固定长度的代码，其中每个字符的长度为8位（实际上只有7位，因为HTTP标头仅使用原始ASCII字符集中的前127个代码，但第8位设置为0）。

霍夫曼编码使用可变长度编码。较常用的字符具有少于8位的较短代码，而较不常用的字符具有8位以上的代码。多数文本的理论是由更常用的代码组成的，因此在大多数情况下，其长度应比ASCII短。这尤其如此，因为当仅使用仅需要7位的基本字符时，ASCII就会“浪费”一点，但是将其保存在8位空间中。

因此，如果使用霍夫曼编码，将会有些文本实际上比ASCII长。

[HPACK中使用的霍夫曼编码表显示为here，例如，您可以看到<编码为15位的111111111111100。因此，对霍夫曼编码，字符串<<<<将采用ASCII的4个八位位组，但60位或8个八位位组。

因此，HPACK允许您在这种情况下使用ASCII，因为这样做效率更高。

也许这有点复杂，在这些罕见的情况下，我们应该接受效率稍低的编码-有些人说IETF痴迷于保存位，但这就是为什么它存在的原因。

接收者无法控制对方使用什么，因此每个HTTP / 2实现都需要理解霍夫曼编码，因此在没有HTTP / 2实现的情况下，它不是可选的。

[顺便说一句，如果您有兴趣比规格书更详细地了解HPACK，那么我将在我的书的第8章中介绍它（包括对这个问题的答案！）：https://www.manning.com/books/http2-in-action。