HTTP2.0简明笔记

时间 2019-11-20

原文原文链接

版权声明：本文由史燕飞原创文章，转载请注明出处:
文章原文连接：https://www.qcloud.com/community/article/82html

来源：腾云阁 https://www.qcloud.com/communityweb

RFC2616发布以来，一直是互联网发展的基石。HTTP协议也成为了能够在任何领域使用的核心协议，基于这个协议人们设计和部署了愈来愈多的应用。HTTP的简单本质是其快速发展的关键，但随着愈来愈多的应用被部署到WEB上，HTTP的问题慢慢凸显出来。今天，用户和开发者都迫切须要经过THHP1.1达到一种几近实时的响应速度和协议性能，而要知足这个需求，只在原有协议上进行修补是不够的。为了应对这些挑战，HTTP必须继续发展。HTTP工做组已经在2012年宣布要设计和开发HTTP2.0。HTTP2.0的主要目标是改进传输性能，实现低延迟和高吞吐量。算法

在HTTP2.0真正诞生以前，谷歌开发了一个实验性质的协议-SPDY，它定位于解决HTTP1.1中的一些性能限制，来减小网页的延时。自从2009年SPDY发布以后，这个协议获得了众多浏览器厂商和大型网站的支持，实践证实它确实能够很大幅度的提高性能，已经具有成为一个标准的条件。因而，HTTP-WG于2012年初提出要重在SPDY的一些实践基础上新设计和开发HTTP2.0，以期使数据传输具备更好的性能和更少的延时。SPDY是HTTP2.0的先驱，但两者并不能初略的划为等号，SPDY V2草案是HTTP2.0标准制定的起点，今后以后SPDY标准并无停滞，而是在不断进化，它成为了HTTP2.0新功能及新建议的实验场，为HTTP2.0标准收纳的每一项建议，提供事前的测试和评估手段，整体来讲SPDY比HTTP2.0更为激进。HTTP2.0协议版本发布历程以下：浏览器

2012年3月，HTTP2.0征集建议；
2012年11月，HTTP2.0第一稿；
2014年8月，HTTP2.0 draft-17和HPACK draft-12发布；
2014年8月，工做组最后征集HTTP2.0建议；
2015年2月，IESG批准HTTP2.0和HPACK草稿；
2015年5月，RFC 7540 (HTTP2.0) 和 RFC 7541 (HPACK) 发布；

在新的协议中，将会从根本上解决以往HTTP1.1版本中所作的“特殊优化”，将在这些解决方案内置在传输层中，使数据传输更加便捷和高效，如HTTP1.1及之前的版本中影响性能的很大一个问题，就是队首阻塞问题，在HTTP2.0中会将会经过新的组帧机制来解决这个问题，使链接能够多路复用，再经过压缩HTTP首部字段将协议开销降到最低。HTTP2.0不会改动HTTP语义，很好的继承以往版本的HTTP方法、状态码、URI及首部字段等核心概念，下面将对这些内容进行细致的描述。缓存

1.二进制分帧

HTTP2.0的根本改进仍是新增的二进制分帧层，不一样于HTTP1.X使用换行符分割纯文本，二进制分帧层更加简洁，处理起来也更加高效。这里所谓的层，指的是位于套接字接口与应用可见的高层HTTP API间的一个新机制：HTTP语义，包括各类动词、方法、首部，都不受影响，不一样的是传输它们的编码方式变了。HTTP 1.X以换行符做为纯文本的分隔符，而HTTP 2.0将全部传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码。示例以下：

由上图可知，在HTTP1.1传输数据时，首部和数据是一块发送的，每次传输都是须要带有首部信息；在HTTP2.0中，首部信息被分为一个独立的帧进行发送，数据帧在在首部帧发送后，再进行发送，并且采用首部压缩后，每次传输只须要发送改动的部分便可，极大提升了数据发送的效率。安全

1.1.分帧首部

在创建HTTP2.0链接以后，客户端与服务器会经过交换帧进行通讯，帧是HTTP2.0协议的最小单位。全部的帧都拥有一个8字节的首部，具体格式以下：性能优化

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R | Length (14) | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+

