QUIC的优势与缺陷

被寄予厚望的下一代互联网传输协议，QUIC究竟有哪些优点呢？总结如下：

多路复用：QUIC升华了HTTP/2中的多路复用技术，实现了基于互相独立的多流（多通道）数据传输，从根本上解决了TCP存在的队头阻塞问题。
快速握手：即使不使用TLS，TCP建连过程也至少需要经过三次握手。而QUIC融合了握手和密钥协商交换的过程，从而实现了“初次光临1-RTT回头客0-RTT”的建连速度，大大提高了握手效率，这对于短连接频繁或者时延较高的场景非常有用
精准的RTT计算：TCP由于受到“重传报文仍然使用原始报文的序列号（sequence number）”的影响，在存在重传报文的情况下，会产生RTT计算歧义性。QUIC使用的包序号（packet number）则具有单调递增的属性，故即使发送方发送了重传报文，在收到ACK之后仍能准确计算出对应的RTT
连接迁移：前面提到，TCP的连接是由一对四元组定义的，而QUIC的连接则是由连接ID定义。因此当底层四元组变化时，TCP必须重新握手建连，QUIC则仍然能让连接继续保持，从而避免了再次握手，减少了握手时间的损耗。这一特性在移动端场景中已被证实非常有用
内生安全：TCP报文的整个头部是通过明文进行传输的，且如果需要在建立TCP连接过程中需要额外进行TLS握手，而对QUIC来说，除了例如目的ID等个别字段外，报文头部中的大部分字段也进行了加密；同时TLS1.3直接内嵌在QUIC内部，加密过程中产生的握手信息和警告直接通过QUIC进行封装传输
细致的流量控制：QUIC从不同粒度进行流量控制，即基于连接的流量控制与基于流的流量控制。由于一个QUIC连接中可以起许多条单向流或双向流，所以仅靠连接级别的流量控制还不够，仍然有可能导致整体流量过载，因此必须搭配连接级别的流量控制一起使用，才能从宏观到微观对流量进行全面控制
更快的特性迭代速度：由于TCP是在内核态实现，所以如果用户想要切换或者升级一些新特性是非常麻烦的事，比如加入新的拥塞控制算法。QUIC则是在用户态实现的，支持新特性的快速演进，这也是为何其能支持可插拔的拥塞控制算法：不仅能够在现有的成熟拥塞控制算法,，例如Cubic，BBR等之间进行轻易切换，而且还能快速部署验证基于AI的拥塞控制算法——例如基于强化学习（Reinforcement Learning）的拥塞控制算法
多路径传输提高带宽利用率：多路径QUIC（MPQUIC）是一项基于QUIC路经验证、同时类似于QUIC连接迁移的衍生技术。在保证路径合法性的基础上，它可以让一个QUIC连接同时利用多条链路来进行数据传输，从而最大化可用带宽的利用率，也提高了连接的容错能力（其中一条链路出现故障不会影响传输）。MPQUIC不仅能够利用QUIC的自带优势，在路径分配上还能借鉴多路径TCP（MPTCP）中许多成熟和优秀的算法
可以按需进行一定的扩展：在IETF的QUIC主页上，除了RFC8999-9002这四篇与QUIC本身特性密切相关的标准外，更多的RFC或者draft介绍的是QUIC的一些扩展特性，例如基于Datagram帧的不可靠数据传输扩展（RFC9221）、基于QUIC的负载均衡（draft-ietf-quic-load-balancers）等。许多扩展特性目前虽然并未被纳入到正式标准中，但它们不断为QUIC自身特性注入新的血液，也为QUIC的应用前景带来了更广阔的想象
虽然QUIC的种种优势受到了不少追捧，也已在不少公司的产品中落地，然而当前QUIC自身仍有许多问题有待解决，包括由于QUIC自身特性导致或者是一些客观情况造成的“硬伤”。具体来说，QUIC的问题主要发生在下面几种情况：
网络质量较好的链路上QUIC的表现可能还不如TCP：这一点早在2017年的SIGCOMM会议上，从谷歌发表的论文中就可以看出来[1]，其中特别提到在高带宽（超过100Mbps）、低时延（几毫秒）和低丢包率的网络中，QUIC的性能有时还不如TCP。另外在2020年的SIGCOMM会议上，谷歌专门针对QUIC的CPU使用率情况做了相关汇报[2]：2017年所做的实验可以表明，同等流量下，（2017年的）QUIC的CPU消耗是TCP/SSL的2倍左右，即使后续进行了一些优化，但是仍然要高于使用了SSL的TCP。

