HTTP/3 在前阵子也已经通过了提案标准，对于这个新协议，网上有不少内容和观点值得商榷，今天，我就尝试解释一些关于 QUIC 的问题。
在解释问题之前，我们先看一下 QUIC 在网络协议栈中的位置
QUIC 在网络协议栈中的位置
QUIC 是基于 UDP 来实现的传输层协议，我们可以认为 QUIC 就是传输层协议。请看图 👇
为什么要基于 UDP 来实现 QUIC
很多网络上的文章说 QUIC 基于 UDP 是因为性能原因，其实并不然，选择基于 UDP 来实现是做了一些权衡的，其中的 tradeoff 有：
- 最理想的情况下，QUIC 被设计为一个全新且独立的传输层协议直接运行在 IP 层之上
- 但这样有一个明显弊端，那就是互联网上的所有设备都需要更新内核才能识别并使用 QUIC
- 如果以内核态来实现全新的 QUIC 协议，那么 QUIC 的迭代速度仍然会像 TCP 一样缓慢
所以，QUIC 选择基于 UDP 的真正原因是：
- UDP 和 TCP 一样，是一种已经被互联网设备实现并且广泛使用的协议
- 基于 UDP 来实现 QUIC 主要是从可部署性(Deployability) 来考量的
- UDP 是在内核态中实现，其余的一些特性，我们在用户态实现，方便部署和迭代
- 在未来的某一天，我们也许可以将在 QUIC 中实验考证后的算法、特性等重新在 TCP 中实现
HTTP/3 为什么要基于 QUIC
HTTP/2 我们或多或少都有了解，与 HTTP/1.1 最大的不同在于 HTTP/2 是二进制协议，而非 HTTP/1.1 那样的基于文本的协议。
基于二进制的 HTTP/2 在传输效率上有天然的性能优势，同时，HTTP/2 也在应用层实现了多路复用特性。
但是，因为 HTTP/2 仍然采用了 TCP 作为传输层协议，TCP 的弊端诸如队头阻塞等问题仍然存在，因此，在传输层，它并不是多路复用的。
HTTP/3 为了解决 HTTP/2 的问题，所以在传输层选择了 QUIC，所以，HTTP/3 本质上就是 HTTP/2 over QUIC。
在技术演进和迭代的过程中，我们更新换代的目的在于解决一些上一代留存的问题。前面我们说了，HTTP/2 在传输层仍然选择 TCP，存在着「队头阻塞」等问题，所以，解决这些问题是 HTTP/3 的目标之一。
QUIC 在传输层引入了 「流(stream)」 的概念，并且在传输层上实现了真正意义上的多路复用。这里面有很多细节值得讨论，在这里暂且按下不表。
QUIC 的开销问题
从上图 👆 我们可以看到，超过了图中虚线的部分会带来额外的开销，并且，QUIC 的开销要高于 TCP。原因有：
- QUIC 出于灵活性和部署推广的考量，选择基于 UDP 来实现
- 很多特性是在用户态(User Space)实现的，相比内核实现的各种 TCP 优化，反而增加了开销
理论上 QUIC 会带来诸多提升，但出于种种原因，从目前实际的性能测试结果来看，采用 QUIC 的性能并没有更好。
但是，像前面所说的，协议的特性放在了用户态实现，QUIC 仍然在快速迭代和部署当中，相信未来会逐一解决这些问题的。
QUIC 的连接速度与安全性
QUIC 深度集成了 TLS，因此安全性和隐私性得到了很好的保障。
虽然加密会带来额外的开销，协议也会相对变得笨重，但带来了其他的提升：建立连接的速度更快。因为把「建立连接和加密」这两个步骤合并成了一个步骤。
参考
强烈推荐完整阅读如下的系列文章，作者是互联网协议的专家，参与了多个协议标准的制定，我也在推特上和作者有过一些互动和交流。