R : 保留的2位字段。这些字节的语义是未定义的，而且在发送的时候必须保持未设置(0)，接收的时候必须被忽略此字段。
Length : 14位无符号整数的帧主体长度。8字节长度的帧报头信息不计算在此内，主体最大可能长度为2^14-1(16383)字节，整个帧(包括首部)的最大长度是最大的帧长度是16391字节。
Type ：帧的8位类型。帧类型定义了剩余的帧报头和帧主体将如何被解释。具体实现必须在收到未知帧类型(任何未在文档中定义的帧)时做为链接错误中的类型协议错误(PROTOCOL_ERROR)处理。
Flags ：为帧类型保留的8字节字段有具体的布尔标识。标识针对肯定的帧类型赋予特定的语义。肯定帧类型定义语义之外的标示必须被忽略，而且必须在发送的时候保留未设置(0)。
R : 1位的保留字段。这个字段的语义未设置而且必须在发送的时候保持未设置(0)，在接受的时候必须被忽略。
Stream Identifier : 31字节的流标识符，惟一标识HTTP2.0的流。0是保留的，标明帧是与链接相关做为一个总体而不是一个单独的流。

经过这个共享的8字节首部，能够很快肯定帧的类型、标志和长度，并且每一帧的长度也是事先定义好的，解析器也能够迅速的找到下一帧的开始，并进行解析，这对于HTTP1.1X来讲也是一个很大的提高。服务器

1.2.帧类型

无论是在链接管理或单独的流中，每种帧都为了特定的目的而服务。在HTTP2.0中，共定义了如下10种帧类型：cookie

DATA：用于传输HTTP消息体；
HEADERS：用于传输关于流的额外的首部字段；
PRIORITY：用于指定或从新指定引用资源的优先级；
RST_STREAM：用于知道流的非正常终止；
SETTINGS：用于通知两端通讯方式的配置数据；
PSUH_PROMISE：用于发出建立流和服务器引用资源的要约；
PING：用于计算往返时间，执行活性检查；
GOWAY：通知远端对等端不要在这个链接上创建新流；
WINDOW_UPDATE：用于针对个别流或个别链接实现流量控制；
CONTINUATION：用于继续一系列首部片断。

注：服务器能够利用GOWAY类型的帧告诉客户端要处理的最后一个流ID，从而消除一些请求竞争，并且浏览器也能够据此智能地重试或取消“悬着的”请求。这也是保证复用链接安全的一个重要和必要的功能。网络

HTTP2.0性能加强的核心，全在于新增的二进制分帧层，它定义了如何封装HTTP消息并在客户端与服务器之间传输。因为在HTTP2.0中使用了新的组帧方式，这样一来，客户端和服务器为了相互理解，必须都使用新的二进制编码机制，因此HTTP1.x客户端没法理解只支持HTTP2.0的服务器，反之亦然。但这并不影响咱们使用HTTP2.0，现有的应用不用关注这些变化，由于客户端和服务器会替它们完成必要的分帧工做。

1.3.流、消息和帧

新的二进制分帧机制改变了客户端与服务器之间交互数据的方式，为了更好的理解HTTP2.0中这一核心变化，下面介绍流、消息、帧这三个概念及区别：

流（stream）：已创建的链接上的双向字节流，HTTP/2链接中的虚拟通道。
消息（message）：与逻辑消息对应的完整的一系列数据帧。
帧（frame）：HTTP2.0通讯的最小单位，包括根据帧类型结构的字节的报头和可变长度的序列，每一个帧包含首部。

全部HTTP2.0通讯都在一个TCP链接上完成，这个链接能够承载任意数量的双向数据流。相应的，每一个数据流以消息的形式发送，而消息由一个或多个帧组成，这些帧能够乱序发送，而后根据每一个帧首部的流标识符从新组装。帧是HTTP2.0中的最小通讯单位，不一样类型的帧有特殊的做用。

2.多路复用

2.1.队列传输与多路复用

在HTTP1.x中，若是客户端想发送多个并行的请求以及改进性能，那么必须使用多个TCP链接，并且存在队首阻塞问题，严重影响数据的传输效率。在HTTP2.0中，二进制分帧机制突破了这些限制，实现了多向请求和响应，客户端和服务器能够把HTTP消息分解为互不依赖的帧，而后乱序发送，而后在接收端从新组装，这样就完成了消息的传输。示例以下：

由上图可知，在同一个链接中，有三个流在同时传输，有两个是从服务端发给客户端的，也有一个是从客户端发送到服务端，这就大大的提升了链接的利用率。
这个新的机制是革命性的，会在整个WEB技术栈中引起一系列连锁反应，从而带来巨大的性能提高，由于：