其实这些现象从下面几个角度来理解：
o 底层传输协议：QUIC底层使用UDP进行传输，而由于内核中设计的UDP收发包机制存在一定问题，使得其批量收发包等接口性能都不如TCP，而这也同时影响QUIC报文的传输性能[3]；
o 报文加解密：QUIC内部利用TLS对报文进行了从头到尾全方位的加密，而TCP本身并不会强制使用SSL机制来进行加密。复杂的加密过程对CPU的性能损耗不容小觑；
o ACK处理：虽然TCP和QUIC均是反馈驱动的传输协议，发送方通过来自接收方的ACK来进行丢包重传等一系列处理，然而TCP的ACK报文是直接在内核中通过tcp_ack函数进行处理，而QUIC则是不管三七二十一把包括ACK在内的所有报文先收上来放到用户层后再进行处理，这就导致了额外的用户级和内核级的上下文切换以及数据从内核转移至用户的额外拷贝；
o UDP限速（UDP throttling）：国内不少运营商会对UDP流量进行限速处理，主要原因在于UDP这类不存在流量控制、拥塞控制的协议可能会被滥用从而抢占大量链路带宽，因此才会出现许多故意把UDP报文伪装成TCP报文（俗称fake TCP）从而绕开限速的工具。另外由于UDP五元组变化频繁，这就会导致某些状态设备在短时间内需要保存大量的UDP连接，这会给设备造成很大的压力
在这里插入图片描述

图1 QUIC与TCP在CPU性能消耗上的对比。可以看出即使经过了优化，QUIC的CPU消耗率仍比TCP/SSL要高不少https://conferences.sigcomm.org/sigcomm/2020/files/slides/epiq/0%20QUIC%20and%20HTTP_3%20CPU%20Performance.pdf

对流量管理和分析不太友好：由于使用了TLS1.3作为安全性保证，以及UDP作为底层传输协议，这让Wireshark、Zeek等抓包及网络安全分析工具无法获取到QUIC报文携带的关键信息，这同时会给想要过滤QUIC流量的用户造成一定影响[4]。不过，目前较新版本的Wireshark已经支持通过导入密钥日志文件来抓取QUIC报文并进行解密，QUIC协议也自带了qlog这一机制（目前还处于草案阶段）来方便使用者进行调试并观察QUIC报文交互过程。另外还有像qvis[5]这样的可视化工具，也给未来QUIC的流量分析的提供了更多的可能性。
移动端性能：虽然设计QUIC的初衷是为了优化网页端的用户体验，但由于其结合了UDP和可靠性传输两个特性，所以人们自然而然想到如果在移动端也是用QUIC，说不定能为音视频等业务提供更高的服务质量（QoS）。事实上，已经有不少大公司在移动端将QUIC进行了商用：在国外，像Facebook就从将自家设计的QUIC开源框架mvfst用于Facebook App上并在用户侧收获了一些体验的提升[6]，Uber同样也利用了QUIC的0-RTT握手、更精准的RTT计算等特性解决了使用TCP时存在的痛点，从而提升了弱网环境下移动端的性能，让用户享受到更快的叫车速度[7]。国内例如阿里、百度等大厂也早已将自研的QUIC工程用于淘宝的短视频场景以及百度App上[8，9]。即便如此，QUIC在移动端的使用仍然会碰到一些棘手的问题[10]：
o 首先，不像socket接口，目前业界并不存在统一的SDK来进行开发，如果开发者想要将QUIC集成到移动端上，只能自己从零开始实现QUIC协议，或者使用开源的第三方库[11]；
o 其次，集成到移动端的QUIC代码必须适配多种操作系统（至少要适配目前主流的iOS和Android），这种多系统适配开发本身就有一定的难度；
o 再者，如果设备发现使用QUIC的效果不尽人意（例如有些网络中QUIC流量会被屏蔽），则相应的设备必须具备能够回退到原来HTTP或TCP版本的能力，这给应用开发者和QUIC的部署带来了一定的挑战。例如，谷歌研究人员曾在YouTube over Google’s QUIC vs Internet Middleboxes：A Tug of War between Protocol Sustainability and Application QoE这篇论文中提到，根据YouTube上的测试结果来看，如果受到中间件问题引起的传输失败（middleboxes failure）或者网络拥塞控制的影响，盲目地将QUIC流量切换回TCP这种回退行为会导致QUIC的性能有较大程度的下降[12]。因此，比起QUIC自身的连接迁移特性所带来的优势，QUIC与其他协议之间所进行的“连接迁移”可就不那么让人放心了；

