深刻浅出：HTTP/2

概述

HTTP/2 的目的就是经过支持请求与响应的多路复用来减小延迟，经过压缩HTTP首部字段将协议开销降至最低，同时增长对请求优先级和服务器端推送的支持。为达成这些目标，HTTP/2 还会给咱们带来大量其余协议层面的辅助实现，好比新的流量控制、错误处理和更新机制。上述几种机制虽然不是所有，但倒是最重要的，全部Web开发者都应该理解并在本身的应用中利用它们。

HTTP/2 不会改动HTTP的语义。HTTP方法、状态码、URI及首部字段，等等这些核心概念一如往常。可是，HTTP/2 修改了格式化数据（分帧）的方式，以及客户端与服务器间传输这些数据的方式。这两点统帅全局，经过新的组帧机制向咱们的应用隐藏了全部复杂性。换句话说，全部原来的应用均可以没必要修改而在新协议运行。这固然是好事。

下面咱们就来详细介绍一下这些新的机制。

历史及其与SPDY的渊源

SPDY是谷歌开发的一个实验性协议，于2009年年中发布，其主要目标是经过解决HTTP 1.1中广为人知的一些性能限制，来减小网页的加载延迟。大体上，这个项目设定的目标以下：

• 页面加载时间（PLT，Page Load Time）下降50%；

• 无需网站做者修改任何内容；

• 把部署复杂性降至最低，无需变动网络基础设施；

• 与开源社区合做开发这个新协议；

• 收集真实性能数据，验证这个实验性协议是否有效。

2012年，这个新的实验性协议获得了Chrome、Firefox和Opera的支持，不少大型网站（如谷歌、Twitter、Facebook）都对兼容客户端提供SPDY会话。换句话说，SPDY在被行业采用并证实可以大幅提高性能以后，已经具有了成为一个标准的条件。最终，HTTP-WG（HTTP Working Group）在2012年初把HTTP/2 提到了议事日程，吸收SPDY的经验教训，并在此基础上制定官方标准。

走向HTTP/2

从那时起，SPDY 已经通过了不少变化和改进，并且在 HTTP/2 官方标准公布以前，还将有不少变化和改进。在此，有必要回顾一下HTTP/2 宣言草稿，由于这份宣言明确了该协议的范围和关键设计要求：

HTTP/2 应该知足以下条件：

• 相对于使用TCP的HTTP 1.1，用户在大多数状况下的感知延迟要有实质上、可度量的改进；

• 解决HTTP中的“队首阻塞”问题；

• 并行操做无需与服务器创建多个链接，从而改进TCP的利用率，特别是拥塞控制方面；

• 保持HTTP 1.1的语义，利用现有文档，包括（但不限于）HTTP方法、状态码、URI，以及首部字段；

• 明确规定HTTP/2 如何与HTTP 1.x互操做，特别是在中间介质上；

• 明确指出全部新的可扩展机制以及适当的扩展策略；

HTTP/2 特征

二进制分帧层

HTTP/2 性能加强的核心，全在于新增的二进制分帧层（以下图所示），它定义了如何封装HTTP消息并在客户端与服务器之间传输。

这里所谓的“层”，指的是位于套接字接口与应用可见的高层HTTP API之间的一个新机制：HTTP的语义，包括各类动词、方法、首部，都不受影响，不一样的是传输期间对它们的编码方式变了。HTTP 1.x以换行符做为纯文本的分隔符，而HTTP/2 将全部传输的信息分割为更小的消息和帧，并对它们采用二进制格式的编码。

这样一来，客户端和服务器为了相互理解，必须都使用新的二进制编码机制：HTTP 1.x客户端没法理解只支持HTTP/2 的服务器，反之亦然。不过没关系，现有的应用没必要担忧这些变化，由于客户端和服务器会替它们完成必要的分帧工做。

首部压缩

HTTP的每一次通讯都会携带一组首部，用于描述传输的资源及其属性。在HTTP 1.x中，这些元数据都是以纯文本形式发送的，一般会给每一个请求增长500～800字节的负荷。若是算上HTTP cookie，增长的负荷一般会达到上千字节。为减小这些开销并提高性能，HTTP/2会用 “HPACK” 算法来压缩头部数据。

