HTTP协议的演变
HTTP/1.1
- 使用TCP长连接改善了短连接造成的性能消耗
- 支持管道网络通信，只要一个请求发送出去了，就可以发送第二个，减少整体的响应时间。
性能瓶颈：
- 请求头未压缩就发送，首部信息越多延迟越大，只能压缩
Body部分 - 发送冗余的首部。每次互相发送相同的首部造成浪费。
- 服务端是顺序响应的，可能造成队头阻塞
- 没有优先级控制
- 请求只能从客户端开始，服务器只能被动请求
HTTP/2
HTTP/2是基于HTTPS的，使用安全性也是有保障的。
- 头部压缩
- 如果同时发出多个请求，他们的头是一样或者类似的，那么会消除重复的部分
- 也就是所谓的
HPACK算法：在客户端和服务端同时维护一张表，所有字段都会存入这张表，生成一个索引号，以后就不发送同样字段了只发送索引号，这样就提高速度了。
- 二进制格式
- 全面采用了二进制格式，头信息和数据体都是二进制，并且统称为帧：头信息帧和数据帧，对计算机友好，无需再将明文的报文转换成二进制，而是直接解析二进制报文，提高了数据传输的效率
- 数据流
- HTTP/2中的数据包不是按顺序发送的，同一连接里连续的数据包，可能属于不用的响应。因此必须要对数据包进行标记，指出它属于哪个响应。
- 每个请求或响应的所有数据包，称为一个
数据流。每个数据流都标记着一个独一无二的编号，其中规定客户端发出的数据流编号为奇数，服务器发出的数据流编号为偶数。 - 客户端还可以指定数据流的优先级。优先级高的请求，服务器就先响应该请求。
- 多路复用
- HTTP/2是可以在一个连接中并发多个请求或响应，而不用按照顺序一一对应。
- 移除了HTTP/1.1中串行请求，不需要排队等待，降低了延迟，大幅度提高了连接的利用率。
- 举例来说，在一个 TCP 连接里，服务器收到了客户端 A 和 B 的两个请求，如果发现 A 处理过程非常耗时，于是就 回应 A 请求已经处理好的部分，接着回应 B 请求，完成后，再回应 A 请求剩下的部分。
- 服务器推送
- 可以主动向客户端发送消息。
- 举例来说，在浏览器刚请求 HTML 的时候，就提前把可能会用到的 JS、CSS 文件等静态资源主动发给客户端，减少延时的等待，也就是
服务器推送(Server Push，也叫 Cache Push)。
HTTP/3
HTTP2主要问题在于，多个HTTP请求在复用一个TCP连接，下层的TCP协议不清楚有多少个HTTP请求。一旦发生丢包，就会触发TCP的重传机制，这样子一个TCP连接中的所有HTTP请求都必须等待这个丢了的包被重新传回来。
- HTTP/1.1中管道传输如果一个请求阻塞，队列后的请求也都阻塞了
- HTTP/2多个请求复用同个TCP连接，一旦发生丢包，就会阻塞所有的HTTP请求。
这些都是基于TCP传输层的问题，所以HTTP/3把HTTP下层的TCP协议改成了UDP！
UDP 发生是不管顺序，也不管丢包的，所以不会出现 HTTP/1.1 的队头阻塞 和 HTTP/2 的一个丢包全部重传问题。
但UDP是不可靠传输的，但基于UDP的QUIC协议可以实现类似TCP的可靠性传输。
- QUIC协议有自己的一套机制来保证传输的可靠性。当某个流发生丢包时只会阻塞这个流，其他流不会受到影响
- TLS3升级了最新的1.3版本，优化了过程，只需要 1 个 RTT 往返时延，也就是只需要 3 次握手；头部压缩算法也升级为
QPark - HTTPS要建立一个链接，需要花费6次交互，先建立3次握手，然后是TLS/1.3的3次握手。QUIC直接将以往的TCP和TLS/1.3的六次交互合并成3次，减少了交互次数。
所以， QUIC 是一个在 UDP 之上的伪 TCP + TLS + HTTP/2 的多路复用的协议。
QUIC 是新协议，对于很多网络设备，根本不知道什么是 QUIC，只会当做 UDP，这样会出现新的问题。所以HTTP/3 现在普及的进度非常的缓慢，不知道未来 UDP 是否能够逆袭 TCP。
