HTTP2
在HTTP1.1中如果交错发送请求，服务器穿插返回响应：
客户端会收到这样的内容，这样根本无法判断每一行的内容是属于哪个请求的
- 帧、消息、流和TCP连接
在HTTP2.0中将一个TCP连接分为若干个流（Stream），会标识每个数据包是属于哪个请求的，每个流中可以传输若干消息（Message），每个消息消息由若干最小的二进制帧（Frame）组成。这也是HTTP/1.1与HTTP/2最大的区别所在。
HTTP2.0中帧的结构：
前三个字节表示帧的长度，第四个字节表示帧的类型，第5个字节根据不同帧的类别表示不同的含义用来传递当前帧的状态，第6个字节的第一位为保留位，后面的31代表当前帧所属流的id，后面则表示帧的载荷。
根据每个帧的头部信息就可以分析出当前帧所属于哪个流因此可以知道当前帧属于哪个请求，最后从重新组成完整的请求或响应
HTTP2.0不在是简单的请求---响应，还多出的许多类型
拆分为帧的形式解决了，多路复用，头部压缩的问题。
同时还支持其他的特性：调整响应传输的优先级，头部压缩，服务器推送（server push）
- 响应传输的优先级
浏览器在渲染页面时，并非所有资源都具有相同的优先级:HTML 文档本身对 构建 DOM 不可或缺，CSS 对构建 CSSOM 不可或缺，而 DOM 和 CSSOM 的构 建都可能受到 JavaScript 资源的阻塞，其他资源(如图片)的优先级都可以降低。
为加快页面加载速度，所有现代浏览器都会基于资源的类型以及它在页面中的位 置排定请求的优先次序，甚至通过之前的访问来学习优先级模式——比如，之前 的渲染如果被某些资源阻塞了，那么同样的资源在下一次访问时可能就会被赋予 更高的优先级。
在 HTTP 1.x 中，浏览器极少能利用上述优先级信息，因为协议本身并不支持多路复用，也没有办法向服务器通告请求的优先级。此时，浏览器只能依赖并行连接， 且最多只能同时向一个域名发送 6 个请求。于是，在等连接可用期间，请求只能在客户端排队，从而增加了不必要的网络延迟。理论上，HTTP 管道可以解决这 个问题，只是由于缺乏支持而无法付诸实践。
HTTP 2.0 一举解决了所有这些低效的问题:浏览器可以在发现资源时立即分派请 求，指定每个流的优先级，让服务器决定最优的响应次序。这样请求就不必排队 了，既节省了时间，也最大限度地利用了每个连接。
- 头部压缩
HPACK算法是新引入HTTP/2的一个算法，用于对HTTP头部做压缩。其原理在于：
客户端与服务端维护一份共同的静态字典（Static Table），其中包含了常见头部名及常见头部名称与值的组合的代码
客户端和服务端根据先入先出的原则，维护一份可动态添加内容的共同动态字典（Dynamic Table）
客户端和服务端，支持基于该静态哈夫曼码表的哈夫曼编码（Huffman Coding）。
- 服务器推送
网站为了使请求数减少，通常采用对页面上的图片、脚本进行极简化处理。但是，这一举措十分不方便，也不高效，依然需要诸多HTTP链接来加载页面和页面资源。
HTTP/2引入了服务器推送，即服务端向客户端发送比客户端请求更多的数据。这允许服务器直接提供浏览器渲染页面所需资源，而无须浏览器在收到、解析页面后再提起一轮请求，节约了加载时间。
HTTP3
..............