“HPACK”算法是专门为压缩 HTTP 头部定制的算法，与 gzip、zlib 等压缩算法不一样，它是一个“有状态”的算法，须要客户端和服务器各自维护一份“索引表”，也能够说是“字典”（这有点相似 brotli），压缩和解压缩就是查表和更新表的操做。

• HTTP/2 在客户端和服务器端使用“首部表”来跟踪和存储以前发送的键－值对，对于相同的数据，再也不经过每次请求和响应发送；

• 首部表在HTTP/2 的链接存续期内始终存在，由客户端和服务器共同渐进地更新;

• 每一个新的首部键－值对要么被追加到当前表的末尾，要么替换表中以前的值。

因而，HTTP/2 链接的两端都知道已经发送了哪些首部，这些首部的值是什么，从而能够针对以前的数据只编码发送差别数据，具体以下图所示。

请求与响应首部的定义在HTTP/2 中基本没有改变，只是全部首部键必须所有小写，并且请求行要独立为:method 、:scheme 、:host 和:path 这些键－值对。

在前面的例子中，第二个请求只须要发送变化了的路径首部（:path ），其余首部没有变化，不用再发送了。这样就能够避免传输冗余的首部，从而显著减小每一个请求的开销。

通讯期间几乎不会改变的通用键－值对（用户代理、可接受的媒体类型，等等）只需发送一次。事实上，若是请求中不包含首部（例如对同一资源的轮询请求），那么首部开销就是零字节。此时全部首部都自动使用以前请求发送的首部！

二进制帧

头部数据压缩以后，HTTP/2 就要把报文拆成二进制的帧准备发送。

HTTP/2 的帧结构有点相似 TCP 的段或者 TLS 里的记录，但报头很小，只有 9 字节，很是地节省（能够对比一下 TCP 头，它最少是 20 个字节）。

二进制的格式也保证了不会有歧义，并且使用位运算可以很是简单高效地解析。

帧开头是 3 个字节的长度（但不包括头的 9 个字节），默认上限是 2^14，最大是 2^24，也就是说 HTTP/2 的帧一般不超过 16K，最大是 16M。

长度后面的一个字节是帧类型，大体能够分红数据帧和控制帧两类，HEADERS 帧和 DATA 帧属于数据帧，存放的是 HTTP 报文，而 SETTINGS、PING、PRIORITY 等则是用来管理流的控制帧。

HTTP/2 总共定义了 10 种类型的帧，但一个字节能够表示最多 256 种，因此也容许在标准以外定义其余类型实现功能扩展。这就有点像 TLS 里扩展协议的意思了，好比 Google 的 gRPC 就利用了这个特色，定义了几种自用的新帧类型。

第 5 个字节是很是重要的帧标志信息，能够保存 8 个标志位，携带简单的控制信息。经常使用的标志位有END_HEADERS表示头数据结束，至关于 HTTP/1 里头后的空行（“\r\n”），END_STREAM表示单方向数据发送结束（即 EOS，End of Stream），至关于 HTTP/1 里 Chunked 分块结束标志（“0\r\n\r\n”）。

报文头里最后 4 个字节是流标识符，也就是帧所属的“流”，接收方使用它就能够从乱序的帧里识别出具备相同流 ID 的帧序列，按顺序组装起来就实现了虚拟的“流”。

流标识符虽然有 4 个字节，但最高位被保留不用，因此只有 31 位可使用，也就是说，流标识符的上限是 2^31，大约是 21 亿。

流、消息和帧

新的二进制分帧机制改变了客户端与服务器之间交互数据的方式（以下图所示）。为了说明这个过程，咱们须要了解HTTP/2 的两个新概念。

• 流：已创建的链接上的双向字节流。

• 消息：与逻辑消息对应的完整的一系列数据帧。

• 帧：HTTP/2 通讯的最小单位，每一个帧包含帧首部，至少也会标识出当前帧所属的流。