能够并行交错地发送请求，请求之间互不影响；
能够并行交错地发送响应，响应之间互不干扰；
只使用一个链接便可并行发送多个请求和响应；
消除没必要要的延迟，从而减小页面加载时间；
没必要再为绕过HTTP1.X限制而作多余的工做。

HTTP2.0的二进制分帧机制解决了HTTP1.X中存在的队首阻塞问题，也消除了并行处理和发送请求及响应时对多个链接的依赖。这样，就会使应用更快、开发更简单、部署成本更低，也会减小客户端和服务器的CPU及内存占用。

2.2.每一个来源一个链接

在能够实现链接的多路复用后，HTTP2.0再也不依赖多个TCP链接去实现多流并行了。如今，多个数据流都拆分红不少帧，而这些帧能够交错，还能够分别优先级。因而，全部的 HTTP2.0链接都是持久化的，并且客户端与服务器之间也只须要一个链接便可。每一个来源一个链接显著减小了相关的资源占用：链接路径上的套接字管理工做少了，内存占用少了，链接吞吐量大了。因此，不少层面上都有不小的提升：

全部数据流的优先级次序始终如一；
压缩上下文单一使得压缩效果更好；
因为TCP链接减小而使网络拥塞情况得以改观；
慢启动时间减小，拥塞和丢包恢复速度更快。

大多数HTTP链接的时间都很短，并且是突发性的，但TCP只在长时间链接传输大块数据时效率才高。HTTP2.0经过让全部数据流共用同一个链接，能够更有效地使用TCP链接。HTTP2.0不只可以减小网络延迟，还有助于提升吞吐量和下降运营成本。
注：任何事物都有其两面性，每一个来源一个链接固然也会带来一些问题:

虽然消除了HTTP队首阻塞现象，但TCP层次上仍然存在队首阻塞；
若是TCP窗口缩放被禁用，那带宽延迟积效应可能会限制链接的吞吐量；
丢包时，TCP拥塞窗口会缩小。

虽然有上述问题影响HTTP2.0的性能，但实验代表一个TCP链接仍然是目前最佳的策略：压缩和优先级排定带来的性能提高，已经超过了队首阻塞形成的负面效应。与全部其余的性能优化同样，去掉一个性能瓶颈，又会带来新的瓶颈。对HTTP2.0而言，TCP极可能就是下一个瓶颈。这也是服务器端TCP配置对HTTP2.0相当重要的一个缘由。

3.请求优先级

在HTTP消息被分解为不少独立的帧以后，就能够经过优化这些帧的交错和传输顺序，可让最紧要的帧优先发送，以确保关键任务的快速展开。那么如何定义这些帧的发送顺序就是一个难题，为方便起见，在HTTP / 2标准容许每一个流具备相关联的权重和依赖性：

每一个流可被分配1~256之间的权重值，具备相同父节点的流应该根据权重比例来分配资源；
每一个流可声明对另外一流的显式依赖性，包含一个依赖偏好设置表示分配资源给特定的流而不是所依赖的流。

经过流依赖和权重，客户端能够构建一个“优先级树”（以下图所示），将这个树发送到服务端，表达客户端愿意以怎样的方式接收响应；服务端在接收到该“优先级树”后，能够根据这个信息，经过协调相关服务器资源返回响应，如CPU、存储器、网络等资源，优先处理高优先级的流。而且一旦响应数据是可用的，服务端将分配更多的带宽以确保高优先级的快速响应。

HTTP 2.0内的一个流只能设置一个惟一的流依赖，被依赖流就是当前流的父节点流，若是省略了流依赖的声明，则默认依赖于“根流”。声明一个流的依赖性代表，若是可能的话，父流应先于子流进行资源分配和响应，例如请处理和响应C前交付响应D。
具备相同的父流的同级流应该按照其权重比例分配服务器资源。例如，若是流A具优先级重量为12，他的同级兄弟流B的权重为4，那么肯定两者应分配的资源比例为：

计算全部流的权重总和：4 + 12 = 16；
计算每一个流所占总和的比例：A = 12 / 16，6B = 4/16。

由上可知，如A流获得四分之三可用资源分配的话，B流应获得可利用的资源的四分之一。为了更好的理解优先级机制，下面从左到右依次介绍上图的优先级重组状况：

