http1.0/http1.1/http2.0/http3.0的进化

这篇文章是梳理下自己的思路，不完整，如果有问题还希望大伙指出来

http1.0

对于最早的http，每发送一次请求，就要重新建立一次tcp连接并且销毁，我们称这样的连接为短连接。这种反复的建立连接和销毁自然会造成不小的开销，于是在1.1版本进行了优化

http1.1

1 长连接，在1.1中，最重要的优化就是将原本的短链接变为了长连接，在一段时间内tcp连接都不会断掉

2 使用了管道机制，在一个tcp连接里，能连续不断的发送很多个请求，但是实际上，虽然发送了很多个请求，但是接收端还是一个一个的处理，因此当某一个请求卡住时，后面的请求就无法被响应，造成队头阻塞

3 请求只能由客户端发送给服务端

4 没有对请求进行压缩处理，每次请求的请求头中重复部分发送会造成开销

5 没有对请求有优先级控制

http2.0

1 多路复用，针对1.1出现的管道机制中继续进行升级，这次可以在一个连接中并发（注意不是并行）地处理多个请求，而不需要一个一个地处理，这样就不会被某个请求给卡住，解决了队头阻塞问题

2 服务器推送，请求不止是客户端发送到服务端，服务端也可以主动发送到客户端

3 数据流，每一个请求或者回应对应的所有数据包都成为一个数据流，每个数据流对应一个独一无二的编号用来标记，客户端还可以指定数据流的优先级来让服务端优先处理

4 将1.1的纯文本格式变成二进制格式，优化了数据传输效率

5 头部压缩，将请求头中的重复部分进行压缩消除，提高传输速度

http3.0

在2.0中我们发现，在一个数据流中如果有一个包丢了，那么会触发重传机制，所有的http请求都得等着这个包传回来，因此在这个基础上3.0进化了。

将tcp改成了基于UDP的QUIC协议，UDP是比较奔放自由的，不会管顺序，也不管你是不是收到了，也不管丢没丢，是完全的不可靠传输。但是基于UDP的QUIC协议可以稍微实现可靠性传输，在这种情况下，如果在一个数据流中如果有一个包丢了只会阻塞这个数据流而不会影响其他的流。

2.0的头部压缩算法

说白了，没有无代价的优化，这种头部压缩的代价就是发送端和接收端都要维护一个静态字典和一个动态字典。静态字典存储了常见http报头字段名称和值，如果报头在静态字典，那直接发索引；动态字典是存储了已经发送的报头和值，那么再次发送时就可以直接用索引在动态字典中找到。并且即使是发送报头，也不会直接发，而是双方会用霍夫曼编码去进行编码发送和解码接收