HTTP/2协议详解-优快云博客

本文链接：https://blog.youkuaiyun.com/linuxGc/article/details/109332764

HTTP/2 是 HTTP 协议自 1999 年 HTTP 1.1 发布后的首个更新，主要基于 SPDY 协议。由互联网工程任务组（IETF）的 Hypertext Transfer Protocol Bis（httpbis）工作小组进行开发。该组织于2014年12月将HTTP/2标准提议递交至IESG进行讨论，于2015年2月17日被批准。HTTP/2标准于2015年5月以RFC 7540正式发表。

概述

和http1兼容。HTTP/2 没有改动 HTTP 的应用语义。 HTTP 方法、状态代码、URI 和标头字段等核心概念一如往常。不过，HTTP/2 修改了数据格式化（分帧）以及在客户端与服务器间传输的方式。因此，所有现有的应用都可以不必修改而在新协议下运行。
传输方式改变。在HTTP/1.x中，每个 TCP 连接同时只能处理一个请求 - 响应，一个请求就会独占一个链接，用户想要多个并行的请求来提高性能，必须得使用多个TCP连接（对于同一个域名Chrome最多只能同时创建 6 个 TCP 连接）。这也是被人吐槽的原因，也是http2 要解决的一个痛点，解决方法是在链接的基础上提出了stream的概念,通过stream 来区别不同的请求。

二进制分帧
先来理解几个概念：

帧：HTTP/2 数据通信的最小单位消息：指 HTTP/2 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。
流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数ID。

HTTP/2 采用二进制格式传输数据，而非 HTTP 1.x 的文本格式，二进制协议解析起来更高效。 HTTP / 1 的请求和响应报文，都是由起始行，首部和实体正文（可选）组成，各部分之间以文本换行符分隔。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。

HTTP/2 中，同域名下所有通信都在单个连接上完成，该连接可以承载任意数量的双向数据流。每个数据流都以消息的形式发送，而消息又由一个或多个帧组成。多个帧之间可以乱序发送，根据帧首部的流标识可以重新组装。

连接多路复用

在一个 TCP 连接上，我们可以向对方不断发送帧，每帧的 stream identifier 的标明这一帧属于哪个流，然后在对方接收时，根据 stream identifier 拼接每个流的所有帧组成一整块数据。
把 HTTP/1.1 每个请求都当作一个流，那么多个请求变成多个流，请求响应数据分成多个帧，不同流中的帧交错地发送给对方，这就是 HTTP/2 中的多路复用。
流的概念实现了单连接上多请求 - 响应并行，解决了线头阻塞的问题。

在 HTTP/2 中，有了二进制分帧之后，HTTP /2 不再依赖 TCP 链接去实现多流并行了，在 HTTP/2中：

同域名下所有通信都在单个连接上完成。
单个连接可以承载任意数量的双向数据流。
数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装。

这一特性，使性能有了极大提升：

同个域名只需要占用一个 TCP 连接，消除了因多个 TCP 连接而带来的延时和内存消耗。
单个连接上可以并行交错的请求和响应，之间互不干扰。
在HTTP/2中，每个请求都可以带一个31bit的优先值，0表示最高优先级，数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。

服务器推送
服务端可以在发送页面HTML时主动推送其它资源，而不用等到浏览器解析到相应位置，发起请求再响应。例如服务端可以主动把JS和CSS文件推送给客户端，而不需要客户端解析HTML时再发送这些请求。

服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，服务器不会随便推送第三方资源给客户端。

头部压缩
HTTP 1.1请求的大小变得越来越大，有时甚至会大于TCP窗口的初始大小，因为它们需要等待带着ACK的响应回来以后才能继续被发送。HTTP/2对消息头采用HPACK（专为http/2头部设计的压缩格式）进行压缩传输，能够节省消息头占用的网络的流量。而HTTP/1.x每次请求，都会携带大量冗余头信息，浪费了很多带宽资源。

HTTP每一次通信都会携带一组头部，用于描述这次通信的的资源、浏览器属性、cookie等，
为了减少这块的资源消耗并提升性能， HTTP/2对这些首部采取了压缩策略：

HTTP/2在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键－值对，对于相同的数据，不再通过每次请求和响应发送；
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
每个新的首部键－值对要么被追加到当前表的末尾，要么替换表中之前的值。