不管是流A或B指定一个相同的父依赖，仍是是依赖于隐式的“根流”：A的优先级权重为12，B的优先级权重为4，所以基于比例权重--流B应该获得分配给流A资源的三分之一；
D是依赖于根流，C是依赖D。所以，D应提早于C，此时权重对资源分配是可有可无的，由于没有其余流与C同级；
D应在C以前接收到资源的充分分配；C应在A和B以前接收资源的充分分配；B流应该接收分配给A流资源的三分之一；
在E和C以前，D应该获得充分的资源分配；E和C应在A和B以前获得平等的分配；A和B应根据它们的权重进行比例分配。

从上述示例可知，流依赖和权重的组合提供了一个表达资源优先次序的方式，这能够为不一样的资源定义优先级，能够更好的提升性能。HTTP／2协议也容许客户端在任什么时候间点更新优先级信息，优先级信息能够像它们被建立同样使用报头帧或者使用优先级帧来明确指定或者改变。有了这个优先级标识，客户端和服务器就能够在处理不一样的流时采起不一样的策略，以最优的方式发送流、消息和帧。优先级的目的是容许终端表达它如何让对等端管理并发流时分配资源。更重要的是，在发送容量有限时优先级能用来选择流来传输帧。提供优先级信息是可选的，没有明确指定时使用默认值。
流依赖和权重表达一个传输偏好，而不是一个要求，所以不保证一个特定的处理或传输顺序。也就是说，客户端不能强制服务器以流优先级的优先级来处理特定顺序的流。在选择HTTP2.0服务器时，须要考虑如下几个问题：

若是服务器对全部优先级视而不见怎么办？
高优先值流必定优先处理吗？
是否存在不一样优先级的流应该交错的状况？

若是服务器不理睬全部优先值，那么可能会致使应用响应变慢：浏览器明明在等关键的CSS和JavaScript，服务器却在发送图片，从而形成渲染阻塞。然而，严格按照规定的优先级次序也可能带来次优的结果，由于这或许会再次引入队首阻塞问题，即某个高优先级的慢请求会没必要要地阻塞其余资源的交付。
因此，服务器能够而且应该交错发送不一样优先级别的帧，只要可能，高优先级流都应该优先传输，不过为了更高效地利用底层链接，不一样优先级的混合也是必须的。所以优先级的表达仅仅是一个建议。

4.流量控制

流量控制的定义是用来保护端点在资源约束条件下的操做。流量控制解决的状况是接收端在一个流上处理数据的同时一样想继续处理同个链接上的其余流。在同一个TCP链接上传输多个数据流，就意味着要共享带宽。标定数据流的优先级有助于按序交付，但只有优先级还不足以肯定多个数据流或多个链接间的资源分配，为解决这个问题，HTTP2.0为数据流和链接的流量控制提供了一个简单的机制：

流量控制基于每一跳进行，而非端到端的控制；
流量控制基于窗口更新帧进行，即接收方广播本身准备接收某个数据流的多少字节，以及对整个链接要接收多少字节；
流量控制窗口大小经过WINDOW_UPDATE帧更新，这个字段指定了流ID和窗口大小递增机制；
每一个新的流及整个链接的流量控制窗口初始值是65,535字节；
流控制方向性，即接收方可能根据本身的状况为每一个流乃至整个链接设置任意窗口大小；流量控制能够由接收方禁用，包括针对个别的流和针对整个链接。
帧类型决定了是否适用流量控制规则。本文档定义的帧中，只有DATA帧受流量控制；全部其余的帧不受广播的流量控制窗口影响。这保证了重要的控制帧不因流量控制所阻塞。

HTTP/2只标准化WINDOW_UPDATE帧格式。HTTP2.0标准没有规定任何特定的算法、值，或者何时发送WINDOW_UPDATE帧，所以实现能够选择本身的算法以匹配本身的应用场景，从而求得最佳性能。
流量控制方案等确保同一链接上的流相互之间不会形成破坏性的干扰。流量控制在单个流及整个链接过程当中使用，HTTP/2 经过使用WINDOW_UPDATE帧类型来提供流量控制。上面的机制和TCP流量控制是同样的思路，然而仅凭TCP流量控制是不能对一条HTTP2.0链接内的多个流实行差别化策略，因此专门有了HTTP2.0流量控制机制的出现。

5.服务器推送

5.1.服务器端推送

