该系列博客是记录自己的学习笔记，若有错误请大佬们指出
狗头声明，本文适用于：新手学习进步，老鸟回顾消遣
该系列以《图解HTTP》为基本路线，进行适当的拓展和补充，希望可以帮助大家。
（这篇笔记先记录着，后续本人有了更多实践后肯定优化补充）
这一章就写的像面经了
HTTP/2
HTTP/1有安全和性能问题，HTTP/1.1解决了安全问题（HTTPS），HTTP/2解决的是性能问题
为了解决性能问题，做了这几件事：
- 首部压缩
- 二进制分帧
- 多路复用
- 服务器推送
（1）、首部压缩
HTTP/1x 中可以使用头字段“Content-Encoding”指定 Body实体的编码方式，如 gzip 等压缩实体，提高传输效率
但是请求报文除了实体，还有头部；头部信息在HTTP/1x中并没有办法压缩发送。
HTTP/2 并没有使用传统的压缩算法，而是开发了专门的“
HPACK”算法，在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键值对，对于相同的数据，不再通过每次请求和响应发送
（2）、二进制分帧
HTTP1.x 的解析是基于文本。基于文本协议的格式解析存在天然缺陷，因为文本的表现形式有多样性，可能会有歧义，要做到健壮性考虑的场景必然很多，很麻烦。二进制则不同，只认 0 和 1 的组合。基于这种考虑 HTTP2.0 的协议解析决定采用二进制格式，实现方便且健壮。
HTTP2.0 在 应用层(HTTP2.0)和传输层(TCP/UDP)之间增加一个二进制分帧层。在不改动 HTTP1.X 的语义、方法、状态码、URI 以及首部字段的情况下, 解决了 HTTP1.1 的性能限制，改进传输性能，实现低延迟和高吞吐量。在二进制分帧层中，HTTP2.0 会将所有传输的信息分割为更小的消息和帧（frame）,并对它们采用二进制格式的编码 ，其中 HTTP1.X 的首部信息会被封装到 HEADER frame，而相应的 Request Body 则封装到 DATA frame 里面。（分帧的同时原本HTTP/1X的报文结构也看不见了）
- 帧：HTTP2.0 数据通信的最小单位消息：指 HTTP2.0 中逻辑上的 HTTP 消息。例如请求和响应等，消息由一个或多个帧组成。
- 流：存在于连接中的一个虚拟通道。流可以承载双向消息，每个流都有一个唯一的整数 ID。
想象成是一个虚拟的“数据流”，在里面流动的是一串有先后顺序的数据帧，这些数据帧按照次序组装起来就是 HTTP/1 里的请求报文和响应报文。
（3）、多路复用
HTTP/2 复用TCP连接，在一个连接里，客户端和浏览器都可以同时发送多个请求或回应，而且不用按照顺序一一对应，这样就避免了”队头堵塞”
（4）、服务器推送
HTTP/2 还在一定程度上改变了传统的“请求 - 应答”工作模式，服务器不再是完全被动地响应请求，也可以新建“流”主动向客户端发送消息。比如，在浏览器刚请求 HTML 的时候就提前把可能会用到的 JS、CSS 文件发给客户端，减少等待的延迟，这被称为“服务器推送”（Server Push，也叫 Cache Push）。
