1、导读
注意，这不是标题党，这是发生在我身上的真实故事。这是某大厂二面面试官，上来让我讲一下http/3.0算法。作为一个候选人，我当然不能说不会了,然后我根据我知道的知识开始分析，然后分析到一半。突然被凶。后来整个面试不在状态。当面试完之后我就给朋友打电话，我说我想发帖。最后朋友劝我，退一步海阔天空，想想不了了之。其实还是怂，导致今天写这篇文章，都不敢写这个公司的名字。
为了让你不让面试官怼，请你一定要看完这篇文章，相信一定会有用的。
2、HTTP/0.9
这个版本仅仅有GET一种方式。当时的需求很简单，就是用来传输学术上体积很小的 HTML 文件。
- 只有请求行，没有后来熟悉的请求头，请求体
- 同理，服务端只是返回数据，没有响应头，响应体这些东西。
3、HTTP/1.0
版本发布，内容大大增加。增加了POST和HEAD命令。可以发送任何形式的内容，也规定了请求和响应格式。
说明一下，1.1之前的知识点没有面试官会问。但是作为一名程序员，懂这这些东西还是很有必要的。除了同行交流，显得自己牛逼。有时候给女朋友科普装x，还是很有必要的。
4、HTTP/1.1
-
长连接 默认使用长连接，长连接就是一次连接，连接期内多次发送请求。相比于1.0 每一次请求都要进行tcp三次握手，节省了大量时间。长连接的请求时长可以在请求头中的keep-alive中设置
-
管线化 在HTTP/1.0时，只有前一次的请求发出，并得到服务器端的响应。第二次的请求才可以发出去。而在HTTP/1.1管道机制规则下，可以一次同时向服务端发出去多个请求。当然了，管线化，也有自己的缺陷。虽然是一次性发出多个，但是服务端在响应的时候还是按照请求顺序响应。这就有可能出现，前面的某个请求的响应时间很长，后面就会有很多的请求排队等候。这个现象也称为队头阻塞。
虽然可以整批发送请求，不过服务器依然需要根据请求顺序来回复浏览器的请求。不少厂子都做过管线化的实验，不过由于种种原因，他们最终都放弃这个技术。
- 支持断点续传，通过请求头中的 range 来实现
- 新增了缓存标识。E-tag，if-match，if-none-match
缺点
- 队头阻塞
- 请求头信息太多
- 多次请求，请求头重复信息太多
- 请求没有优先级
- 只有客户端请求- 服务端响应这个模式
5、HTTP/2.0
HTTP/2.0标准在2015年发布，针对 HTTP/1.1 做出了如下的改变：
- 多路复用 大家都知道HTTP/1.1 为每个域名维护了多个TCP连接，那为什么还要搞多路复用？想知道答案的可以看我上一篇文章，里面有详细的解答。 一个连接中并发多个请求或回应，而不用按照顺序一一对应。降低了延迟，大幅度提高了连接的利用率。 多路复用，每一个请求都对应一个ID。这样，我们的请求就可以分开了，响应也可以打包混合运送，之所以敢这样，就是每一个响应包裹，都有对应ID，客户端收到之后，可以根据自己ID，将数据组合。 又因为有了多路复用，我们的请求优先级也可以用到了，遇到优先级高的，可以将当前的响应立马停止，转而去处理优先级高的请求。是不是感觉非常赞呢？
- 头部压缩
- 同时发送多个请求，头部会帮我们消除重复的部分。这就是HPACK算法
客户端，服务端同时维护一张头信息表，所有的字段都会存入这张表，生成索引号码，每一次仅仅发送索引号码就可以了。这样在网络上传输就会更快。
-
二进制格式 HTTP/2 不再像 HTTP/1.1 里的纯文本形式的报文，而是全面采用了二进制格式。过这种形式对人不友好，对计算机友好。省去了计算机收到报文后，转换成二进制的过程。增加了数据传输的效率
-
数据流 HTTP/2 的数据包不是按顺序发送的，同一个连接里面连续的数据包，可能属于不同的回应。客户端发送的编号是奇数，服务端发出的偶数。客户端可以指定数据流的优先级，优先级高的请求，服务端就先响应其请求。
-
服务器推送 服务端可以主动向客户端发送消息。这样好处，就是那种我预判了你的预判的那种感觉。理解为性能优化中的预加载。
缺点 多个 HTTP 请求在复用一个 TCP 连接，下层的 TCP 协议是不知道有多少个 HTTP 请求的。所以一旦发生丢包现象，就会触发TCP的重传机制，这样一个TCP连接中的所以请求都必须等待这个丢失的包重新传回来。
虽然 HTTP/2.0 解决了 HTTP/1.1 中的队头阻塞问题，但是 HTTP/2.0 依然是基于 TCP 协议的，所以上上面描述的情况已经存在。
因为HTTP/1.1 是多车道，一条对头阻塞了，还有其他的可以请求传输。而我们的HTTP/2.0是单车道，如果因为丢包堵塞，那么就真的是堵塞了。如果堵塞时间长（丢包多），当系统达到了 2% 的丢包率时，HTTP/1.1 的传输效率反而比 HTTP/2 表现得更好。 所以各位谈恋爱的小可爱，哪有什么更好的，只是更适合你的。
6、HTTP/3.0
上面我多次提到了TCP丢包，TCP丢包。从TCP的角度来看，HTTP/2.0 已经可以算是他的巅峰了，已经很难优化了。既然得不到，那就只有毁灭他了。所以HTTP/3.0 有了一个新的协议 QUIC。但是目前各种厂商的中间设备仅支持TCP和UDP协议，那么我们只能退而求其次，传输层选用UDP，顶层加入其他算法，使其既有TCP的稳定，还能保证UDP的传输。
我们一起思考一下，QUIC的内容，既要有HTTP/2.0的优点，又要去掉他的缺点，那么：
- QUIC 实现类似于 TCP 的保证传输的可靠性。也就是在UDP的基础上自己实现一套数据丢包重传机制，并且有多个通道传输内容，当一个通道堵塞，不影响其他通道
- TLS(https安全协议)升级到1.3
- 减少合并，连接开启前的握手
