HTTP 2.0 在性能上实现了很大的飞跃,更难得的是它在改进的同时保持了语义的不变,与 HTTP 1.1的语义完全相同!

比如请求方法、URI、状态码、头字段等概念都保留不变,这样就消除了再学习的成本,在我们的日常软件升级中,向下兼容非常重要,也是促进产品大规模使用的一个前提,不然你一升级,各种接口之类的全换了,谁还敢升。

HTTP 2.0 只在语法上做了重要改进,完全变更了 HTTP 报文的传输格式

头部压缩

HTTP 1.1 考虑了 body的压缩,但没有考虑header的压缩,经常出现传了头部上百,上千字���,但Body却只有几十字节的情况,浪费了带宽

而且我们知道从 1.1开始默认是长连接,几百上千个请求都用的这个连接,而请求的头部很多都是重复的,造成了带宽的极大浪费!

那么 HTTP 2.0 是如何解决的呢?它开发了专门的「HPACK」算法,在客户端和服务器两端建立字典,用索引号表示重复的字符串,还采用哈夫曼编码来压缩数字和整数,可以达到最高达 90% 的压缩率
image.png

  • 维护一份静态的字典(Static table),包含常见的头部名称,以及特别常见的头部名称与值的组合。这样的话如果请求响应命中了静态字典,直接发索引号即可
  • 维护一份相同的动态字典(Dynamic table),可以动态地添加字典
    • 首次请求由于「User-Agent: xxx」,「host:xxx」,「Cookie」这些的动态键值对没有命中静态字典,还是会传给服务器,但服务器收到后会基于传过来的键值对创建动态字典条目
    • 上图的「User-Agent: xxx」对应数字 62,「host:xxx」对应数字 63,这样双方都创建动态条目后,之后就可以用只传 62,63 这样的索引号来通信了!
    • 显而易见,传输数据急遽降低,极大地提升了传输效率!需要注意的是动态字典是每个连接自己维护的,也就是对于每个连接而言,首次都必须发送动态键值对
  • 支持基于静态哈夫曼码表的哈夫曼编码(Huffman Coding)
    • 对于静态、动态字典中不存在的内容,可以使用哈夫曼编码来减小体积。

二进制格式

HTTP 1.1 是纯文本形式,而 2.0 是完全的二进制形式

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

image.png
这些二进制帧只认 0,1,基于这种考虑 http 2.0 的协议解析决定采用二进制格式,使用二进制的形式虽然对人不友好,但大大方便了计算机的解析

原来使用纯文本容易出现多义性,如大小写,空白字符等,程序在处理时必须用复杂的状态机,效率低,还麻烦。而使用二进制的话可以严格规定字段大小、顺序、标志位等格式,“对就是对,错就是错”,解析起来没有歧义,实现简单,而且体积小、速度快。

HTTP 2 定义了「流」(stream)的的概念,它是二进制帧的双向传输序列,同一个消息往返的数据帧 (header 帧和 data帧)会分配一个唯一的流 ID,这样我们就能区分每一个请求。

在同一时间,请求方可以在流里发请求,应答方也可以也流里发响应,对比 HTTP 1.1 一个连接一次只能处理一次请求-应答,吞吐量大大提升

image.png
一个连接里多个流可以同时收发请求-应答数据帧,每个流中数据包按序传输组装

所有的流都是在同一个连接中流动的,这也是 HTTP 2.0 经典的多路复用(Multiplexing),另外由于每个流都是独立的,所以谁先处理好请求,谁就可以先将响应通过连接发送给对方,也就解决了队头阻塞的问题。

image.png
在 HTTP 2 中,两个请求同时发送,可以同时接收,而在 HTTP 1.1 中必须等上一个请求响应后才能处理下一个请求

HTTP 2 的队头阻塞

HTTP 2 引入的流,帧等语法层面的改造确实让其传输效率有了质的飞跃,但是它依然存在着队头阻塞

主要是因为 HTTP 2的分帧主要是在应用层处理的,而分帧最终还是要传给下层的 TCP 层经由它封装后再进行传输,每个连接最终还是顺序传输这些包

image.png
流只是我们虚拟出来的概念,最终在连接层面还是顺序传的

TCP 是可靠连接,为了保证这些包能顺序传给对方,会进行丢包重传机制,如果传了三个包,后两个包传成功,但第一个包传失败了,TCP 协议栈会把已收到的包暂存到缓存区中,停下等待第一个包的重传成功,这样的话在网络不佳的情况下只要一个包阻塞了,由于重传机制,后面的包就被阻塞了,上层应用由于拿不到包也只能干瞪眼了。

阻塞原因

由于这是 TCP 协议层面的机制,无法改造,所以HTTP2的队头阻塞是不可避免的。HTTP 3 对此进行了改进,将 TCP 换成了 UDP 来进行传输,由于 UDP是无序的,不需要断建连,包之间没有依赖关系,所以从根本上解决了“队头阻塞”。

HTTP3

当然由于 UDP 本身的这些特性不足以支撑可靠的通信,所以 Google 在 UDP 的基础上也加了TCP的连接管理,拥塞窗口,流量控制等机制,这套协议我们称之为 QUIC 协议

image.png
可以看到不管是 HTTP 2 还是 3 它们底层都支持用 TLS,保留了 HTTPS 安全的特性,这也可以理解,在互联网发展如此迅猛的今天,各大企业也越来越重视通信安全。