o 最后，由于QUIC使用了TLS进行加密，网络供应商无法使用传统的流量管理工具来分析QUIC流量造成的各种消耗，并进行用户体验质量管理（QoE），这一点在在线视频播放中尤为重要。由于QUIC的优势，视频流占据了大部分的QUIC流量，同时，部分移动端视频又使用了一种叫做码率自适应（ABR，Adaptive Bitrate）的技术，这一技术能够根据实时网络情况以及客户端播放缓冲区的状态对码率进行动态调整，从而提高用户在线观看视频的体验。由于QUIC的安全性措施，客户端便无法获取High Bit Rate[13]。

可能会造成安全漏洞：与支持QUIC协议的浏览器以及服务器不同，诸如防火墙等这类网络中的安全设备无法识别QUIC流量。正常情况下，大部分防火墙具备检测四层至七层流量的能力，比如一旦其检测到HTTP流量就会其进行立刻警觉起来，并采取一定的保护手段以防网络攻击。但由于QUIC仅仅被视为UDP数据，也就是四层报文进行处理，QUIC流量因此避开了来自防火墙的监管，导致防火墙无法识别像披了隐身衣一般的应用层数据，这就给恶意攻击者提供了一个绕过防火墙的机会。
无法支持一些流媒体协议：前面提到，相比不支持TCP连接复用的HTTP1.0来说，HTTP/1.1引入了复用TCP的长连接模式，服务端会通过在回应报文头中添加了“Content-Length”字段来表示回应报文的数据长度，这样客户端才知道收到的回应报文在哪里结束以及下一个回应报文从哪里开始。但对于一些动态生成的内容来说，由于无法提前得知数据的长度，所以HTTP/1.1引入了另外一种传输方式——分块传输编码（chunked transfer encoding），即将网页服务器发送给网页浏览器（或者其他形式的客户端请求）的回应数据分割成多个数据块进行传输，需要注意点是这种机制只有HTTP1.1中有。因此，对于一些需要使用到分块传输编码功能的流媒体协议来说，就无法使用基于QUIC的HTTP/3，例如低时延通用媒体应用程序格式（LLCMAF, Low-Latency Common Media Application Format）[14]。
首包安全性问题：QUIC在握手期间需要交换密钥从确保后续所有发送数据的安全性。对于作为客户端在发起握手时被发送的第一个报文——Initial包来说，它却不得不牺牲自己，做出“舍己为包”的行为：虽然它携带了要进行交换的密钥，但因为是首包所以无法使用本身携带的密钥进行加密。目前QUIC对于客户端第一个Initial包的加密方法是基于Initial包的目的连接ID（随机生成）以及初始salt值（initial_salt）来生成密钥并自行加密。由于初始salt值是公开的，根据QUIC协议自身提到，这只能“抵御被动攻击者（off-path attacker），以及不知道QUIC版本的中间设备（middleboxes），而无法抵御主动攻击者（on-path attacker）“[15]，甚至有研究者认为当前QUIC协议中对于Initial包的保护实际上是形同虚设[16]。不过，目前已经有人对Initial包的保护进行了研究，例如杜克大学的研究人员提交了一份草案，其中提到客户端可以通过利用server产生的密钥来对Initial包进行加密，而这一密钥有关的配置文件（Encrypted ClientHello Configuration）则可以通过例如域名系统（Domain Name System, DNS）这类带外系统（out-of-band system）来获得。不过这个过程涉及到了Initial包头格式的修改，目前来看并不通用[17]。
连接迁移对负载均衡的影响：当由于用户网络发生变化而导致连接迁移时，由于四层负载均衡设备仍然按照四元组哈希来派发请求报文，因而本该落在某一服务器上的请求很有可能落到不同的服务器上，这么一来由于QUIC上下文的丢失便会引发连接的中断。不过目前已经有研究人员提出了一种基于结构化连接ID（structured connection ID）来进行负载均衡的策略[18]，这样就可以不再依赖四元组进行负载均衡。
连接的记忆问题：NAT是常用的一种实现内网和公网相互通信的技术。我们平时常用的例如手机、笔记本等设备使用的都是私有IP，需要通过NAT设备来进行IP转化，这样才能连接到公网。NAT设备一般会记住某一连接的状态，并在通信完成时释放相关的信息。得益于TCP报文的结构，对于使用TCP的传输来说，NAT设备可以根据TCP报文头中的SYN、FIN字段来判断TCP连接当前的状态，从而合理得进行连接记忆的释放。但对于不具备这类标记的UDP报文来说，NAT设备无法确切得知连接的终止时间点。由于QUIC基于UDP，如果NAT设备端口记忆时间过短则可能会造成QUIC连接的中断，除非人为开启QUIC的保活机制，周期性发送保活报文，避免NAT设备过早遗忘连接信息。