全部HTTP/2 通讯都在一个链接上完成，这个链接能够承载任意数量的双向数据流。相应地，每一个数据流以消息的形式发送，而消息由一或多个帧组成，这些帧能够乱序发送，而后再根据每一个帧首部的流标识符从新组装。”

这简简单单的几句话里浓缩了大量的信息，咱们再重申一次。要理解HTTP/2 ，就必须理解流、消息和帧这几个基本概念。

• 全部通讯都在一个TCP链接上完成。

• 流是链接中的一个虚拟信道，能够承载双向的消息；每一个流都有一个惟一的整数标识符（一、2...N）。

• 消息是指逻辑上的HTTP消息，好比请求、响应等，由一或多个帧组成。

• 帧是最小的通讯单位，承载着特定类型的数据，如HTTP首部、负荷，等等。

简言之，HTTP/2 把HTTP协议通讯的基本单位缩小为一个一个的帧，这些帧对应着逻辑流中的消息。相应地，不少流能够并行地在同一个TCP链接上交换消息。

多向请求与响应

在HTTP 1.x中，若是客户端想发送多个并行的请求以及改进性能，那么必须使用多个TCP链接。这是HTTP 1.x交付模型的直接结果，该模型会保证每一个链接每次只交付一个响应（多个响应必须排队）。更糟糕的是，这种模型也会致使队首阻塞，从而形成底层TCP链接的效率低下。

HTTP/2 中新的二进制分帧层突破了这些限制，实现了多向请求和响应：客户端和服务器能够把HTTP消息分解为互不依赖的帧（以下图所示），而后乱序发送，最后再在另外一端把它们从新组合起来。

 

上包含了同一个链接上多个传输中的数据流：客户端正在向服务器传输一个DATA帧（stream 5），与此同时，服务器正向客户端乱序发送stream 1和stream 3的一系列帧。此时，一个链接上有3个请求/响应并行交换！

把HTTP消息分解为独立的帧，交错发送，而后在另外一端从新组装是HTTP/2 最重要的一项加强。事实上，这个机制会在整个Web技术栈中引起一系列连锁反应，从而带来巨大的性能提高，由于：

• 能够并行交错地发送请求，请求之间互不影响；

• 能够并行交错地发送响应，响应之间互不干扰；

• 只使用一个链接便可并行发送多个请求和响应；

• 消除没必要要的延迟，从而减小页面加载的时间；

• 没必要再为绕过HTTP 1.x限制而多作不少工做。

• ……

总之，HTTP/2 的二进制分帧机制解决了HTTP 1.x中存在的队首阻塞问题，也消除了并行处理和发送请求及响应时对多个链接的依赖。结果，就是应用速度更快、开发更简单、部署成本更低。

支持多向请求与响应，能够省掉针对HTTP 1.x限制所费的那些脑筋和工做，好比拼接文件、图片精灵、域名分区。相似地，经过减小TCP链接的数量，HTTP/2 也会减小客户端和服务器的CPU及内存占用。

请求优先级

把HTTP消息分解为不少独立的帧以后，就能够经过优化这些帧的交错和传输顺序，进一步提高性能。为了作到这一点，每一个流均可以带有一个31比特的优先值：

• 0 表示最高优先级。
• 2³¹ -1表示最低优先级。

有了这个优先值，客户端和服务器就能够在处理不一样的流时采起不一样的策略，以最优的方式发送流、消息和帧。具体来说，服务器能够根据流的优先级，控制资源分配（CPU、内存、带宽），而在响应数据准备好以后，优先将最高优先级的帧发送给客户端。

浏览器在渲染页面时，并不是全部资源都具备相同的优先级：HTML文档自己对构建DOM不可或缺，CSS对构建CSSOM不可或缺，而DOM和CSSOM的构建均可能受到JavaScript资源的阻塞（参见10.1节的附注栏“DOM、CSSOM和JavaScript”），其余资源（如图片）的优先级均可以下降。

