参考：
发明了http1.1之后
这些年来网页请求的数量和大小越多越大
http1.1缺陷
简单时候就是安全不足和性能不高
1.高延迟--带来页面加载速度的降低 虽然近几年来网络带宽增长非常快，然而我们却并没有看到网络延迟有对应程度的降低。网络延迟问题主要由于队头阻塞(Head-Of-Line Blocking),导致带宽无法被充分利用
队头阻塞是指当顺序发送的请求序列中的一个请求因为某种原因被阻塞时，在后面排队的所有请求也一并被阻塞，会导致客户端迟迟收不到数据。针对队头阻塞,人们尝试过以下办法来解决: 引入雪碧图、将小图内联base64、使用多个域名、合并小文件等等的方式
2.无状态特性--带来的巨大HTTP头部
由于报文Header一般会携带"User Agent""Cookie""Accept""Server"等许多固定的头字段（如下图），多达几百字节甚至上千字节，但Body却经常只有几十字节（比如GET请求、 204/301/304响应），成了不折不扣的“大头儿子”。Header里携带的内容过大，在一定程度上增加了传输的成本。更要命的是，成千上万的请求响应报文里有很多字段值都是重复的，非常浪费
3.明文传输--带来的不安全性 HTTP/1.1在传输数据时，所有传输的内容都是明文，客户端和服务器端都无法验证对方的身份，这在一定程度上无法保证数据的安全性。
如果你用了有心人设的wifi，所以的流量会被截取，账户密码会被解析
4.不支持服务器推送消息
http2特性
核心就是传输数据量的大幅减少
其中数据量表现为:以二进制方式传输和Header 压缩
多推2头；浏览器有并发请求限制，tcp慢启动，加载体积大的文件会需要很多时间，多路复用和header压缩--~~！
1.多路复用 多个请求都通过一个TCP连接并发地完成（一个域名只使用一个tcp连接，1.1可以6个
2.服务端推送 服务端能够主动把资源推送给客户端
3.新的二进制格式 相比于HTTP/1.1的文本格式，二进制格式具有更好的解析性和拓展性
4.header压缩 减少传输大小
多路复用： 原先1.1虽然有长连接，但是http的连接是只能串行发送，http连接数多的话还是很慢 2.0有帧和流的概念，每个流有多个帧，多路复用就是一个tcp连接可以存在多个流，所以可以发送多个请求，然后那边可以通过帧来判断是属于哪个流，得知对应哪个请求，提高了传输性能
多路复用
简单说，一个域名只需要一个tcp连接，可以交错发送消息，不会阻塞
在 HTTP/1 中，为了性能考虑，我们会引入雪碧图、将小图内联base64、使用多个域名、合并小文件等等的方式。这一切都是因为浏览器限制了同一个域名下的请求数量（Chrome 下一般是限制六个连接），当页面中需要请求很多资源的时候，队头阻塞（Head of line blocking）会导致在达到最大请求数量时，剩余的资源需要等待其他资源请求完成后才能发起请求。
在 HTTP/2 中引入了多路复用的技术，这个技术可以只通过一个 TCP 连接就可以传输所有的请求数据。多路复用很好的解决了浏览器限制同一个域名下的请求数量的问题，同时也间接更容易实现全速传输，毕竟新开一个 TCP 连接都需要慢慢提升传输速度。
多路复用，就是在一个 TCP 连接中可以存在多条流。换句话说，也就是可以发送多个请求，对端可以通过帧中的标识知道属于哪个请求。通过这个技术，可以避免 HTTP 旧版本中的队头阻塞问题，极大的提高传输性能
- tips 在HTTP/2中，每个请求都可以带一个31bit的优先值，0表示最高优先级， 数值越大优先级越低。有了这个优先值，客户端和服务器就可以在处理不同的流时采取不同的策略，以最优的方式发送流、消息和帧。
二进制传输
原先http1.1是传header和body，且是文本传输，现在改成解析更快的二进制，且把报文拆成一帧一帧，以流的方式传输帧，帧可以乱序传输，根据帧首部的流标识可以重新组装
header压缩
在 HTTP/1 中，我们使用文本的形式传输 header，在 header 携带 cookie 的情况下，可能每次都需要重复传输几百到几千的字节。
在 HTTP /2 中，使用了 HPACK 压缩格式对传输的 header 进行编码，减少了 header 的大小。并在两端维护了索引表，用于记录出现过的 header ，后面在传输过程中就可以传输已经记录过的 header 的键名，对端收到数据后就可以通过键名找到对应的值。
服务端推送
使用场景：在浏览器刚请求HTML的时候就提前把可能会用到的JS、CSS文件发给客户端，减少等待的延迟，这被称为"服务器推送"
当然在浏览器兼容的情况下你也可以使用 prefetch 。
服务端可以主动推送，客户端也有权利选择是否接收。如果服务端推送的资源已经被浏览器缓存过，浏览器可以通过发送RST_STREAM帧来拒收。主动推送也遵守同源策略，换句话说，服务器不能随便将第三方资源推送给客户端，而必须是经过双方确认才行。
安全
这好像和http2没什么关系，关键是https好吧
主流浏览器都只支持加密后的http2，必须使用"https”协议名
http2的缺点
说是http2的原因才诞生的3，不如说是因为tcp
1.tcp和tls都需要握手，会有所延迟
2.TCP的队头阻塞
在http2中多个请求在一个tcp中，如果tcp出现丢包，需要等待重传，没传好会导致所有请求都不通。这时候甚至不如http1.1,1.1他有6条tcp通道，不会影响其他请求
http3
真正“完美”地解决了“队头阻塞”问题。
基于 UDP 创建了新协议，增加了很多新功能，多路复用、0-RTT、使用 TLS1.3 加密、流量控制、有序交付、重传等等功能
多路复用
实现了在同一物理连接上可以有多个独立的逻辑数据流。实现了数据流的单独传输，就解决了TCP中队头阻塞的问题
传输的单个数据流可以保证有序交付且不会影响其他的数据流，这样的技术就解决了之前 TCP 存在的问题。
并且 QUIC 在移动端的表现也会比 TCP 好。因为 TCP 是基于 IP 和端口去识别连接的，这种方式在多变的移动端网络环境下是很脆弱的。但是 QUIC 是通过 ID 的方式去识别一个连接，不管你网络环境如何变化，只要 ID 不变，就能迅速重连上。
握手很快
udp无连接，且用了tls比较新的版本，握手很快
实现了类似传输可靠性的功能
QUIC在UDP的基础之上增加了一层来保证数据可靠性传输。它提供了数据包重传、拥塞控制以及其他一些TCP中存在的特性。
假如说这次我要发送三个包，那么协议会算出这三个包的异或值并单独发出一个校验包，也就是总共发出了四个包。
当出现其中的非校验包丢包的情况时，可以通过另外三个包计算出丢失的数据包的内容。
当然这种技术只能使用在丢失一个包的情况下，如果出现丢失多个包就不能使用纠错机制了，只能使用重传的方式了。
小结
HTTP/2 通过多路复用、二进制流、Header 压缩等等技术，极大地提高了性能，但是还是存在着问题的
QUIC 基于 UDP 实现，是 HTTP/3 中的底层支撑协议，该协议基于 UDP，又取了 TCP 中的精华，实现了即快又可靠的协议
- 本文正在参与「掘金小册免费学啦！」活动, 点击查看活动详情
