兼顾高可靠和低延迟，Google打算用QUIC协议替代TCP/UDP

曾经终败给现在 2023-01-13 01:55 204阅读 0赞

![388f0f1976ab6f89e1673fca130504ef.png][]

![ef36cc069082744ae6e8269171198826.png][]

Google想到能否把这两种协议的优势结合起来，同时实现低时延和高可靠并将其应用到更高安全的协议上，于是就有了QUIC。

本文就来详细介绍下QUIC协议。

从TCP协议说起

当前，web平台的数据传输都基于TCP协议。TCP协议在创建连接之前需要进行三次握手（图1），如果需要提高数据交互的安全性，既增加传输层安全协议（TLS），还会增加更多的握手次数（图2）。

![94642c529ea6e21ab49b4d975e5b5480.png][]

图1：TCP三次握手示意

![c83f6ec10894521263f487db99206613.png][]

图2：TLS初始化握手示意

正因为TCP协议连接建立的成本相对较高，可以通过TCP快速打开（TCP Fast Open）来减少建立连接时的握手次数。但是该技术目前应用较少。

和TCP相反，UDP协议是无连接协议。客户端发出UDP数据包后，只能“假设”这个数据包已经被服务端接收。这样的好处是在网络传输层无需对数据包进行确认，但存在的问题就是为了确保数据传输的可靠性，应用层协议需要自己完成包传输情况的确认。

此时，QUIC协议就登场了。QUIC协议可以在1到2个数据包（取决于连接的服务器是新的还是已知的）内，完成连接的创建（包括TLS）（图3）。

![7b5fc17196f91d6c33f9d3611d89bdc0.png][]

图3：QUIC协议握手示意

QUIC协议的目的

从前文对比可以看出，QUIC协议的主要目的，是为了整合TCP协议的可靠性和UDP协议的速度和效率。QUIC的维基百科页面介绍了该协议的主要目的：

> 对于Google来说优化TCP协议是一个长期目标，QUIC旨在创建几乎等同于TCP的独立连接，但有着低延迟，并对类似SPDY的多路复用流协议有更好的支持。 如果QUIC协议的特性被证明是有效的，这些特性以后可能会被迁移入后续版本的TCP和TLS协议（它们都有很长的开发周期）。

值得注意的是，**如果QUIC的特性被证明是有效的，这些特性以后可能会被迁移到后续版本的TCP协议中**。

TCP协议的实现是高度管制的。TCP协议栈通常由操作系统实现，如Linux、Windows内核或者其他移动设备操作系统。修改TCP协议是一项浩大的工程，因为每种设备、系统的实现都需要更新。

相反的，UDP协议在操作系统层面实现相对简单，基于UDP协议实现新的协议以验证Google对于TCP协议改进的理论，验证成本相对较低。

QUIC协议内置了TLS栈，实现了自己的传输加密层，而没有使用现有的TLS 1.2。同时QUIC还包含了部分HTTP/2的实现，因此QUIC的地位看起来是这样的：

![4d5efb3bfab85eb1f4d7a4bd91044177.png][]

从图上可以看出，QUIC底层通过UDP协议替代了TCP，上层只需要一层用于和远程服务器交互的HTTP/2 API。这是因为QUIC协议已经包含了多路复用和连接管理，HTTP API只需要完成HTTP协议的解析即可。

QUIC协议特性

**1. 避免前序包阻塞**

SPDY和HTTP/2协议现在都支持将页面的多个数据（如图片、Java等）通过一个数据链接进行传输。该特性能够加快页面组件的传输速度，但是对于TCP协议来说，这会遇到前序包阻塞的问题。这是由于TCP协议在处理包时是有严格顺序的，当其中一个数据包遇到问题，TCP连接需要等待这个包完成重传之后才能继续进行。因此，即使逻辑上一个TCP连接上并行的在进行多路数据传输，其他毫无关联的数据也会因此阻塞。

![b993bfc7e710fc509b0e8999f516e3da.png][]

QUIC协议直接通过底层使用UDP协议天然的避免了该问题。由于UDP协议没有严格的顺序，当一个数据包遇到问题需要重传时，只会影响该数据包对应的资源，其他独立的资源（如其他css、js文件）不会受到影响。

![c62f1ad65fe179b36c19bcb119e578aa.png][]

**2. 减少数据包**

前文已经介绍过QUIC协议在创建连接握手时，只需要1到2个数据包即可。这对于拥有高速互联网连接的网络环境下可能没有太大的感觉，因为此时一个数据包的延时大概在10～50ms之间。

一般来说延迟在50ms之内不会有太大的感觉。但是对于无线网络来说，情况就不太一样了。且不说传统2G/3G网络，即使是4G网络，客户端和服务器之间的延时也通常在100ms以上。传统TCP+TLS协议的传输方式，在创建连接时的4个数据包和QUIC协议的1个数据包相比，连接创建上就会多耗时300ms以上。

