【网络通信 -- 直播】IM 学习系列 -- 网络通信协议简介(HTTP 协议 七)

【网络通信 -- 直播】IM 学习系列 -- 网络通信协议简介(HTTP 协议 七)

【1】HTTP/2 特性概览

HTTP/2 把 HTTP 分解成了“语义”和“语法”两个部分，“语义”层不做改动，与 HTTP/1 完全一致；同时 HTTP/2 没有在 URI 里引入新的协议名，仍然用“http”表示明文协议，用“https”表示加密协议；

【1.1】头部压缩
HTTP/1 中可以用头字段“Content-Encoding”指定 Body 的编码方式，比如用 gzip 压缩来节约带宽，但报文的另一个组成部分——Header 却没有针对其的优化手段，报文 Header 一般会携带“User Agent”“Cookie”“Accept”“Server”等许多固定的头字段，多达几百字节甚至上千字节，但 Body 却经常只有几十字节；此外，请求响应报文里有很多字段值都是重复的，造成“长尾效应”，导致大量带宽消耗在了这些冗余度极高的数据上；
HTTP/2 把“头部压缩”作为性能改进的一个重点，优化的方式便是“压缩”，HTTP/2  开发了专门的“HPACK”算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还釆用哈夫曼编码来压缩整数和字符串，可以达到 50%~90% 的高压缩率；

【1.2】二进制格式
HTTP/2 全面采用二进制格式，大大方便了计算机的解析；二进制里只有“0”和“1”，可以严格规定字段大小、顺序、标志位等格式，解析起来没有歧义，实现简单，而且体积小、速度快，做到“内部提效”；HTTP/2 把 TCP 协议的部分特性挪到了应用层，把原来的“Header+Body”的消息“打散”为数个小片的二进制“帧”（Frame），用“HEADERS”帧存放头数据、“DATA”帧存放实体数据；

【1.3】虚拟的“流”
针对消息的“碎片”到达目的地后的组装问题，HTTP/2 为此定义了一个“流”（Stream）的概念，它是二进制帧的双向传输序列，同一个消息往返的帧会分配一个唯一的流 ID，可以把它想象成是一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是 HTTP/1 里的请求报文和响应报文；因为“流”是虚拟的，HTTP/2 就可以在一个 TCP 连接上用“流”同时发送多个“碎片化”的消息，这就是常说的“多路复用”（ Multiplexing）多个往返通信都复用一个连接来处理；
在“流”的层面上看，消息是一些有序的“帧”序列，而在“连接”的层面上看，消息却是乱序收发的“帧”，多个请求 / 响应之间没有了顺序关系，不需要排队等待，也就不会再出现“队头阻塞”问题，降低了延迟，大幅度提高了连接的利用率；
HTTP/2 中服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息；比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，称之为“服务器推送”（Server Push，也叫 Cache Push）；

【1.4】强化安全
出于兼容的考虑，HTTP/2 延续了 HTTP/1 的“明文”特点，可以像以前一样使用明文传输数据，不强制使用加密通信，不过格式还是二进制，只是不需要解密，但实际上 HTTP/2 是加密的，即互联网上通常所能见到的 HTTP/2 都是使用“https”协议名，跑在 TLS 上面；
为了区分“加密”和“明文”这两个不同的版本，HTTP/2 协议定义了两个字符串标识符：“h2”表示加密的 HTTP/2，“h2c”表示明文的 HTTP/2，多出的那个字母“c”的意思是“clear text”；加密版本的 HTTP/2 在安全方面做了强化，要求下层的通信协议必须是 TLS1.2 以上，还要支持前向安全和 SNI，并且把几百个弱密码套件列入了“黑名单”；

【1.5】协议栈

【2】HTTP/2内核剖析

【2.1】连接前言
HTTP/2 是基于 TLS 因此在正式收发数据之前，会有 TCP 握手和 TLS 握手，TLS 握手成功之后，客户端必须要发送一个“连接前言”（connection preface），用来确认建立 HTTP/2 连接，该“连接前言”是标准的 HTTP/1 请求报文，使用纯文本的 ASCII 码格式，请求方法是特别注册的一个关键字“PRI”，从而服务器便可知道客户端在 TLS 上想要的是 HTTP/2 协议，此后将会使用 HTTP/2 的数据格式；

PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n

【2.2】头部压缩
确立了连接之后，HTTP/2 就开始准备请求报文，因为语义上它与 HTTP/1 兼容，所以报文还是由“Header+Body”构成的，但在请求发送前，必须要用“HPACK”算法来压缩头部数据；“HPACK”算法是专门为压缩 HTTP 头部定制的算法，它是一个“有状态”的算法，需要客户端和服务器各自维护一份“索引表”，压缩和解压缩就是查表和更新表的操作；为了方便管理和压缩，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”，那么下一次发送的时候就不用再重复发那么多字节了，只要用一个字节发送编号即可；

【2.3】二进制帧
帧长度(3 个字节)，默认上限是 2^14，最大是 2^24，即 HTTP/2 的帧通常不超过 16K，最大是 16M；
帧类型(1 个字节)，可以分成数据帧和控制帧两类，HEADERS 帧和 DATA 帧属于数据帧，存放的是 HTTP 报文，而 SETTINGS、PING、PRIORITY 等则是用来管理流的控制帧；HTTP/2 总共定义了 10 种类型的帧，但一个字节可以表示最多 256 种，所以也允许在标准之外定义其他类型实现功能扩展；
帧标志，可以保存 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 亿；

【2.4】流与多路复用
流是二进制帧的双向传输序列
HTTP/2 的流的特点
1. 流是可并发的，一个 HTTP/2 连接上可以同时发出多个流传输数据，也就是并发多请求，实现“多路复用”；
2. 客户端和服务器都可以创建流，双方互不干扰；
3. 流是双向的，一个流里面客户端和服务器都可以发送或接收数据帧，也就是一个“请求 - 应答”来回；
4. 流之间没有固定关系，彼此独立，但流内部的帧是有严格顺序的；
5. 流可以设置优先级，让服务器优先处理，比如先传 HTML/CSS，后传图片，优化用户体验；
6. 流 ID 不能重用，只能顺序递增，客户端发起的 ID 是奇数，服务器端发起的 ID 是偶数；
7. 在流上发送“RST_STREAM”帧可以随时终止流，取消接收或发送；
8. 第 0 号流比较特殊，不能关闭，也不能发送数据帧，只能发送控制帧，用于流量控制；

HTTP/2 在一个连接上使用多个流收发数据，则其本身默认就会是长连接，永远不需要“Connection”头字段（keepalive 或 close）；
下载大文件的时候想取消接收，在 HTTP/1 里只能断开 TCP 连接重新“三次握手”，成本很高，而在 HTTP/2 里就可以简单地发送一个“RST_STREAM”中断流，而长连接会继续保持；
客户端和服务器两端都可以创建流，而流 ID 有奇数偶数和上限的区分，所以大多数的流 ID 都会是奇数，而且客户端在一个连接里最多只能发出 2^30，即 10 亿个请求；

【2.5】流状态转换

1. 最开始的时候流都是“空闲”（idle）状态，可以理解成是待分配的“号段资源”；
2. 当客户端发送 HEADERS 帧后，有了流 ID，流就进入了“打开”状态，两端都可以收发数据；
3. 客户端发送一个带“END_STREAM”标志位的帧，流就进入了“半关闭”状态；这个“半关闭”状态意味着客户端的请求数据已经发送完了，需要接受响应数据，而服务器端也知道请求数据接收完毕，之后就要内部处理，再发送响应数据；响应数据发完了之后，也要带上“END_STREAM”标志位，表示数据发送完毕，这样流两端就都进入了“关闭”状态，流就结束了；
流 ID 不能重用，所以流的生命周期就是 HTTP/1 里的一次完整的“请求 - 应答”，流关闭就是一次通信结束；下一次再发请求就要开一个新流（而不是新连接），流 ID 不断增加，直到到达上限，发送“GOAWAY”帧开一个新的 TCP 连接，流 ID 就又可以重头计数；

