目录
说一下HTTP2牛币在哪里？先要知道HTTP/1.1 协议的性能问题HTTP2兼容 HTTP/1.1HTTP2头部压缩HTTP2⼆进制帧数据流多路复用，HTTP2并发传输HTTP2服务器主动推送资源HTTP2翻车的地方说一下HTTP2牛币在哪里？
先要知道HTTP/1.1 协议的性能问题
问题：HTTP/1.1延迟⾼影响⽤户体验
原因：每次开始都慢慢地走过来握手，整天排在队头就是不主动地推送一下大头儿子就是不并发执行这两件事。
1、并发连接有限，⽽且每⼀个连接都要经过TCP 和 TLS 握⼿耗时，以及TCP 慢启动过程给流量带来影响；2、队头阻塞问题，同⼀连接只能在完成⼀个 HTTP 事务（请求和响应）后，才能处理下⼀个事务；3、HTTP 头部巨⼤且重复，由于 HTTP 协议是⽆状态的，每⼀个请求都得携带 HTTP 头部，特别是对于有携带cookie 的头部，⽽ cookie 的⼤⼩通常很⼤；4、不⽀持服务器推送消息，因此当客户端需要获取通知时，只能通过定时器不断地拉取消息，这⽆疑浪费⼤量带宽和服务器资源。
HTTP2兼容 HTTP/1.1
没有在 URI ⾥引⼊新的协议名，还是基于 TCP 协议传输，只在应⽤层改变，应⽤层⽅⾯HTTP/2 把 HTTP 分解成了「语义」和「语法」两个部分，「语义」层不做改动，⽐如请求⽅法、状态码、头字段等规则保留不变。
「语法」层⾯做了很多改造，基本改变了 HTTP 报⽂的传输格式。
HTTP2头部压缩
HTTP/2 用HPACK 算法压缩头部，避免重复性，字段从 ASCII 编码改二进制编码主要包含三个部分：
静态字典；（字典前面下标的固定字段）动态字典；（字典后面没填充的空白字段）Huffman 编码（压缩算法，字段从 ASCII 编码改二进制编码）；
客户端和服务器两端都会建⽴和维护「字典」，⽤⻓度较⼩的索引号表示重复的字符串，再⽤ Huffman 编码压缩数据。
这就是所谓的 HPACK 算法：在客户端和服务器同时维护⼀张头信息表，所有字段都会存⼊这个表，⽣成⼀个索引号，以后就不发送同样字段了，只发送索引号，这样就提⾼速度了。
不过，动态表并⾮可以⽆限增⼤， 因为动态表是会占⽤内存的，动态表越⼤，内存也越⼤，容易影响服务器总体的并发能⼒，因此服务器需要限制 HTTP/2 连接时⻓或者请求次数。
HTTP2⼆进制帧
⽂本格式改成二进制格式极⼤提⾼了 HTTP 传输效率，⽽且⼆进制数据使⽤位运算能⾼效解析。
把HTTP响应，划分成了两个帧来传输，并且采⽤⼆进制来编码。
头信息帧有标志位用于携带简单的控制信息表示流的优先级、结束，
有流标识符用于标识该帧属于哪个流，方便有序组装。
数据帧存放的是通过 HPACK 算法压缩过的 HTTP 头部和包体。
数据流
HTTP/2 的数据包不是按顺序发送的，同⼀个连接⾥⾯连续的数据包，可能属于不同的回应。
因此，必须要对数据包做标记，指出它属于哪个回应。
每个请求或回应的所有数据包，称为⼀个数据流（ Stream ）。每个数据流都标记着⼀个独⼀⽆⼆的编号，其中规定客户端发出的数据流编号为奇数， 服务器发出的数据流编号为偶数
客户端还可以指定数据流的优先级。优先级⾼的请求，服务器就先响应该请求。
多路复用，HTTP2并发传输
在⼀个连接中并发多个请求或回应，⽽不⽤按照顺序⼀⼀对应。移除了 HTTP/1.1 中的串⾏请求，不需要排队等待，也就减少出现「队头阻塞」问题，降低了延迟，⼤幅度提⾼了连接的利⽤率。多个 Stream 复⽤⼀条 TCP 连接，节约了 TCP 和 TLS 握⼿时间，以及减少了 TCP 慢启动阶段对流量的影响。达到并发的效果，不同 Stream 的帧是可以乱序发送的（因此可以并发不同的 Stream ），因为每个帧的头部会携带 Stream ID 信息（奇偶区分客户端服务器），所以接收端可以通过 Stream ID 有序组装成 HTTP 消息，⽽同⼀ Stream 内部的帧必须是严格有序的。
HTTP2服务器主动推送资源
HTTP/2 还在⼀定程度上改善了传统的「请求 - 应答」⼯作模式，服务不再是被动地响应，也可以主动向客户端发送消息。
举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会⽤到的 JS、CSS ⽂件等静态资源主动发给客户端，减
少延时的等待，也就是服务器推送
怎么实现的？
客户端发起的请求，必须使⽤的是奇数号 Stream，服务器主动的推送，使⽤的是偶数号 Stream。服务器在推送资源时，会通过 PUSH_PROMISE 帧传输 HTTP 头部，并通过帧中的 Promised Stream ID 字段告知客户端，接下来会在哪个偶数号 Stream 中发送包体。
HTTP2翻车的地方
HTTP/2 是基于 TCP 协议来传输数据的，TCP 是字节流协议，TCP 层必须保证收到的字节数据是完整且连续的，这样内核才会将缓冲区⾥的数据返回给 HTTP 应⽤，那么当「前 1 个字节数据」没有到达时，后收到的字节数据只能存放在内核缓冲区⾥，只有等到这 1 个字节数据到达时，HTTP/2 应⽤层才能从内核中拿到数据，这就是HTTP/2 队头阻塞问题。
HTTP/2 主要的问题在于，多个 HTTP 请求在复⽤⼀个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以⼀旦发⽣了丢包现象，就会触发 TCP 的᯿传机制，这样在⼀个 TCP 连接中的所有的 HTTP 请求都必须等待这个丢了的包被重传回来。
有没有什么解决⽅案呢？既然是 TCP 协议⾃身的问题，那⼲脆放弃 TCP 协议，转⽽使⽤ UDP 协议作为传输层协议，这个⼤胆的决定， HTTP/3 协议做了！
