HTTP系列： HTTP2
三次握手的本质问题：信道不可靠，但是通信双方需要就某个问题达成一致，而要解决这个问题，三次通信是理论上的最小值，所以是为了满足
在不可靠信道上可靠的进行传输信息这一需求导致的。
client=>server客户端向服务端发送消息： 关键词：发
server=>cloent服务端收到了客户端发送的消息，然后回复： 关键词：收发
client=>server客户端发送收到服务端的消息的确认报文： 关键词：收
为了解决 HTTP1.0 中每请求一次就需要建立三次握手的问题，HTTP1.1 加入了 Connection: keep-alive 就可以告诉对方先不要断开链接，我之后还要用这个链接发消息。当需要断开的时候，再指定 Connection: close 的 header。
但是 HTTP1.1 中存在一个问题，就是下一次的请求需要等到上一次的请求返回响应才能发出，这就造成了队头阻塞
管道化 能解决部分问题，但是依旧解决不了 队头阻塞的问题
浏览器 一般会在同一个域名建立 6-8个 TCP链接， 如果一个队发生阻塞，就放到其他队里面，这就缓解了队头阻塞问题。
除了 队头阻塞问题 HTTP 还存在 header过大 的问题，因此，我们的网页就要做打包，也就是需要打包工具把模块合并成多个 chunk 来加载。需要把小图片合并成大图片，通过调整background:position来使用，需要把一些CSS， 图片等内链，而且静态资源的域名也要禁止携带cookie
这些都是为了减少请求次数来达到提高性能加载的目的。
HTTP2
通过
stream流来解决 http1.1 存在的问题
-
多路复用：
HTTP2发送一次请求，响应，或者一次服务端推送的流程，都是封装在一个个流里面的。- 流和流之间可以并发，还可以设置优先级，这样自然就没有了队头阻塞的问题
- 也就是复用同一个链链接，建立起多条通路(流)的意思。
-
服务端推送
-
头部压缩： 两端会维护一个索引表，通过下标来标识 header，这样传输量就少了不少，会用二进制的方式表示，用做压缩，而且压缩算法是专门设计的，叫做 HPACK。
-
队头阻塞：通过流的来标识请求、响应，同一个流的分为多个帧来传输，多个流之间可以并发，不会相互阻塞。
