这 HTTP/2 还没捂热， HTTP/3 怎么就来了？
这次又是 Google，它自己突破自己，主要也是源自于痛点，这次的痛点来自于 HTTP 依赖的 TCP。
TCP 是面向可靠的、有序的传输协议，因此会有失败重传和按序机制，而 HTTP/2 是所有流共享一个 TCP 连接，所以会有 TCP 层面的队头阻塞，当发生重传时会影响多个请求响应。
并且 TCP 是基于四元组（源IP，源端口，目标IP，目标端口）来确定连接的，而在移动网络的情况下 IP 地址会频繁的换，这会导致反复的建连。
还有 TCP 与 TLS 的叠加握手，增加了延时。
问题就出在 TCP 身上，所以 Google 就把目光瞄向了 UDP。
UDP 我们知道是无连接的，不管什么顺序，也不管你什么丢包，而 TCP 我在之前的文章说的很清楚了TCP疑难杂症解析不了解的同学可以去看看。
简单的说就是 TCP 太无私了，或者说太保守了，现在需要一种更激进的做法。
那怎么搞? TCP 改不动我就换！然后把 TCP 可靠、有序的功能提到应用层来实现，因此 Google 就研究出了 QUIC 协议。
QUIC 层来实现自己的丢包重传和拥塞控制，还有出于安全的考虑我们都会用 HTTPS ，所以需要多次握手。
上面我也已经提到了关于四元组的情况，所以在移动互联网时代这握手的消耗就更加放大了，于是 QUIC 引入了个叫 Connection ID 来标识一个链接，所以切换网络之后可以复用这个连接，达到 0 RTT 就能开始传输。
注意上图是在已经和服务端握过手之后的，由于网络切换等原因才有 0 RTT ，也就是 Connection ID 在之前生成过了。
如果是第一次建连还是需要多次握手的，我们来看一下简化的握手对比图。
所以所谓的 0RTT 是在之前已经建连的情况下。
当然还有 HTTP/2 提到的 HPACK，这个是依赖 TCP 的可靠、有序传输的，于是 QUIC 得搞了个 QPACK，也采用了静态表、动态表和哈夫曼编码。
它丰富了 HTTP/2 的静态表，从 61 项加到了 98 项。
上面提到的动态表，是用来存储未包含在静态表中的头部项，假设动态表还未收到，后面来解头部的时候肯定要被阻塞的。
所以 QPACK 就另开一条路，在单向的 Stream 里传输动态表的编解码，单向传输好了，接受端到才能开始解码，也就是说还没好你就先别管，防止做一半卡住了。
那还有前面提到的 TCP 队头阻塞， QUIC 是怎么解决的呢？毕竟它也要保证有序和可靠啊。
因为 TCP 不认识每个流分别是哪个请求的，所以它只能全部阻塞住，而 QUIC 知道，因此比如请求 A 丢包了，我就把 A 卡住了就行，请求 B 完全可以全部放行，丝毫不受影响。
可以看到基于 UDP 的 QUIC 还是很强大的，而且人家用户多，在 2018 年，互联网标准化组织 IETF 提议将 HTTP over QUIC 更名为 HTTP/3 并获得批准。
可以看到需求又推动技术的进步，由于 TCP 自身机制的限制，我们的目光已经往 UDP 上靠了，那 TCP 会不会成为历史呢？
我们拭目以待。
最后今天我们大致过了一遍 HTTP 发展的历史和它的演进之路，可以看到技术是源于需求，需求推动着技术的发展。
本质上就是人的惰性，只有痛了才会成长。
而且标准其实也是巨头们为了他们的利益推动的，不过标准确实能减轻对接的开销，统一而方便。
当然就 HTTP 来说还是有很多内容的，有很多细节，很多算法，比如拿 Connection ID 来说，不同的四元组你如何保证请求一定会转发到之前的服务器上？
所以今天我只是浅显的谈了谈大致的演进，具体的实现还是得靠各位自己摸索，或者之后有机会我再写一些。