HTTP2

RFC协议是7540。https://tools.ietf.org/html/rfc7540

互联网标准化组织 IETF 以 SPDY 为基础，综合其他多方的意见，推出了HTTP/2（下面简称h2，h1代表HTTP/1.1），因为他们认为以前的“1.0”“1.1”造成了很多的混乱和误解，让人在实际的使用中难以区分差异，所以就决定 HTTP 协议不再使用小版本号（minor version），只使用大版本号（major version），从今往后 HTTP 协议不会出现 HTTP/2.0、2.1，只会有“HTTP/2”“HTTP/3”。

HTTP2的新特性

头部压缩

开发了专门的“HPACK”算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还釆用哈夫曼编码来压缩整数和字符串，可以达到 50%~90% 的高压缩率。

因为h1的时候尝试使用gzip压缩头部，但会受到“CRIME”攻击，所以开发了HPACK算法。

二进制格式

传输格式全面采用二进制，因为二进制只有“0”和“1”，可以严格规定字段大小、顺序、标志位等格式，解析起来没有歧义，实现简单，而且体积小、速度快，做到“内部提效”。

它把 TCP 协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据。

虚拟的“流”

消息的“碎片”到达目的地后应该怎么组装起来呢？

h2 为此定义了一个“流”（Stream）的概念，它是二进制帧的双向传输序列，同一个消息往返的帧会分配一个唯一的流 ID。你可以把它想象成一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是 h1 里的请求报文和响应报文。

因为“流”是虚拟的，实际上并不存在，所以 h2 就可以在一个 TCP 连接上用“流”同时发送多个“碎片化”的消息，这就是常说的“多路复用”（ Multiplexing）——多个往返通信都复用一个连接来处理。

在“流”的层面上看，消息是一些有序的“帧”序列，而在“连接”的层面上看，消息却是乱序收发的“帧”。多个请求 / 响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降低了延迟，大幅度提高了连接的利用率。

为了更好地利用连接，加大吞吐量，h2 还添加了一些控制帧来管理虚拟的“流”，实现了优先级和流量控制，这些特性也和 TCP 协议非常相似。

h2 还在一定程度上改变了传统的“请求 - 应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息。比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，这被称为“服务器推送”（Server Push，也叫 Cache Push）。

强化安全

出于兼容的考虑，h2 延续了 h1 的“明文”特点，可以像以前一样使用明文传输数据，不强制使用加密通信，不过格式还是二进制，只是不需要解密。

为了区分“加密”和“明文”这两个不同的版本，h2 协议定义了两个字符串标识符：“h2”表示加密的 h2，“h2c”表示明文的 h2，多出的那个字母“c”的意思是“clear text”。

在 h2 标准制定的时候（2015 年）已经发现了很多 SSL/TLS 的弱点，而新的 TLS1.3 还未发布，所以加密版本的 h2 在安全方面做了强化，要求下层的通信协议必须是 TLS1.2 以上，还要支持前向安全和 SNI，并且把几百个弱密码套件列入了“黑名单”，比如 DES、RC4、CBC、SHA-1 都不能在 h2 里使用，相当于底层用的是“TLS1.25”。

协议栈

在HTTP和TLS之间加入了HPack和Stream。

启动HTTP/2

h2c连接过程

指使用h2连接http地址的过程，发生在TCP三次握手之后，可以分为两种情况：

without prior knowledge

客户端不知道服务器是否支持h2，需要先发送一个Upgrade报文，如下：

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

这个时候服务器有两种响应可能：

• 服务器不支持h2，直接无视Upgrade头字段，返回h1响应报文。
• 服务器支持h2，返回101切换协议响应，并且随后发出连接前言（Connection Preface），包含SETTINGS帧（可以为空）

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

[ HTTP/2 connection ...

客户端收到服务器101切换协议响应后，也马上发出连接前言，并包含SETTINGS帧（可以为空）。至此，h2c连接结束。

with prior knowledge

客户端知道服务器支持h2，无需发送Upgrade报文，直接发送连接前言和SETTINGS帧，服务器收到请求后也响应连接前言和SETTINGS帧，h2c连接结束。

h2连接过程

指使用h2连接https地址的过程，发生在TCP三次握手和TLS连接之后，客户端和服务器互发连接前言后，h2连接结束。

HTTP2-Settings 头字段

从h1升级到h2的请求必须包含这个字段，用来管理h2的连接。值是 HTTP2-Settings = token68。

由于升级只适用于直接连接，发送该头字段的客户端必须在Connection头字段中发送该头字段作为连接选项，防止它被转发。

连接前言

连接两端必须都发送连接前言作为h2连接的确认。这个“连接前言”是标准的 h1 请求报文，使用纯文本的 ASCII 码格式，请求方法是特别注册的一个关键字“PRI”，全文只有 24 个字节： PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n 这里的字符组合起来就是 PRISM–棱镜计划。

整个序列之后必须紧跟一个SETTINGS帧，它可能是空的。

为了避免不必要的延迟，客户端在发送连接前言后可以立即向服务器发送额外的帧，而不必等待接收服务器的连接前言。

HTTP帧

帧的格式

h2 的帧结构有点类似 TCP 的段或者 TLS 里的记录，但报头很小，只有 9 字节，非常地节省（可以对比一下 TCP 头，它最少是 20 个字节）。

• 帧开头是 3 个字节的长度（但不包括头的 9 个字节），默认上限是 2^14，最大是 2^24，也就是说 h2 的帧通常不超过 16K，最大是 16M，代表本次在payload里面传输的数据的长度。

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

  • h2 总共定义了 10 种类型的帧，但一个字节可以表示最多 256 种，所以也允许在标准之外定义其他类型实现功能扩展。这就有点像 TLS 里扩展协议的意思了，比如 Google 的 gRPC 就利用了这个特点，定义了几种自用的新帧类型。

• 第 5 个字节是非常重要的帧标志信息，可以保存 8 个标志位，携带简单的控制信息。常用的标志位有END_HEADERS表示头数据结束，相当于 h1 里头后的空行（“\r\n”），END_STREAM表示单方向数据发送结束（即 EOS，End of Stream），相当于 h1 里 Chunked 分块结束标志（“0\r\n\r\n”）。

• 报文头里最后 4 个字节是流标