我再用通俗的语言解释下，头部压缩需要在支持 HTTP/2 的浏览器和服务端之间：

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

实现细节
了解了 HTTP/2 头部压缩的基本原理，最后我们来看一下具体的实现细节。HTTP/2 的头部键值对有以下这些情况：

1）整个头部键值对都在字典中

  0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
| 1 |        Index (7+)         |
+---+---------------------------+

这是最简单的情况，使用一个字节就可以表示这个头部了，最左一位固定为 1，之后七位存放键值对在静态或动态字典中的索引。例如下图中，头部索引值为 2（0000010），在静态字典中查询可得 :method :GET。

2）头部名称在字典中，更新动态字典

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

对于这种情况，首先需要使用一个字节表示头部名称：左两位固定为 01，之后六位存放头部名称在静态或动态字典中的索引。接下来的一个字节第一位 H 表示头部值是否使用了哈夫曼编码，剩余七位表示头部值的长度 L，后续 L 个字节就是头部值的具体内容了。例如下图中索引值为 32（100000），在静态字典中查询可得 cookie；头部值使用了哈夫曼编码（1），长度是 28（0011100）；接下来的 28 个字节是 cookie 的值，将其进行哈夫曼解码就能得到具体内容。

3）头部名称不在字典中，更新动态字典

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

这种情况与第 2 种情况类似，只是由于头部名称不在字典中，所以第一个字节固定为 01000000；接着申明名称是否使用哈夫曼编码及长度，并放上名称的具体内容；再申明值是否使用哈夫曼编码及长度，最后放上值的具体内容。例如下图中名称的长度是 5（0000101），值的长度是 6（0000110）。对其具体内容进行哈夫曼解码后，可得 pragma: no-cache。

4）头部名称在字典中，不允许更新动态字典

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

这种情况与第 2 种情况非常类似，唯一不同之处是：第一个字节左四位固定为 0001，只剩下四位来存放索引了

5）头部名称不在字典中，不允许更新动态字典

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

这种情况与第 3 种情况非常类似，唯一不同之处是：第一个字节固定为 00010000。这种情况比较少见，没有截图，各位可以脑补。同样，这种格式的头部键值对，也不允许被添加到动态字典中，只能使用哈夫曼编码来减少体积。

实际上，协议中还规定了与 4、5 非常类似的另外两种格式：将 4、5 格式中的第一个字节第四位由 1 改为 0 即可。它表示「本次不更新动态词典」，而 4、5 表示「绝对不允许更新动态词典」。区别不是很大，这里略过。

HTTP/2 的协议协商机制
客户端在不知道服务器是否支持HTTP2协议时需要使用HTTP Upgrade 机制。

客户端首先发起一个 HTTP/1.1 请求，其中包含Upgrade首部字段，还必须包含一个且只能一个 HTTP2-Settings 首部字段。

例如：

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

Upgrade。“h2c” 标示运行在明文 TCP 之上的 HTTP/2 协议。“h2” 标示使用了 TLS(Transport Layer Security)[TLS12] 的 HTTP/2 协议
HTTP2-Settings。是一个连接相关的首部字段，它提供了用于管理 HTTP/2 连接的参数（前提是服务端接受了升级请求）
不支持 HTTP/2 的服务端响应请求时，可以认为 Upgrade 首部字段不存在。

支持 HTTP/2 的服务器响应状态码 101 (Switching Protocols) 表示接受升级协议的请求。在结束 101 响应之后，服务端可以开始发送 HTTP/2 帧。

例如：

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

[ HTTP/2 connection ...

客户端一收到 101(Switching Protocols) 响应（表示成功升级）后，就发送客户端连接前奏。客户端连接前奏以一个固定的24字节的序列开始，用十六进制表示为：0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a（相当于一个魔法值，在WireSark可以看到标识为Magic）。

为了避免不必要的延迟，允许客户端发送完连接前奏后就立即向服务端发送其他的帧，而不必等待服务端的连接前奏。

服务端发送的第一个 HTTP/2 帧必须是由一个 SETTINGS 帧组成的服务端连接前奏。

两端都要发送一个连接前奏，作为对所使用协议的最终确认，并确定 HTTP/2 连接的初始设置。