HTTP2.0新增了一个强大的功能，就是服务器能够对一个客户端请求发送多个响应。换句话说，出了最初请求的相应外，服务器还能够额外向用户端推送资源，而无需客户端明确地请求。示例以下：

这样一个机制须要解决的问题是什么呢？咱们知道，一般一个web应用每每包含数十个资源，客户端须要分析服务器提供的文档才能逐个找到它们。那么为何不让服务器提早就把这些资源推送给客户端，从而减小额外的延时呢？服务器已经知道客户端下一步要请求什么资源了，这时候服务器端推荐就能够大展拳脚了。事实上，网页上嵌入的CSS及JS，或经过URI嵌入的其余资源，也能够算是服务器端推送。把资源直接插入到文档中，就是把资源直接推送给客户端，而无需客户端主动请求。在HTTP2.0中，惟一的不一样就是能够把这个过程从应用中拿出来，放到HTTP协议自己来实现，并且带来了以下好处：

客户端能够缓存推送的资源;
客户端能够拒绝推送的资源;
推送资源能够由不一样的页面共享;
推送资源能够与其余资源一块儿复用;
服务器能够按照优先级推送资源.

有了服务器推送后，HTTP1.X时代的插入或嵌入资源的作法就能够退出历史舞台了。惟一有必要采用嵌入资源方式的状况就是该资源只供一个页面使用，并且编码代价不大，除此以外，其余全部的场景都应该使用服务器端推送。

注：全部服务器推送流都由PUSH_PROMISE发端，它除了对原始请求的响应以外，服务器向客户端发出的有意推送所述资源的信号。PUSH_PROMISE帧中只包含有要约资源的HTTP首部。

客户端在接收到PUSH_PROMISE帧以后，能够视自身需求选择接收或拒绝这个流。服务端推送也有一些限制：

首先，服务必须遵循请求-响应的循环，只能借着请求的响应推送资源，服务器端并不能随意发起推送；
其次，PUSH_PROMISE帧必须在返回响应以前发送，以避免客户端出现竞争状态，不然会出现客户端请求的刚好服务器打算推送的情景。

由于推送的响应是有效地逐跳，中介端接从服务端接收到推送响应的能够选择不转发这些到客户端。也就是说，如何使用推送响应取决于这些中介端。相等的，中介可能选择不推送的额外的响应给客户端，不须要服务端进行任何操做。服务端只能推送能够被缓存的响应；被承诺的请求必须是安全的，并且绝对不能包含一个请求主体。

5.2.如何实现服务器端推送

服务器推送为优化应用的资源交付提供了不少可能，然而，服务器到底该如何肯定哪些资源能够或应该推送呢？HTTP2.0并无给出详尽的规定，那么就有可能出现多种策略，每种策略可能会考虑一种应用或服务器使用场景。

应用能够在自身的代码中明确发起服务器推送；
应用能够经过额外的HTTP首部向服务器发送信号，列出它但愿推送的资源；
服务器能够不依赖应用而自动学习相关资源，经过分析来推测出须要推送的资源。

上面只是几个可能的策略，固然也有不少其余的实现方式，多是手工调用低级的API，也多是一种全自动的实现。总之，服务器推送领域将会出现不少有意思的创新。推送的资源将直接进入客户端缓存，就像客户端请求了同样，不存在客户端API或JS回调方法等通知机制，能够用于肯定资源什么时候到达，整个过程对运行在浏览器中的web应用来讲好像根本不存在。

虽然如今还不知道如何肯定哪些资源能够或应该推送，可是如何发起推送的机制已经创建，由服务端先发起推送请求，客户端再进行推送响应。具体以下：

Push Requests

服务端推送语义上等同于服务端响应一个请求；然而，这种状况下请求也是由服务端发送的，做为一个PUSH_PROMISE帧。PUSH_PROMISE包含了一个报头区块，含有完整的服务端属性请求报头字段。推送的响应老是与客户端的一个明确的请求相关。服务端在这个明确的请求流上发送PUSH_PROMISE帧。PUSH_PROMISE帧通常包含被承诺的流标识符，从可用的服务端流标识符中选择。服务端应当在发送任何被承诺的响应以前发送一个PUSH_PROMISE帧。这避免了客户端在收到任何PUSH_PROMISE帧前发出请求而出现的竞赛。PUSH_PROMISE能够由服务端在任意由客户端打开的流上发送。

Push Responses

