（一）.HTTP发展到1.1存在的问题：
- 线头阻塞：TCP连接上只能发送一个请求，前面的请求未完成前，后续的请求都在排队等待。
- 多个TCP连接：虽然HTTP/1.1管线化可以支持请求并发，但是浏览器很难实现，chrome、firefox等都禁用了管线化。所以1.1版本请求并发依赖于多个TCP连接，建立TCP连接成本很高，还会存在慢启动的问题。
- 头部冗余，采用文本格式HTTP/1.X版本是采用文本格式，首部未压缩，而且每一个请求都会带上cookie、user-agent等完全相同的首部。
- 客户端需要主动请求
（二）http 2.0
1.二进制分帧层：HTTP2性能提升的核心就在于二进制分帧层。HTTP2是二进制协议，他采用二进制格式传输数据而不是1.x的文本格式。
1.1响应是文本格式，而2.0把响应划分成了两个帧，也就是说一条HTTP响应，划分成了两个帧来传输，并且采用二进制来编码。
一个TCP连接上可以有任意数量的流。
流（Stream）：已建立的TCP连接上的双向字节流，可以承载一个或多个消息。
消息（Message）：一个完整的HTTP请求或响应，由一个或多个帧组成。特定消息的帧在同一个流上发送，这意味着一个HTTP请求或响应只能在一个流上发送。
帧（Frame）：通信的基本单位。
2.多路复用
HTTP/1.1的线头阻塞和多个TCP连接的问题，HTTP2的多路复用完美解决。HTTP2让所有的通信都在一个TCP连接上完成，真正实现了请求的并发。
3.头部压缩：在1.X版本中，首部用文本格式传输，通常会给每个传输增加500-800字节的开销。而每个请求带的一些首部字段都是相同的，例如cookie、user-agent等。HTTP2为此采用HPACK压缩格式来压缩首部。头部压缩需要在浏览器和服务器端之间：
维护一份相同的静态字典，包含常见的头部名称，以及常见的头部名称和值的组合
维护一份相同的动态字典，可以动态的添加内容
通过静态Huffman编码对传输的首部字段进行编码
4.服务器端推送：主动推送到客户端。
例如：客户端请求index.html，服务器端能够额外推送script.js和style.css。
实现原理就是客户端发出页面请求时，服务器端能够分析这个页面所依赖的其他资源，主动推送到客户端的缓存，当客户端收到原始网页的请求时，它需要的资源已经位于缓存。
参考文章：https://juejin.im/post/5c0ce870f265da61171c8c66#heading-4
（三）websocket协议和 HTTP2 有关系么？
WebSocket是HTML5出的（协议），由于使用HTTP和HTTPS的端口，因此TCP连接建立后的握手消息是基于HTTP的，但是WebSocket连接除了建立和关闭时的握手，数据传输和HTTP没丁点关系了。
WebSocket则提供使用一个TCP连接进行双向通讯的机制，包括网络协议和API，以取代网页和服务器采用HTTP轮询进行双向通讯的机制。
HTTP/2 完全不能替代websocket，各有各的适用场景。做app还是偏向于websocket
原因：
- HTTP/2 Server Push 不能被代码使用，所以还得配合SSE(Server sentevent)，无论从coder还是运维的角度来看，这混搭增加了复杂度。 IE对http2以及SSE都支持的不好
- HTTP/2连接不确定性会永远保持连接，而websocket有onclose事件，对代码友好
- 多个tab页windows页可能共用一个HTTP/2连接，你无法知道Server Push来自哪一个 由于多路复用
- 实际状态 HTTP2 vs Websocket 显而易见，http2 在浏览器服务器上限制颇多，而 websocket 基本普及。