破旧立新的过程肯定会遇到许多的阻碍，QUIC作为传输协议的明日之星，其试图改进的不仅是TCP的逻辑，更是希望带给TCP背后整个庞大网络体系以更高的性能和更好的用户体验。路漫漫其修远兮，虽然从目前来看TCP仍是网络传输中的主流协议，HTTP1.1和HTTP2也同样是当前主流的HTTP协议，但随着QUIC和HTTP/3对应RFC标准的发布、学术界越来越多研究人员的关注、业界许多大厂的推进与部署，以及人们对于用户体验的越发重视，未来QUIC一定能闯出一片更广阔的天地来。相信随着时间的推移，QUIC的生态将会越发完善，应用场景也会越发丰富，定会带领网络传输技术迈向那片星辰大海。

注： [1]Langley A, Riddoch A, Wilk A, et al. The quic transport> protocol: Design and internet-scale eployment[C]//Proceedings of the> conference of the ACM special interest group on data communication.> 2017: 183-196.
[2]https://conferences.sigcomm.org/sigcomm/2020/files/slides/epiq/0%20QUIC%20and%20HTTP_3%20CPU%20Performance.pdf
[3]UDP协议栈的性能问题参见博文https://blog.csdn.net/csdnnews/article/details/98551466
[4]QUIC & The Dead: Which of the Most Common IDS/IPS Tools Can Best
Identify QUIC Traffic? [5]qvis.quictools.info/#/files [6]How Facebook
is bringing QUIC to billions
https://engineering.fb.com/2020/10/21/networking-traffic/how-facebook-is-bringing-quic-to-billions/
[7]Employing QUIC Protocol to Optimize Uber’s App Performance
https://eng.uber.com/employing-quic-protocol/ [8]淘宝APP在短视频场景下的IETF
QUIC最佳实践https://developer.aliyun.com/article/857436
[9]百度APP移动端网络深度优化实践分享(三)：移动端弱网优化篇https://juejin.cn/post/6844903901649616910
[10]The Future of Wireless Protocols: Google and PacketZoom Push the
Boundaries
https://www.bizety.com/2018/07/18/the-future-of-wireless-protocols-google-and-packetzoom-push-the-boundaries/
[11]关于不同QUIC开源工程已实现的功能与它们彼此之间的互通性参见https://interop.seemann.io/
[12]Chaudhary S, Sachdeva P, Mondal A, et al. YouTube over Google’s
QUIC vs Internet Middleboxes: A Tug of War between Protocol
Sustainability and Application QoE[J]. arXiv preprint
arXiv:2203.11977, 2022. [13] Does QUIC Suit Well with Modern Adaptive
Bitrate Streaming Techniques? [14]
https://www.wowza.com/blog/low-latency-cmaf-chunked-transfer-encoding
[15] RFC9001 Section 5.2 [16] Gagliardi E , Levillain O . Analysis of
QUIC Session Establishment and Its Implementations[M]. 2020. [17]
Protected QUIC Initial
Packets：https://datatracker.ietf.org/doc/pdf/draft-duke-quic-protected-initial-04
[18] QUIC-LB: Generating Routable QUIC Connection
IDs，https://datatracker.ietf.org/doc/draft-ietf-quic-load-balancers/