发送PUSH_PROMISE帧后，服务端能够开始接收被推送进来的响应做为一个由服务端发起的使用被承诺流标识的流的响应。一旦客户端接收到PUSH_PROMISE帧而且选择接受推送的响应，客户端不该该对被承诺的响应发起请求，直到被承诺的流被关闭为止。若是客户端以任何理由决定不但愿接受服务端推送的响应，或者服务端花费太长时间才开始发送承诺的响应，客户端能够发送一个RST_STREAM帧，使用CANCEL或者REFUSED_STREAM码来关联被推送的流标识符。

6.首部压缩

HTTP的每一次通讯都会携带一组首部，用于描述传输的资源及其属性。在HTTP1.X中，这些元数据是以纯文本形式发送的，一般会给每一个请求增长500-800字节的负荷。若是算上COOKIE，增长的负荷会达到上千字节，为了减小这些开销并提高性能，HTTP2.0会压缩首部元数据：

HTTP2.0在客户端和服务器端使用“首部表”来跟踪和存储以前发送的键-值对，对于相同的数据，再也不经过每次请求和响应发送；
首部表在HTTP2.0的链接存续期内始终存在，由客户端和服务器共同渐进的更新；
每一个新的首部键-值对要么被追加到当前表的末尾，要么替换表中以前的值。

因而，HTTP2.0链接的两端都知道已经发送了哪些首部，这些首部的值是什么，从而能够针对以前的数据只编码发送这些差别数据。在通讯期间几乎不会改变的键值对只需发送一次便可，这样就大大提升了数据的载荷。示例以下：

HTTP/1 的状态行信息（Method、Path、Status 等），在 HTTP/2 中被拆成键值对放入头部（冒号开头的那些），一样能够享受到字典和哈夫曼压缩。另外，HTTP/2 中全部头部名称必须小写。
头部压缩须要客户端和服务器端作好如下工做：

维护一份相同的静态字典（Static Table），包含常见的头部名称，以及特别常见的头部名称与值的组合；
维护一份相同的动态字典（Dynamic Table），能够动态地添加内容；
支持基于静态哈夫曼码表的哈夫曼编码（Huffman Coding）。

静态字典的做用有两个：

1）对于彻底匹配的头部键值对，例如 :method: GET，能够直接使用一个字符表示；
2）对于头部名称能够匹配的键值对，例如 cookie: xxxxxxx，能够将名称使用一个字符表示。

同时，浏览器能够告知服务端，将 cookie: xxxxxxx 添加到动态字典中，这样后续整个键值对就可使用一个字符表示了。相似的，服务端也能够更新对方的动态字典。须要注意的是，动态字典跟具体链接上下文有关，须要为每一个 HTTP2.0 链接维护不一样的字典。使用字典能够极大地提高压缩效果，其中静态字典在首次请求中就可使用。对于静态、动态字典中不存在的内容，还可使用哈夫曼编码来减少体积。HTTP2.0 使用了一份静态哈夫曼码表，也须要内置在客户端和服务端之中。哈夫曼编码的核心理念就是使用最少的位数表示最多的信息，HTTP2.0中这份哈夫曼编码表是根据一个大样本的HTTP报头的统计数据生成，常常出现的字符会用较短的二进制数标识，出现频率较低的字符用较长的二进制数标识，这样就保证了综合来看报头信息占用了较少的空间，进一步压缩了报头信息。

在服务端接收到压缩过的报头信息后，会先进行哈夫曼编码解码，获得报首信息后，再结合维护的静态字典和动态字典信息得出完整的报首信息，随后进行请求的处理和响应。在须要更新动态字典信息时，对字典进行更新。

HTTP2.0压缩算法：SPDY早期版本使用zlib和自定义的字典压缩全部的HTTP首部，能够减小85%-88%的首部开销，从而显著减小加载页面的时间。然而，在2012年夏天，出现了针对TLS和SPDY压缩算法的CRIME安全攻击，因而，zlib算法被撤销，取而代之的是前面介绍的新索引表算法。该算法没有相似的安全问题，但能够实现相差无几的性能提高。

7.HTTP2.0升级与发现

向HTTP2.0的迁移不可能瞬间完成，不管服务器端仍是客户端都须要进行必要的更新升级才能使用。好消息是，大多数现代浏览器都内置有高效的后台升级机制，对大多数既有用户来讲，这些浏览器能够很快的支持HTTP2.0，不会带来很大困扰。然而，服务器端和中间设备的升级、更新就不是那么容易，是一个长期的过程，并且很费力、费钱。

