如果您亲自体验过HTTP/2，那么您可能已经意识到HTTP/2可能带来的可见性能提高，这是由于流复用、显式流依赖和服务器推送等特性。但是有一个重要的特征是肉眼看不到的。这是HPACK头压缩。nginx的当前实现以及使用它的边缘网络和cdn不支持完整的HPACK实现。然而，我们已经在nginx中实现了完整的HPACK，并将执行Huffman编码的部分上流。Conor Lawless的CC BY 2.0图像这篇博客文章概述了HPACK开发的原因，以及它带来的隐藏带宽和延迟优势。一些背景正如您可能知道的，常规的HTTPS连接实际上是多层模型中几个连接的叠加。您通常关心的最基本的连接是TCP连接（传输层），在此基础上有TLS连接（传输层/应用层的混合），最后是HTTP连接（应用层）。在过去，HTTP压缩是在TLS层使用gzip执行的。头和正文都被不加区别地压缩，因为较低的TLS层不知道传输的数据类型。实际上，这意味着两者都是用DEFLATE算法压缩的。随后，SPDY推出了一种新的、专用的、头压缩算法。虽然专门为头设计，包括使用预设字典，但它仍然使用DEFLATE，包括动态Huffman代码和字符串匹配。不幸的是，他们都被发现容易受到犯罪攻击，犯罪攻击可以从压缩的报头中提取秘密身份验证cookies：因为DEFLATE使用反向字符串匹配和动态Huffman代码，攻击者可以控制部分请求头，可以通过修改请求的部分内容并查看在压缩过程中请求的总大小如何变化来逐步恢复完整的cookie。大多数边缘网络，包括Cloudflare，都因为犯罪而禁用了头压缩。直到HTTP/2出现。HPACK公司HTTP/2支持一种新的专用头压缩算法，称为HPACK。HPACK的开发考虑了犯罪等攻击，因此被认为是安全的。HPACK对犯罪具有弹性，因为它不使用部分向后字符串匹配和动态Huffman代码，比如DEFLATE。相反，它使用以下三种压缩方法：静态字典：一个预定义的字典，包含61个常用的头字段，有些字段带有预定义的值。动态字典：连接期间遇到的实际标头的列表。此词典的大小是有限的，当添加新条目时，旧条目可能会被逐出。哈夫曼编码：静态哈夫曼代码可用于编码任何字符串：名称或值。这段代码是专门为HTTP响应/请求头计算的——ASCII数字和小写字母的编码更短。可能的最短编码长度为5位，因此可实现的最高压缩比为8:5（或更小37.5%）。高压回流当HPACK需要以格式对报头进行编码时名称：value，它将首先查找静态和动态词典。如果名称：值为现在，它只会引用字典中的词条。这通常需要一个字节，在大多数情况下，两个字节就足够了！在一个字节中编码的整个头！这有多疯狂？由于许多报头是重复的，这种策略的成功率非常高。例如，标题如下：授权机构：或有时巨大的cookie头是本案中常见的疑点。当HPACK无法匹配字典中的整个标头时，它将尝试查找同名的标头。大多数流行的头名称都出现在静态表中，例如：content encoding、cookie、etag。其余的可能是重复的，因此会出现在动态表中。例如，Cloudflare为每个响应分配一个唯一的cf ray头，虽然这个字段的值总是不同的，但名称可以重用！如果找到了名称，在大多数情况下，它可以用一个或两个字节表示，否则将使用原始编码或哈夫曼编码（两者中较短的一个）对名称进行编码。头的值也是如此。我们发现仅哈夫曼编码就节省了近30%的头大小。虽然HPACK进行字符串匹配，但要让攻击者找到标头的值，他们必须猜测整个值，而不是采用渐进的方法，这种方法可以使用DEFLATE匹配，并且容易受到犯罪的攻击。请求标头HPACK为HTTP请求头提供的收益比响应头的收益更重要。请求头得到更好的压缩，因为头中的重复性要高得多。例如，对于我们自己的博客，使用Chrome有两个请求：请求1：:授权：blog.cloudflare.com**：方法：**GET：路径：/**：方案：**https接受：text/html，application/xhtml+xml，application/xml；q=0.9，image/webp，/；q=0.8接受-编码：gzip，放气，sdch，br接受-语言：en-US，en；q=0.8cookie:297字节cookie**升级不安全的请求：**1用户-代理：Mozilla/5.0（Macintosh；Intel Mac OS X 10_11_6）AppleWebKit/537.36（KHTML，如Gecko）Chrome/55.0.2853.0 Safari/537.36我用红色标记了可以使用静态字典压缩的标题。三个字段：方法：获取，：path:/和：方案：https是总是出现在静态字典中，并且每个都将在一个字节中编码。然后一些字段的名称将只压缩在一个字节中：：authority、accept、accept encoding、accept language、cookie和user agent都存在于静态字典中。其他所有用绿色标记的都将被哈夫曼编码。不匹配的标头将被插入到动态字典中，以供以下请求使用。让我们看看后面的请求：请求2：:授权：blog.cloudflare.com:方法：获取：路径：/assets/images/cloudflare sprite-小.png**：方案：**https接受：image/webp，图像/，/*；q=0.8**接受编码：**gzip，deflate，sdch，br**接受语言：**en-US，en；q=0.8**cookie:*相同的297字节cookie引用：https://blog.cloudflare.com/assets/css/screen.css？v=2237be22c2**用户代理：**Mozilla/5.0（Macintosh；Intel Mac OS X 10_11_6）AppleWebKit/537.36（KHTML，如Gecko）Chrome/55.0.2853.0 Safari/537.36这里我添加了蓝色编码字段。这些字段表示与动态字典匹配的字段。很明显，大多数字段在请求之间重复。在这种情况下，静态字典中会再次出现两个字段，另外五个字段会重复出现在动态字典中，这意味着它们可以分别编码为一个或两个字节。其中之一是~300字节的cookie头和~130字节的用户代理。这是430字节编码成4字节，99%压缩！总之，对于重复请求，只有三个短字符串将被哈夫曼编码。这是6小时内Cloudflare edge网络上入口标头流量的显示方式：平均来说，我们看到入口头的压缩率为76%。由于报头代表了大部分的入口流量，因此它也为总入口流量节省了大量资源：我们可以看到，由于HPACK压缩，总的入口流量减少了53%！事实上，今天，我们通过HTTPS处理HTTP/1和HTTP/2的请求数量大致相同，但是HTTP/2的入口流量只有HTTP/1的一半。响应标头对于响应报头（出口流量），收益较小，但仍然引人注目：回答1：缓存-控制：公共，最大年龄=30岁**cf缓存状态：**命中cf-h2-推送：，**cf射线：**2ded53145e0c1ffa DFW内容-编码：gzip内容-类型：text/html；字符集=utf-8日期：星期三，2016年9月7日格林尼治标准时间21:41:23到期时间：周三，2016年9月7日格林尼治标准时间21:41:53链接：；rel=预加载；as=脚本；rel=预加载；as=脚本服务器：cloudflare nginx状态：200变化：接受编码**x-ghost-cache-status:**来自缓存**x-powered-by:**Express公司第一个响应的大部分将被Huffman编码，其中一些字段名将从静态字典中匹配。回答2：缓存-控制：公共，最大年龄=31536000**cf公司-bgj:imgq公司：**100**cf缓存状态：**命中cf公司-雷：2ded53163e241ffa DFW内容-类型：image/png**日期：**2016年9月7日星期三21:41:23 GMT过期时间：星期四2017年9月7日格林尼治标准时间21:41:23**服务器：**cloudflare nginx**状态：**200**变化：**接受编码**x-ghost-cache-status:**来自缓存x-powered-by:快速同样，蓝色表示来自动态表的匹配，红色表示来自静态表的匹配，绿色表示Huffman编码的字符串。在第二个响应中，可以完全匹配12个头中的7个。对于剩下的五个字符串中的四个，名称可以完全匹配，六个字符串将使用静态哈夫曼编码进行有效编码。尽管这两个expires头文件几乎完全相同，但它们只能被Huffman压缩，因为它们不能完全匹配。处理的请求越多，动态表就越大，可以匹配更多的头，从而提高压缩比。这是出口标头流量在Cloudflare边缘上的显示方式：出口集管平均压缩69%。但是，总出口流量的节省并不显著：很难看到，但是我们在总出口HTTP/2流量上节省了1.4%。虽然看起来并不多，但在许多情况下，增加数据的压缩级别仍远远不够。这一数字也被提供非常大文件的网站严重扭曲：我们测量了一些网站的节省超过15%。测试您的HPACK如果您安装了nghttp2，您可以使用一个名为h2load的捆绑工具在您的网站上测试HPACK压缩的效率。例如：H2负荷https://blog.cloudflare.com|尾-6 |头-1流量：总计18.27KB（18708），538B（538）个标头（节省空间27.98%），17