176 lines
14 KiB
Markdown
176 lines
14 KiB
Markdown
# 31 | 时代之风（下）：HTTP/2内核剖析
|
||
|
||
今天我们继续上一讲的话题，深入HTTP/2协议的内部，看看它的实现细节。
|
||
|
||
|
||
|
||
这次实验环境的URI是“/31-1”，我用Wireshark把请求响应的过程抓包存了下来，文件放在GitHub的“wireshark”目录。今天我们就对照着抓包来实地讲解HTTP/2的头部压缩、二进制帧等特性。
|
||
|
||
## 连接前言
|
||
|
||
由于HTTP/2“事实上”是基于TLS，所以在正式收发数据之前，会有TCP握手和TLS握手，这两个步骤相信你一定已经很熟悉了，所以这里就略过去不再细说。
|
||
|
||
TLS握手成功之后，客户端必须要发送一个“**连接前言**”（connection preface），用来确认建立HTTP/2连接。
|
||
|
||
这个“连接前言”是标准的HTTP/1请求报文，使用纯文本的ASCII码格式，请求方法是特别注册的一个关键字“PRI”，全文只有24个字节：
|
||
|
||
```
|
||
PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n
|
||
|
||
```
|
||
|
||
在Wireshark里，HTTP/2的“连接前言”被称为“**Magic**”，意思就是“不可知的魔法”。
|
||
|
||
所以，就不要问“为什么会是这样”了，只要服务器收到这个“有魔力的字符串”，就知道客户端在TLS上想要的是HTTP/2协议，而不是其他别的协议，后面就会都使用HTTP/2的数据格式。
|
||
|
||
## 头部压缩
|
||
|
||
确立了连接之后，HTTP/2就开始准备请求报文。
|
||
|
||
因为语义上它与HTTP/1兼容，所以报文还是由“Header+Body”构成的，但在请求发送前，必须要用“**HPACK**”算法来压缩头部数据。
|
||
|
||
“HPACK”算法是专门为压缩HTTP头部定制的算法，与gzip、zlib等压缩算法不同，它是一个“有状态”的算法，需要客户端和服务器各自维护一份“索引表”，也可以说是“字典”（这有点类似brotli），压缩和解压缩就是查表和更新表的操作。
|
||
|
||
为了方便管理和压缩，HTTP/2废除了原有的起始行概念，把起始行里面的请求方法、URI、状态码等统一转换成了头字段的形式，并且给这些“不是头字段的头字段”起了个特别的名字——“**伪头字段**”（pseudo-header fields）。而起始行里的版本号和错误原因短语因为没什么大用，顺便也给废除了。
|
||
|
||
为了与“真头字段”区分开来，这些“伪头字段”会在名字前加一个“:”，比如“:authority” “:method” “:status”，分别表示的是域名、请求方法和状态码。
|
||
|
||
现在HTTP报文头就简单了，全都是“Key-Value”形式的字段，于是HTTP/2就为一些最常用的头字段定义了一个只读的“**静态表**”（Static Table）。
|
||
|
||
下面的这个表格列出了“静态表”的一部分，这样只要查表就可以知道字段名和对应的值，比如数字“2”代表“GET”，数字“8”代表状态码200。
|
||
|
||
|
||
|
||
但如果表里只有Key没有Value，或者是自定义字段根本找不到该怎么办呢？
|
||
|
||
这就要用到“**动态表**”（Dynamic Table），它添加在静态表后面，结构相同，但会在编码解码的时候随时更新。
|
||
|
||
比如说，第一次发送请求时的“user-agent”字段长是一百多个字节，用哈夫曼压缩编码发送之后，客户端和服务器都更新自己的动态表，添加一个新的索引号“65”。那么下一次发送的时候就不用再重复发那么多字节了，只要用一个字节发送编号就好。
|
||
|
||
|
||
|
||
你可以想象得出来，随着在HTTP/2连接上发送的报文越来越多，两边的“字典”也会越来越丰富，最终每次的头部字段都会变成一两个字节的代码，原来上千字节的头用几十个字节就可以表示了，压缩效果比gzip要好得多。
|
||
|
||
## 二进制帧
|
||
|
||
头部数据压缩之后，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亿。
|
||
|
||
好了，把二进制头理清楚后，我们来看一下Wireshark抓包的帧实例：
|
||
|
||
|
||
|
||
在这个帧里，开头的三个字节是“00010a”，表示数据长度是266字节。
|
||
|
||
帧类型是1，表示HEADERS帧，负载（payload）里面存放的是被HPACK算法压缩的头部信息。
|
||
|
||
标志位是0x25，转换成二进制有3个位被置1。PRIORITY表示设置了流的优先级，END\_HEADERS表示这一个帧就是完整的头数据，END\_STREAM表示单方向数据发送结束，后续再不会有数据帧（即请求报文完毕，不会再有DATA帧/Body数据）。
|
||
|
||
最后4个字节的流标识符是整数1，表示这是客户端发起的第一个流，后面的响应数据帧也会是这个ID，也就是说在stream\[1\]里完成这个请求响应。
|
||
|
||
## 流与多路复用
|
||
|
||
弄清楚了帧结构后我们就来看HTTP/2的流与多路复用，它是HTTP/2最核心的部分。
|
||
|
||
在上一讲里我简单介绍了流的概念，不知道你“悟”得怎么样了？这里我再重复一遍：**流是二进制帧的双向传输序列**。
|
||
|
||
要搞明白流，关键是要理解帧头里的流ID。
|
||
|
||
在HTTP/2连接上，虽然帧是乱序收发的，但只要它们都拥有相同的流ID，就都属于一个流，而且在这个流里帧不是无序的，而是有着严格的先后顺序。
|
||
|
||
比如在这次的Wireshark抓包里，就有“0、1、3”一共三个流，实际上就是分配了三个流ID号，把这些帧按编号分组，再排一下队，就成了流。
|
||
|
||
|
||
|
||
在概念上，一个HTTP/2的流就等同于一个HTTP/1里的“请求-应答”。在HTTP/1里一个“请求-响应”报文来回是一次HTTP通信，在HTTP/2里一个流也承载了相同的功能。
|
||
|
||
你还可以对照着TCP来理解。TCP运行在IP之上，其实从MAC层、IP层的角度来看，TCP的“连接”概念也是“虚拟”的。但从功能上看，无论是HTTP/2的流，还是TCP的连接，都是实际存在的，所以你以后大可不必再纠结于流的“虚拟”性，把它当做是一个真实存在的实体来理解就好。
|
||
|
||
HTTP/2的流有哪些特点呢？我给你简单列了一下：
|
||
|
||
1. 流是可并发的，一个HTTP/2连接上可以同时发出多个流传输数据，也就是并发多请求，实现“多路复用”；
|
||
2. 客户端和服务器都可以创建流，双方互不干扰；
|
||
3. 流是双向的，一个流里面客户端和服务器都可以发送或接收数据帧，也就是一个“请求-应答”来回；
|
||
4. 流之间没有固定关系，彼此独立，但流内部的帧是有严格顺序的；
|
||
5. 流可以设置优先级，让服务器优先处理，比如先传HTML/CSS，后传图片，优化用户体验；
|
||
6. 流ID不能重用，只能顺序递增，客户端发起的ID是奇数，服务器端发起的ID是偶数；
|
||
7. 在流上发送“RST\_STREAM”帧可以随时终止流，取消接收或发送；
|
||
8. 第0号流比较特殊，不能关闭，也不能发送数据帧，只能发送控制帧，用于流量控制。
|
||
|
||
这里我又画了一张图，把上次的图略改了一下，显示了连接中无序的帧是如何依据流ID重组成流的。
|
||
|
||
|
||
|
||
从这些特性中，我们还可以推理出一些深层次的知识点。
|
||
|
||
比如说，HTTP/2在一个连接上使用多个流收发数据，那么它本身默认就会是长连接，所以永远不需要“Connection”头字段（keepalive或close）。
|
||
|
||
你可以再看一下Wireshark的抓包，里面发送了两个请求“/31-1”和“/favicon.ico”，始终用的是“56095<->8443”这个连接，对比一下[第8讲](https://time.geekbang.org/column/article/100502)，你就能够看出差异了。
|
||
|
||
又比如，下载大文件的时候想取消接收，在HTTP/1里只能断开TCP连接重新“三次握手”，成本很高，而在HTTP/2里就可以简单地发送一个“RST\_STREAM”中断流，而长连接会继续保持。
|
||
|
||
再比如，因为客户端和服务器两端都可以创建流，而流ID有奇数偶数和上限的区分，所以大多数的流ID都会是奇数，而且客户端在一个连接里最多只能发出2^30，也就是10亿个请求。
|
||
|
||
所以就要问了：ID用完了该怎么办呢？这个时候可以再发一个控制帧“GOAWAY”，真正关闭TCP连接。
|
||
|
||
## 流状态转换
|
||
|
||
流很重要，也很复杂。为了更好地描述运行机制，HTTP/2借鉴了TCP，根据帧的标志位实现流状态转换。当然，这些状态也是虚拟的，只是为了辅助理解。
|
||
|
||
HTTP/2的流也有一个状态转换图，虽然比TCP要简单一点，但也不那么好懂，所以今天我只画了一个简化的图，对应到一个标准的HTTP“请求-应答”。
|
||
|
||
|
||
|
||
最开始的时候流都是“**空闲**”（idle）状态，也就是“不存在”，可以理解成是待分配的“号段资源”。
|
||
|
||
当客户端发送HEADERS帧后，有了流ID，流就进入了“**打开**”状态，两端都可以收发数据，然后客户端发送一个带“END\_STREAM”标志位的帧，流就进入了“**半关闭**”状态。
|
||
|
||
这个“半关闭”状态很重要，意味着客户端的请求数据已经发送完了，需要接受响应数据，而服务器端也知道请求数据接收完毕，之后就要内部处理，再发送响应数据。
|
||
|
||
响应数据发完了之后，也要带上“END\_STREAM”标志位，表示数据发送完毕，这样流两端就都进入了“**关闭**”状态，流就结束了。
|
||
|
||
刚才也说过，流ID不能重用，所以流的生命周期就是HTTP/1里的一次完整的“请求-应答”，流关闭就是一次通信结束。
|
||
|
||
下一次再发请求就要开一个新流（而不是新连接），流ID不断增加，直到到达上限，发送“GOAWAY”帧开一个新的TCP连接，流ID就又可以重头计数。
|
||
|
||
你再看看这张图，是不是和HTTP/1里的标准“请求-应答”过程很像，只不过这是发生在虚拟的“流”上，而不是实际的TCP连接，又因为流可以并发，所以HTTP/2就可以实现无阻塞的多路复用。
|
||
|
||
## 小结
|
||
|
||
HTTP/2的内容实在是太多了，为了方便学习，我砍掉了一些特性，比如流的优先级、依赖关系、流量控制等。
|
||
|
||
但只要你掌握了今天的这些内容，以后再看RFC文档都不会有难度了。
|
||
|
||
1. HTTP/2必须先发送一个“连接前言”字符串，然后才能建立正式连接；
|
||
2. HTTP/2废除了起始行，统一使用头字段，在两端维护字段“Key-Value”的索引表，使用“HPACK”算法压缩头部；
|
||
3. HTTP/2把报文切分为多种类型的二进制帧，报头里最重要的字段是流标识符，标记帧属于哪个流；
|
||
4. 流是HTTP/2虚拟的概念，是帧的双向传输序列，相当于HTTP/1里的一次“请求-应答”；
|
||
5. 在一个HTTP/2连接上可以并发多个流，也就是多个“请求-响应”报文，这就是“多路复用”。
|
||
|
||
## 课下作业
|
||
|
||
1. HTTP/2的动态表维护、流状态转换很复杂，你认为HTTP/2还是“无状态”的吗？
|
||
2. HTTP/2的帧最大可以达到16M，你觉得大帧好还是小帧好？
|
||
3. 结合这两讲，谈谈HTTP/2是如何解决“队头阻塞”问题的。
|
||
|
||
欢迎你把自己的学习体会写在留言区，与我和其他同学一起讨论。如果你觉得有所收获，也欢迎把文章分享给你的朋友。
|
||
|
||
|
||
|