11. HTTP 2.0 概览

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

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

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

头部压缩

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

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

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

维护一份静态的字典（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”帧存放实体数据

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

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

流

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

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

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

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

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

HTTP 2 的队头阻塞

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

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

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

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

阻塞原因

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

HTTP3

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

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