为加快页面加载速度，全部现代浏览器都会基于资源的类型以及它在页面中的位置排定请求的优先次序，甚至经过以前的访问来学习优先级模式——好比，以前的渲染若是被某些资源阻塞了，那么一样的资源在下一次访问时可能就会被赋予更高的优先级。

在HTTP 1.x中，浏览器极少能利用上述优先级信息，由于协议自己并不支持多路复用，也没有办法向服务器通告请求的优先级。此时，浏览器只能依赖并行链接，且最多只能同时向一个域名发送6个请求。因而，在等链接可用期间，请求只能在客户端排队，从而增长了没必要要的网络延迟。理论上，HTTP管道能够解决这个问题，只是因为缺少支持而没法付诸实践。

HTTP/2 一举解决了全部这些低效的问题：浏览器能够在发现资源时当即分派请求，指定每一个流的优先级，让服务器决定最优的响应次序。这样请求就没必要排队了，既节省了时间，也最大限度地利用了每一个链接。

HTTP/2 没有规定处理优先级的具体算法，只是提供了一种赋予数据优先级的机制，并且要求客户端与服务器必须可以交换这些数据。这样一来，优先值做为提示信息，对应的次序排定策略可能因客户端或服务器的实现而不一样：客户端应该明确指定优先值，服务器应该根据该值处理和交付数据。

在这个规定之下，尽管你可能没法控制客户端发送的优先值，但或许你能够控制服务器。所以，在选择HTTP/2 服务器时，能够多留点心！为说明这一点，考虑下面几个问题。

• 若是服务器对全部优先值视而不见怎么办？

• 高优先值的流必定优先处理吗？

• 是否存在不一样优先级的流应该交错的状况？

若是服务器不理睬全部优先值，那么可能会致使应用响应变慢：浏览器明明在等关键的CSS和JavaScript，服务器却在发送图片，从而形成渲染阻塞。不过，规定严格的优先级次序也可能带来次优的结果，由于这可能又会引入队首阻塞问题，即某个高优先级的慢请求会没必要要地阻塞其余资源的交付。

服务器能够并且应该交错发送不一样优先级别的帧。只要可能，高优先级流都应该优先，包括分配处理资源和客户端与服务器间的带宽。不过，为了最高效地利用底层链接，不一样优先级的混合也是必需的。

有了新的分帧机制后，HTTP/2 再也不依赖多个TCP链接去实现多流并行了。如今，每一个数据流都拆分红不少帧，而这些帧能够交错，还能够分别优先级。因而，全部HTTP/2 链接都是持久化的，并且客户端与服务器之间也只须要一个链接便可。

实验代表，客户端使用更少的链接确定能够下降延迟时间。HTTP/2 发送的总分组数量比HTTP差很少要少40%。而服务器处理大量并发链接的状况也变成了可伸缩性问题，由于HTTP/2 减轻了这个负担。——HTTP/2.0 Draft 2”

每一个来源一个链接显著减小了相关的资源占用：链接路径上的套接字管理工做量少了，内存占用少了，链接吞吐量大了。此外，从上到下全部层面上也都得到了相应的好处：

• 全部数据流的优先次序始终如一；

• 压缩上下文单一使得压缩效果更好；

• 因为TCP链接减小而使网络拥塞情况得以改观；

• 慢启动时间减小，拥塞和丢包恢复速度更快。

大多数HTTP链接的时间都很短，并且是突发性的，但TCP只在长时间链接传输大块数据时效率才最高。HTTP/2 经过让全部数据流共用同一个链接，能够更有效地使用TCP链接。

HTTP/2 不只可以减小网络延迟，还有助于提升吞吐量和下降运营成本！

等一等，我听你说了一大堆每一个来源一个TCP链接的好处，难道它就一点坏处都没有吗？有，固然有。

• 虽然消除了HTTP队首阻塞现象，但TCP层次上仍然存在队首阻塞（参见2.4节“队首阻塞”）；

• 若是TCP窗口缩放被禁用，那带宽延迟积效应可能会限制链接的吞吐量；

• 丢包时，TCP拥塞窗口会缩小。