**3. 向前纠错**

QUIC协议有一个非常独特的特性，称为向前纠错（Forward Error Correction），每个数据包除了它本身的内容之外，还包括了部分其他数据包的数据，因此少量的丢包可以通过其他包的冗余数据直接组装而无需重传。

这类似网络层的RAID 5！

目前默认的冗余量是10%，既每发送10个数据包，其冗余数据就可以重新构建一个丢失的数据包。

向前纠错牺牲了每个数据包可以发送数据的上限，但是减少了因为丢包导致的数据重传，因为数据重传将会消耗更多的时间（包括确认数据包丢失、请求重传、等待新数据包等步骤的时间消耗）。

**4. 会话重启和并行下载**

底层协议切换到UDP协议之后的另一大好处是，连接不再依赖于来源IP。

对于TCP协议来说，标识一个TCP连接需要4个参数，既来源IP、来源端口、目的IP和目的端口。其中的任一参数改变，TCP连接就需要重新创建。

这对于传统网络来说影响不大，因为来源和目的IP相对固定。但是在无线网络中，情况就大不相同了。设备在移动过程中，可能会因为网络切换（如从WIFI网络切换到4G网络环境），导致TCP连接需要重新创建。

QUIC协议使用了UDP协议，不再需要这四元组参数。同时QUIC协议实现了自己的会话标记方式，称为连接UUID。当设备网络环境切换时，连接UUID不会发生变化，因此无需重新进行握手。

该特性除了可以减少无谓的连接重连之外，还可以充分利用设备的不同网络接口，进行资源的并行下载。因为虽然这些网络接口有不同的IP，但只要他们能够共享连接UUID，就能够并行的从服务器下载数据。

QUIC协议实践

Chrome浏览器从2014年开始已经实验性的支持了QUIC协议。可以通过在Chrome浏览器中输入chrome://net-internals/\#quic查看是否已经支持QUIC协议。如果还未支持，可以在chrome://flags/\#enable-quic中进行开启。

开始Chrome浏览器对QUIC协议的支持之后，可以在chrome://net-internals/\#quic中查看到当前浏览器的QUIC一些连接。当然目前只有Google服务才支持QUIC协议（如YouTube、 Google.com）。

![668f65b27b196a8286eb844d34ae0f61.png][]

**关于防火墙**

通常系统管理员会关注防火墙的TCP规则，而忽略UDP规则。如果要在防火墙之后使用QUIC协议，除了传统web服务需要开放的80/TCP、443/TCP之外，针对QUIC还需要开放443/UDP的访问。

**服务端使用QUIC协议**

目前支持QUIC协议的web服务只有0.9版本以后的Caddy。其他常用web服务如nginx、apache等都未开始支持。curl表达了对QUIC协议支持的兴趣。

**QUIC性能优势**

在2015年的博文中，Google分享了一些关于QUIC协议实现的结果。

这些优势在诸如YouTube的视频服务上更为突出。用户报告通过QUIC协议在观看视频的时候可以减少30%的重新缓冲时间。

![aed0e5024563a686b902c5d374bccfef.png][]

**-END-**

欢迎关注“互联网架构师”，我们分享最有价值的互联网技术干货文章，助力您成为有思想的全栈架构师，我们只聊互联网、只聊架构，不聊其他！打造最有价值的架构师圈子和社区。

[388f0f1976ab6f89e1673fca130504ef.png]: /images/20221022/0c47f499eebc4259bb15a802df121316.png
[ef36cc069082744ae6e8269171198826.png]: /images/20221022/8416e7ad44bc4e5c9b02d5d2826f334e.png
[94642c529ea6e21ab49b4d975e5b5480.png]: /images/20221022/9b92375510f74166963dcaf45a34b057.png
[c83f6ec10894521263f487db99206613.png]: /images/20221022/0335747f00b444548c47035657cd6581.png
[7b5fc17196f91d6c33f9d3611d89bdc0.png]: /images/20221022/74d2398089dc47cdbbe73e8951d7fe11.png
[4d5efb3bfab85eb1f4d7a4bd91044177.png]: /images/20221022/bf0feab99aca4faf9ff08b5ac52cb57d.png
[b993bfc7e710fc509b0e8999f516e3da.png]: /images/20221022/4243a6b195a2464d88de1e124970ef18.png
[c62f1ad65fe179b36c19bcb119e578aa.png]: /images/20221022/2e414c4af4b5462ca2f610d5be020fde.png
[668f65b27b196a8286eb844d34ae0f61.png]: /images/20221022/65a7ab600ccc478a89df6d0270565a75.png
[aed0e5024563a686b902c5d374bccfef.png]: /images/20221022/ba5d0851c83f4a38a87ef91cfd06b471.png