【3】HTTP/3展望

【3.1】HTTP/3 协议栈

【3.2】QUIC 协议

QUIC 通常指 iQUIC，与早期的 gQUIC 不同，是一个传输层的协议，和 TCP 是平级；

【3.3】QUIC 的特点
QUIC 基于 UDP，而 UDP 是“无连接”的，根本就不需要“握手”和“挥手”，所以天生就要比 TCP 快；QUIC 基于 UDP 实现了可靠传输，保证数据一定能够抵达目的地，同时引入了类似 HTTP/2 的“流”和“多路复用”，单个“流”是有序的，可能会因为丢包而阻塞，但其他“流”不会受到影响；为了防止网络上的中间设备（Middle Box）识别协议的细节，QUIC 全面采用加密通信，可以很好地抵御窜改和“协议僵化”（ossification）；QUIC 就直接应用了 TLS1.3，获得了 0-RTT、1-RTT 连接的优势，但 QUIC 并不是建立在 TLS 之上，而是内部“包含”了 TLS，它使用自己的帧“接管”了 TLS 里的“记录”，握手消息、警报消息都不使用 TLS 记录，直接封装成 QUIC 的帧发送，省掉了一次开销；

【3.4】QUIC 内部细节
QUIC 的基本数据传输单位是包（packet）和帧（frame），一个包由多个帧组成，包面向的是“连接”，帧面向的是“流”；
QUIC 使用不透明的“连接 ID”来标记通信的两个端点，客户端和服务器可以自行选择一组 ID 来标记自己，这样就解除了 TCP 里连接对“IP 地址 + 端口”的强绑定，支持“连接迁移”（Connection Migration）；

QUIC 的帧里有多种类型，PING、ACK 等帧用于管理连接，STREAM 帧专门用来实现流；QUIC 里的流与 HTTP/2 的流是帧的序列，但 HTTP/2 里的流都是双向的，而 QUIC 则分为双向流和单向流；
QUIC 帧普遍采用变长编码，最少只要 1 个字节，最多有 8 个字节；流 ID 的最大可用位数是 62，数量上比 HTTP/2 的 2^31 大大增加；流 ID 还保留了最低两位用作标志，第 1 位标记流的发起者，0 表示客户端，1 表示服务器；第 2 位标记流的方向，0 表示双向流，1 表示单向流；

【3.5】HTTP/3 协议
帧头只有两个字段：类型和长度，而且同样都采用变长编码，最小只需要两个字节

HTTP/3 里的帧仍然分成数据帧和控制帧两类，HEADERS 帧和 DATA 帧传输数据，但其他一些帧因为在下层的 QUIC 里有了替代，所以在 HTTP/3 里就都消失了，比如 RST_STREAM、WINDOW_UPDATE、PING 等；
头部压缩算法在 HTTP/3 里升级成了“QPACK”，使用方式上也做了改变，虽然也分成静态表和动态表，但在流上发送 HEADERS 帧时不能更新字段，只能引用，索引表的更新需要在专门的单向流上发送指令来管理，解决了 HPACK 的“队头阻塞”问题；QPACK 的字典也做了优化，静态表由之前的 61 个增加到了 98 个，而且序号从 0 开始；

【3.6】HTTP/3 服务发现
使用 HTTP/2 里的“扩展帧”，浏览器需要先用 HTTP/2 协议连接服务器，然后服务器可以在启动 HTTP/2 连接后发送一个“Alt-Svc”帧，包含一个“h3=host:port”的字符串，告诉浏览器在另一个端点上提供等价的 HTTP/3 服务；浏览器收到“Alt-Svc”帧，会使用 QUIC 异步连接指定的端口，如果连接成功，就会断开 HTTP/2 连接，改用新的 HTTP/3 收发数据；

参考致谢
本博客为博主的学习实践总结，并参考了众多博主的博文，在此表示感谢，博主若有不足之处，请批评指正。

【1】透视HTTP协议