上述每一点均可能对HTTP/2 链接的吞吐量和延迟性能形成不利影响。然而，除了这些局限性以外，实验代表一个TCP链接仍然是HTTP/2 基础上的最佳部署策略：

目前为止的测试代表，压缩和优先级排定带来的性能提高，已经超过了队首阻塞（特别是丢包状况下）形成的负面效果。

流量控制

在同一个TCP链接上传输多个数据流，就意味着要共享带宽。标定数据流的优先级有助于按序交付，但只有优先级还不足以肯定多个数据流或多个链接间的资源分配。为解决这个问题，HTTP/2 为数据流和链接的流量控制提供了一个简单的机制：

• 流量控制基于每一跳进行，而非端到端的控制；

• 流量控制基于窗口更新帧进行，即接收方广播本身准备接收某个数据流的多少字节，以及对整个链接要接收多少字节；

• 流量控制窗口大小经过WINDOW_UPDATE 帧更新，这个字段指定了流ID和窗口大小递增值；

• 流量控制有方向性，即接收方可能根据本身的状况为每一个流乃至整个链接设置任意窗口大小；

• 流量控制能够由接收方禁用，包括针对个别的流和针对整个链接。

HTTP/2 链接创建以后，客户端与服务器交换SETTINGS 帧，目的是设置双向的流量控制窗口大小。除此以外，任何一端均可以选择禁用个别流或整个链接的流量控制。

上面这个列表是否是让你想起了TCP流量控制？应该是，这两个机制其实是同样的。然而，因为TCP流量控制不能对同一条HTTP/2 链接内的多个流实施差别化策略，所以光有它本身是不够的。这正是HTTP/2 流量控制机制出台的缘由。

HTTP/2 标准没有规定任何特定的算法、值，或者何时发送WINDOW_UPDATE 帧。所以，实现能够选择本身的算法以匹配本身的应用场景，从而求得最佳性能。

优先级能够决定交付次序，而流量控制则能够控制HTTP/2 链接中每一个流占用的资源：接收方能够针对特定的流广播较低的窗口大小，以限制它的传输速度。

服务器推送

HTTP/2 新增的一个强大的新功能，就是服务器能够对一个客户端请求发送多个响应。换句话说，除了对最初请求的响应外，服务器还能够额外向客户端推送资源（以下图所示），而无需客户端明确地请求。

创建HTTP/2 链接后，客户端与服务器交换SETTINGS 帧，借此能够限定双向并发的流的最大数量。所以，客户端能够限定推送流的数量，或者经过把这个值设置为0而彻底禁用服务器推送。

为何须要这样一个机制呢？

一般的Web应用都由几十个资源组成，客户端须要分析服务器提供的文档才能逐个找到它们。那为何不让服务器提早就把这些资源推送给客户端，从而减小额外的时间延迟呢？服务器已经知道客户端下一步要请求什么资源了，这时候服务器推送便可派上用场。事实上，若是你在网页里嵌入过CSS、JavaScript，或者经过数据URI嵌入过其余资源，那你就已经亲身体验过服务器推送了。

把资源直接插入到文档中，就是把资源直接推送给客户端，而无需客户端请求。在HTTP/2 中，惟一的不一样就是能够把这个过程从应用中拿出来，放到HTTP协议自己来实现，并且还带来了以下好处：

• 客户端能够缓存推送过来的资源；

• 客户端能够拒绝推送过来的资源；

• 推送资源能够由不一样的页面共享；

• 服务器能够按照优先级推送资源。

全部推送的资源都遵照同源策略。换句话说，服务器不能随便将第三方资源推送给客户端，而必须是通过双方确认才行。

有了服务器推送后，HTTP 1.x时代的大多数插入或嵌入资源的作法基本上也就过期了。惟一有必要直接在网页中插入资源的状况，就是该资源只供那一个网页使用，并且编码代价不大；除此以外，全部应用都应该使用HTTP/2 服务器推送。

 

参考文章 

• https://hpbn.co/http2/

• Web性能权威指南