HTTP3为什么抛弃了经典的TCP，转而拥抱 QUIC 呢

大家好，我是风筝

我们在看一些关于计算机网络的数据或文章的时候，最常听到的就是 TCP、UDP、HTTP 这些，除此之外，我们或多或少可能听过 QUIC这个东西，一般跟这个词一起出现的是 HTTP3，也就是HTTP协议的3.0版本，未来2.x 版本的升级方案。

QUIC 由 Google 主导设计研发。我们都知道 HTTP 协议是应用层协议，在传输层它使用的是 TCP 作为传输协议，当然这仅仅是对于 HTTP/1 和 HTTP/2 而言的。而 QUIC 的设计的对标协议就是 TCP ，也就是说将来只要能使用 TCP 的地方，都可以用 QUIC 代替。

Google 最开始的目的就是为了替换 HTTP 协议使用的 TCP 协议，所以最开始的名字叫做 HTTP over QUIC，后来由 IETF 接管后更名为 HTTP/3。所以，现在说起 HTTP/3 ,实际指的就是利用 QUIC 协议的版本。

TCP 不好吗，为什么还要 QUIC

TCP 协议作为传输层最负盛名的协议，可谓是久经考验。只要一说到 TCP ，我们都能说出来它是一种面向连接的、可靠的、基于字节流的传输层通信协议。

TCP 通过三次握手的方式建立连接，并且通过序号、ACK确认、丢包重传以及流量控制、拥塞控制等各种繁琐又细致的方式来保证它的可靠性。

关于 TCP 的更多细节，有兴趣的可以读读我之前写的《轻解计算机网络》里的 一个网管的自我修养之TCP协议

看上去很完美了，那为什么还要重新搞个 QUIC 出来呢，而且还被作为下一代 HTTP 的实现协议。确实不存在完美的协议，TCP 协议在整个发展过程中经过了多次改进，但是由于牵扯到互联网世界浩如烟海的各种设备，每次更新、修改都要考虑兼容问题，历史包袱太重，以至于尾大不掉。

所以为了弥补 TCP 的不足，在 TCP 上直接修改不太可能，那最好的方案就是重新开发一套协议。这种协议要吸收 TCP 的精华，又要解决 TCP 的不足，这就是 QUIC 出现的意义。

TCP 的问题-队头阻塞

时至今日，互联网上大多数网站都已经支持 HTTP/2 协议了，你可以在浏览器开发者工具中看一下网络请求，其中的 Protocol 表示网络请求采用的协议。

HTTP/2的一个主要特性是使用多路复用（multiplexing），因而它可以通过同一个TCP连接发送多个逻辑数据流。复用使得很多事情变得更快更好，它带来更好的拥塞控制、更充分的带宽利用、更长久的TCP连接————这些都比以前更好了，链路能更容易实现全速传输。标头压缩技术也减少了带宽的用量。

采用HTTP/2后，浏览器对每个主机一般只需要 一个 TCP连接，而不是以前常见的六个连接。

如下图所示，HTTP/2 在使用 TCP 传输数据的时候，可以在一个连接上传输两个不同的流，红色是一个流，绿色是另外一个流，但是仍然是按顺序传输的，假设其中有一个包丢了，那整个链路上这个包后面的部分都要等待。

这就造成了阻塞，虽然一个连接可传多个流，但仍然存在单点问题。这个问题就叫做队头阻塞。

QUIC 如何解决的

TCP 这个问题是无解的，QUIC 就是为了彻底解决这个问题。

如下图所示，两台设备之间建立的是一个 QUIC 连接，但是可以同时传输多个相互隔离的数据流。例如黄色是一个数据流，蓝色是一个数据流，它俩互不影响，即便其中一个数据流有丢包的问题，也完全不会影响到其他的数据流传输。

这样一来，也就解决了 TCP 的队头阻塞问题。

为什么要基于 UDP 协议

QUIC 虽然是和TCP 平行的传输协议，工作在传输层，但是其并不是完全采用全新设计的，而是对 UDP 协议进行了包装。

UDP 是无连接的，相对于 TCP 来说，无连接就是不可靠的，没有三次握手，没有丢包重传，没有各种各样的复杂算法，但这带来了一个好处，那就是速度快。

而 QUIC 为了达到 TCP 的可靠性，所以在 UDP 的基础上增加了序号机制、丢包重传等等 UDP 没有而 TCP 具有的特性。

既然这么多功能都做了，还差一个 UDP 吗，完全全新设计一个不好吗，那样更彻底呀。

之所以不重新设计应该有两个原因：

QUIC 协议

不需要三次握手

QUIC 建立连接的速度是非常快的，不需要 TCP 那样的三次握手，称之为 0-RTT（零往返时间）及 1-RTT（1次往返时间）。

QUIC 使用了TLS 1.3传输层安全协议，所以 QUIC 传输的数据都是加密的，也就是说 HTTP/3 直接就是 HTTPS 的，不存在 HTTP 的非加密版本。

正是因为这样，所以，QUIC 建立连接的过程就是 TLS 建立连接的过程，如下图这样，首次建立连接只需要 1-RTT。

而在首次连接建立之后，QUIC 客户端就缓存了服务端发来的 Server Hello，也就是加密中所需要的一些内容。在之后重新建立连接时，只需要根据缓存内容直接加密数据，所以可以在客户端向服务端发送连接请求的同时将数据也一并带过去，这就是 0-RTT 。

连接不依靠 IP

QUIC 在建立连接后，会为这个连接分配一个连接 ID，用这个 ID 可以识别出具体的连接。

假设我正在家里用 WIFI 发送请求，但是突然有事儿出去了，马上切换到了蜂窝网络，那对于 QUIC 来说就没有什么影响。因为这个连接没有变，所以仍然可以继续执行请求，数据该怎么传还怎么传。

而如果使用的是 TCP 协议的话，那只能重新建立连接，重传之前的数据，因为 TCP 的寻址依靠的是 IP 和 端口。

未来展望

随着 QUIC 协议的不断完善和推广，其应用场景将更加广泛，对互联网传输技术产生深远的影响。未来的互联网，将是 QUIC 和 HTTP3 主导的时代。

要知道，HTTP/1 到 HTTP/2，中间用了整整 16 年才完成，这还只是针对协议做改进和优化，而 QUIC 可谓是颠覆性的修改，可想而知，其过程只会更加漫长。

还可以看看风筝往期文章

《轻解计算机网络》

「差生文具多系列」最好看的编程字体

我患上了空指针后遗症

一千个微服务之死

搭建静态网站竟然有这么多方案，而且还如此简单

被人说 Lambda 代码像屎山，那是没用下面这三个方法