一、HTTP/2概述
HTTP/2是HTTP协议的第二个大版本，相较于HTTP/1而言，HTTP/2的核心观念是“构建一个更快、更简单以及更强大”的web应用。
HTTP/2 will make our applications faster, simpler, and more robust—a rare combination—by allowing us to undo many of the HTTP/1.1 workarounds previously done within our applications and address these concerns within the transport layer itself.
HTTP/2的前身是SPDY协议，这个协议是由google开发出来的一个实验性协议，在2009年中旬发布，主要目的是为了减少网页加载延迟。这个协议的目标是：
- 减少50%的页面加载时间。
- 无需网站作者修改任何内容。
- 最小化部署的复杂性，避免对网络架构的更改。
- 与开源社区合作开发这个新协议。
- 收集真实的性能数据，验证此协议是否真的有效。
在2012年，SPDY协议得到了chrome、firefox和opera的支持，越来越多的大型网站（如google、twitter和facebook）以及小型网站都在其基础设施内部署SPDY。在被越来越多的行业采用后，SPDY已经具备了称为一个标准的条件。也正因为这样，HTTP-WG在SPDY的基础上制定了官方的HTTP/2协议。在2015年初，IESG批准了这个基于SPDY协议的HTTP/2协议。
其实很多应用目前（2020）就已经使用了SPDY协议，例如我在一个部署了阿里云CDN的网站上就看到了SPDY相关的身影：
虽然是个报错信息，但可以看出目前SPDY（HTTP/2）确实已经被广泛使用。而在实验数据上，通过模拟网络连接下载了25个最流行的网站之后，页面加载速度最高加快了55%。
So far we have only tested SPDY in lab conditions. The initial results are very encouraging: when we download the top 25 websites over simulated home network connections, we see a significant improvement in performance - pages loaded up to 55% faster.
——来源：Chromium Blog
HTTP/2没有改变HTTP的基本语义和操作，各种操作方法（如GET/POST/HEAD等）、请求头和请求体机制都没有改变，不同的只是传输的方式改变了。HTTP/1.x 协议以换行符作为纯文本的分隔符，而 HTTP/2 将所有传输的信息分割为更小的消息和帧，并采用二进制格式对它们编码。
HTTP/2的主要功能特性：
- 将HTTP协议中的纯文本传输修改成了二进制帧传输，分为头部帧和数据帧。
- 使用HPCAK对头部数据压缩，添加头部索引减少重复头部数据传输。
- 添加数据优先级，针对不同的数据源建立不同的优先级树，确保优先级高的数据不会被阻塞。
- 请求响应的复用，同一个数据流中可以同时以不同的顺序发送多个不同的帧，每个数据源只产生一个连接。
- 流控制，阻止发送方向接收方发送的大量数据，通过请求窗口限制请求速率。
- 服务端推送，打破严格的请求-响应机制，服务端也可以主动推送数据到客户端。
二、数据帧的传递方法
2.1 HTTP/2数据传输的基本元素
新的HTTP/2协议通过二进制帧来传输数据，改变了客户端与服务器之间交换数据的方式，主要涉及了三个概念：
- 帧：HTTP/2数据传输的基本单位，通过把原始的文本数据处理成二进制帧来发送。
- 消息：逻辑请求和响应构成的统一整体就是消息。
- 数据流：建立的TCP连接，承载发送一条和多条消息。
帧和消息
和HTTP/1一样，HTTP/2依旧还是保留了请求头、请求体以及响应体的部分。只不过在传输的时候被处理成了二进制的内容格式，同时把请求帧和响应帧区分开来了，两者可以单独发送。
例如以下是一个GET请求的帧格式（实际传输是二进制的）：
因为GET请求不包含请求体，因此只会有一个标头帧发送出去。而服务端响应的帧格式为：
上面的请求帧和响应帧构成的帧集合即为消息。
流
一个TCP连接上包含的多个消息即为流，它体现形式为：
2.2 每个来源一个连接
在浏览器中，一个页面存在很多请求，虽然HTTP/1.1中由连接保持机制，但是大量的连接还会使得浏览器不得不建立多个连接来连接复用。大部分的浏览器还会限制单个源的连接数量，并且由于HTTP/1.1中的keep-alive是基于pipeline的，所以一旦有些请求阻塞后会导致其他请求也阻塞。
当使用二进制帧传输后，HTTP/2不再依赖创建多个TCP连接进行连接复用。每个数据流都拆分成很多帧，而这些帧可以交错，还可以分别设定优先级。 因此，所有 HTTP/2 连接都是永久的，而且仅需要每个来源一个连接，随之带来诸多性能优势。
大多数 HTTP 传输都是短暂且急促的，而 TCP 则针对长时间的批量数据传输进行了优化。 通过重用相同的连接，HTTP/2 既可以更有效地利用每个 TCP 连接，也可以显著降低整体协议开销。 不仅如此，使用更少的连接还可以减少占用的内存和处理空间，也可以缩短完整连接路径（即，客户端、可信中介和源服务器之间的路径） 这降低了整体运行成本并提高了网络利用率和容量。 因此，迁移到 HTTP/2 不仅可以减少网络延迟，还有助于提高通量和降低运行成本。
连接数量减少对提升 HTTPS 部署的性能来说是一项特别重要的功能：可以减少开销较大的 TLS 连接数、提升会话重用率，以及从整体上减少所需的客户端和服务器资源。
三、标头压缩
每个 HTTP 传输都承载一组标头，这些标头说明了传输的资源及其属性。 在 HTTP/1.x 中，此元数据始终以纯文本形式，通常会给每个传输增加 500–800 字节的开销。如果使用 HTTP Cookie，增加的开销有时会达到上千字节。 （请参阅测量和控制协议开销。） 为了减少此开销和提升性能，HTTP/2 使用 HPACK 压缩格式压缩请求和响应标头元数据，这种格式采用两种简单但是强大的技术：
- 这种格式支持通过静态霍夫曼代码对传输的标头字段进行编码，从而减小了各个传输的大小。
- 这种格式要求客户端和服务器同时维护和更新一个包含之前见过的标头字段的索引列表（换句话说，它可以建立一个共享的压缩上下文），此列表随后会用作参考，对之前传输的值进行有效编码。
利用霍夫曼编码，可以在传输时对各个值进行压缩，而利用之前传输值的索引列表，我们可以通过传输索引值的方式对重复值进行编码，索引值可用于有效查询和重构完整的标头键值对。
图片来源：Introduction to HTTP/2。
作为一种进一步优化方式，HPACK 压缩上下文包含一个静态表和一个动态表：静态表在规范中定义，并提供了一个包含所有连接都可能使用的常用 HTTP 标头字段（例如，有效标头名称）的列表；动态表最初为空，将根据在特定连接内交换的值进行更新。 因此，为之前未见过的值采用静态 Huffman 编码，并替换每一侧静态表或动态表中已存在值的索引，可以减小每个请求的大小。
注：在 HTTP/2 中，请求和响应标头字段的定义保持不变，仅有一些微小的差异：所有标头字段名称均为小写，请求行现在拆分成各个 :method、:scheme、:authority 和 :path 伪标头字段。
四、服务端推送
HTTP/2 新增的另一个强大的新功能是，服务器可以对一个客户端请求发送多个响应。 换句话说，除了对最初请求的响应外，服务器还可以向客户端推送额外资源，而无需客户端明确地请求。
注：HTTP/2 打破了严格的请求-响应语义，支持一对多和服务器发起的推送工作流，在浏览器内外开启了全新的互动可能性。 这是一项使能功能，对我们思考协议、协议用途和使用方式具有重要的长期影响。
为什么在浏览器中需要一种此类机制呢？一个典型的网络应用包含多种资源，客户端需要检查服务器提供的文档才能逐个找到它们。 那为什么不让服务器提前推送这些资源，从而减少额外的延迟时间呢？ 服务器已经知道客户端下一步要请求什么资源，这时候服务器推送即可派上用场。
事实上，如果您在网页中内联过 CSS、JavaScript，或者通过数据 URI 内联过其他资产（请参阅资源内联），那么您就已经亲身体验过服务器推送了。 对于将资源手动内联到文档中的过程，我们实际上是在将资源推送给客户端，而不是等待客户端请求。 使用 HTTP/2，我们不仅可以实现相同结果，还会获得其他性能优势。
评论