HTTP1.X至少还会存续十年以上，大多数服务器和客户端在此期间必须同时支持1.x和2.0标准。因而，支持HTTP2.0的客户端在发起新请求以前，必须能发现服务器及中间设备是否支持HTTP2.0协议。有如下三种状况：

经过TLS和ALPN发起的新的HTTPS链接；
根据以前的信息发起的新的HTTP链接；
没有以前的信息而发起新的HTTP链接；

HTTPS协商过程当中有一个环节会使用ALPN发现和协商HTTP2.0支持状况。有 ALPN 的状况下 TLS 握手信息中包含了客户端支持的协议列表，服务端直接选择 HTTP2，全部协商在握手阶段一次完成，无需额外的报文。
注：应用层协议谈判（ALPN）是一个TLS扩展，支持在TLS握手过程当中进行协议协商，从而省去经过HTTP的Upgrade机制所需的额外往返延迟。过程以下：

客户在ClientHello消息添加新的ProtocolNameList字段，包含支持的应用程序协议列表。
该服务器检查ProtocolNameList字段，并在ServerHello消息中返回一个ProtocolName字段，用来指示服务器端选择的协议。
服务器可能只响应其中一个协议，若是它不支持任何客户端要求的协议，那么它可能选择停止链接。其结果是，TLS握手完成后，安全隧道创建好了，客户端和服务端也协商好了所使用的应用协议 - 它们能够当即开始通讯。

经过非加密信道创建HTTP2.0链接须要多作一些工做，由于HTTP1.0和HTTP2.0都使用80端口，又没有服务器是否支持HTTP2.0的其余任何信息，此时客户端只能使用HTTP upgrade 机制经过协商肯定适当的协议：

GET /default.htm HTTP/1.1 Host: server.example.com Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>

不支持HTTP/2的服务端对请求返回一个不包含升级的报头字段的响应：

HTTP/1.1 200 OK
Content-Length: 243
Content-Type: text/html
...

支持HTTP/2的服务端能够返回一个101(转换协议)响应来接受升级请求：

HTTP/1.1 101 Switching Protocols
Connection: Upgrade
Upgrade: h2c
...

在101空内容响应终止后，服务端能够开始发送HTTP/2帧。这些帧必须包含一个发起升级的请求的响应。第一个被服务端发送的HTTP/2帧是一个设置(SETTINGS)帧。在收到101响应后，客户端发送一个包含设置(SETTINGS)帧的链接序言。

使用这种Upgrade流，若是服务器不支持HTTP2.0，就当即返回HTTP1.1响应。不然，服务器就会以HTTP1.1格式返回101 switching protocols响应，而后当即切换到HTTP2.0并使用新的二进制分帧协议返回响应。不管哪一种状况，都不须要额外往返。

最后，若是客户端由于本身保存有或经过其余手段（如dns记录，手工配置）得到了HTTP2.0的支持信息，也能够直接发送HTTP2.0分帧，而没必要依赖Upgrade机制。

8.HTTP2.0数据传输示例

发起新流

在发送应用数据以前，必须建立一个新流并随之发送相应的元数据，好比优先级、HTTP首部等。HTTP2.0协议规定客户端和服务器均可以发起流，所以有两种可能：

客户端经过发送HEADERS帧来发起流，这个帧里包含带有新流ID的公用首部，能够选的31位优先值，以及一组HTTP键值对首部；
服务器端经过发送PSUH_PROMISE帧来发起推送流，这个帧与HEADERS等效，但它包含要约流ID，没有优先值。
HEADERS帧示例以下：

这两种帧的类型字段都只用于沟通新流的元数据，净荷会在DATA帧中单独发送。
发送应用数据
建立新流并发送HTTP首部以后，接下来就是利用DATA帧发送应用数据。应用数据能够分为多个DATA帧，最后一帧要翻转帧首部的END_STREAM字段。数据净荷不会被另行编码或压缩。编码方式取决于应用或服务器，纯文本，gzip压缩、图片或适配压缩格式均可以。DATA帧示例以下：

参考资料：

《WEB性能权威指南》

HPACK: Header Compression for HTTP/2

HTTP/2 头部压缩技术介绍

High Performance Browser Networking

RFC7540(HTTP2.0)

HTTP1.1学习笔记