QUIC(Quick UDP Internet Connection)是Google提出的一个基于UDP的传输协定，因其高效的传输效率和多路并发的能力，曾经成为下一代互联网协议HTTP/3的底层传输协定。除了利用于Web畛域，它的劣势同样实用于一些通用的须要低提早、高吞吐个性的传输场景。本文从QUIC的由来和劣势登程，分享理论我的项目中须要思考的问题和解决思路，通过测试比照QUIC和TCP的理论传输能力，心愿有助于大家了解和实际QUIC协定。

PART 01 为什么须要QUIC？

家喻户晓，HTTP从最后的HTTP/0.9，经验了HTTP/1.x，HTTP/2到最新的HTTP/3这几个大的更新版本。在HTTP/3版本之前，HTTP底层都是用TCP传输数据，而随同着挪动互联网的倒退，网络交互场景越来越丰盛并要求及时性，传统TCP固有的性能瓶颈越来越不能满足需要，起因有以下几点：

建设连贯的握手提早大

HTTPS蕴含两个握手：1）TCP三次握手，1个RTT；2）TLS握手，2个RTT。残缺握手总共须要3个RTT，对于直播等须要首帧秒开场景，握手提早太大。

多路复用的队首阻塞

以HTTP/2多路复用为例，多个数据申请作为不同的流，共用一条TCP连贯发送，所有的流应用层都必须按序解决。若某个流的数据失落，前面其余流的数据都会被阻塞，直到失落的流数据重传实现其余流能力被持续传输。即便接收端曾经收到之后流的数据包，HTTP协定也不会告诉应用层去解决。

TCP协定的更新滞后

TCP协定是实现在操作系统内核内，然而用户端的操作系统版本升级十分艰难，很多老旧的零碎像WindowsXP还有大量用户应用，因而TCP协定的一些更新很难被疾速推广。

正是思考到以上的这些问题，QUIC在应用层之上基于UDP实现丢包复原，拥塞管制，加解密，多路复用等性能，既能优化握手提早，同时又齐全解决内核协定更新滞后问题。

PART 02 QUIC的劣势

这里列举下QUIC的次要劣势。

握手建连更快

QUIC建连工夫大概0~1 RTT，在两方面做了优化：

1）传输层应用了UDP，缩小了1个RTT三次握手的提早。

2）加密协议采纳了TLS 协定的最新版本TLS 1.3，绝对之前的TLS 1.1-1.2，TLS1.3容许客户端无需期待TLS握手实现就开始发送应用程序数据的操作，能够反对1 RTT和0RTT。

对于QUIC协定，客户端第一次建连的握手协商需1-RTT，而已建连的客户端从新建连能够应用之前协商好的缓存信息来复原TLS连贯，仅需0-RTT工夫。因而QUIC建连工夫大部分0-RTT、极少局部1-RTT，相比HTTPS的3-RTT的建连，具备极大的劣势。

防止队首阻塞的多路复用

QUIC同样反对多路复用，相比HTTP/2，QUIC的流与流之间齐全隔离的，相互没有时序依赖。如果某个流呈现丢包，不会阻塞其余流数据的传输和应用层解决，所以这个计划并不会造成队首阻塞。

反对连贯迁徙

什么是连贯迁徙？举个例子，当你用手机应用蜂窝网络加入近程会议，当你把网络切换到WLAN时，会议客户端会立马重连，视频同时呈现一瞬间的卡顿。这是因为，TCP采纳四元组（包含源IP、源端口、指标地址、指标端口）标识一个连贯，在网络切换时，客户端的IP发生变化，TCP连贯被霎时切断而后重连。连贯迁徙就是当四元组中任一值发生变化时，连贯仍旧能放弃，不中断业务。QUIC反对连贯迁徙，它用一个（个别是64位随机数）ConnectionID标识连贯，这样即便源的IP或端口发生变化，只有ConnectionID统一，连贯都能够放弃，不会产生切断重连。

可插拔的拥塞管制

QUIC是应用层协定，用户能够插拔式抉择像Cubic、BBR、Reno等拥塞控制算法，也能够依据具体的场景定制公有算法。

前向纠错（FEC）

QUIC反对前向纠错，弱网丢包环境下，动静的减少一些FEC数据包，能够缩小重传次数，晋升传输效率。

PART 03 基于QUIC的服务架构

理论我的项目在利用QUIC之前，首先要对整体服务架构做一些宏观上的思考，对上面的问题进行肯定的思考后，再去思考我的项目自身的细节，能够躲避一些技术弯路。

哪些链路须要晋升传输效率？

TCP的性能瓶颈次要体现在具备数据丢包的网络，因为TCP的AIMD（加性增、乘性减）的拥塞防止策略，网络上呈现大量丢包，TCP拥塞控制算法会指数级升高传输速率，导致其无奈无效利用带宽。对于一些比拟现实的网络，比方局域网内，TCP与QUIC的传输能力相当，传输速率受限于理论带宽，引入QUIC反而减少了复杂度。

如何兼容老的客户端？

新的架构不能影响老的客户端，因而须要同时反对TCP和QUIC。

如何实现连贯迁徙？

用户在4G和WIFI之间切换，如何实现连贯迁徙，保障业务层不中断？

QUIC是否会带来一些弊病，如何解决？

新事物产生往往会随同新的问题，QUIC实现在内核之上的应用层，用UDP代替TCP传输，也带来了一些问题：

（1）国内运营商针对UDP做QOS限速和丢包，一些企业的局域网防火墙有时候会禁用 UDP 协定，导致网络UDP传输低效不可用。

（2）QUIC的协定栈运行在用户态，同时因为协定的复杂度，对CPU的耗费会比TCP高不少，理论实现时如何尽可能的缩小QUIC对服务器性能的影响？

（3）UDP的报文长度受限于MTU，对于大块数据，QUIC在应用层切成大量的小包，收发会造成大量的零碎调用sendmsg/recvmsg，因而QUIC的网络吞吐相比TCP有很大劣势。Linux零碎提供了多种优化伎俩：1）反对批量发送函数sendmmsg，多个UDP报文，通过一次零碎调用实现发送；2)开启内核GRO/GSO，在网卡驱动实现拆包和组包；3）网卡反对硬件UDP GSO offload。

思考到以上问题之后，个别QUIC服务能够相似依照下图的架构设计。

减速链路

对以下两段链路应用QUIC减速：1）最初一公里：因受wifi设施性能、蜂窝网络信号覆盖范围强弱等因素影响，用户终端的最初一公里网络能力参差不齐，是比拟容易呈现弱网的一段链路。2）数据中心间级联：数据中心之间的数据个别会走骨干网，但在一些流量顶峰时段，可能会呈现网络拥塞，比拟容易呈现数据丢包，延时加剧。

双链路备份

客户端个别会同时反对TCP和QUIC两种传输通道，互为备份，依据两条链路的理论情况（RTT、丢包等）智能抉择最优传输通道。

连贯迁徙的实现

如前文所述，QUIC socket采纳UDP收发数据，一个连贯用一个ConnectionID惟一标识，无论用户在蜂窝网络与WLAN之间如何切换，只有数据包中的ConnectionID不变，服务端能够将不同的四元组关联到同一个连贯上下文，从而避免出现断网重连。然而实现无缝的连贯迁徙艰难并不小，为了实现高并发，服务端个别都会采纳多线程，多过程的架构，负载平衡依据四元组将连贯ConnectionID关联到特定的运行环境（线程或过程），连贯迁徙大概率会导致缓存的连贯上下文生效。以下图多线程的设计举例，构想CID1连贯迁徙产生时，用户源IP和端口由A变成C，socket绑定的线程由1迁徙到2，因线程2查找不到CID1连贯的上下文，导致连贯迁徙失败。

上图只是多线程的架构，咱们能够想方法把新的socket从新bind回线程1。如果是多过程架构，负载平衡会寻址到不同的服务器上，如何将连贯从新寻址到原始服务器？业内个别的解决思路借鉴了雪花算法，在建连实现就给Server的destination ConnectionId打上初始服务器的地址标记，依据这些标记信息（集群ID+机器ID+线程ID），让新的服务器寻址到初始的服务器，后续数据再通明转发给初始服务器，整个过程仅减少了一次转发动作，对用户没有任何感知。

PART 04 传输时延测试

建连时延

上图能够看到建连有将近50%的晋升，QUIC节俭了2-RTT工夫，对于一些RTT高网络，成果更显著。

丢包时延

为了比照TCP和QUIC在丢包网络下的体现，别离对5%、15%、30%的丢包率场景做了比照测试。每一种场景，进行1000次测试，每次测试发送10KB数据，统计最终落在指定时延以下的概率。最终的后果参考下图，横坐标示意时延，纵坐标用百分比示意指定时延下的样本数量，曲线收敛速度越快，落在较低时延范畴的样本数量越多，所以时延体现越好。

5%丢包下，200ms内传输实现的测试样本，QUIC占95%，TCP占78%，QUIC比TCP晋升了17%左右。

15%丢包下，200ms内传输实现的测试样本，QUIC占90%，TCP占50%，QUIC比TCP晋升了90%左右。

30%丢包下，200ms内传输实现的测试样本，QUIC占62%，TCP占22%，QUIC比TCP晋升了300%左右。

总结起来，QUIC相比TCP的弱网丢包下的延时晋升比拟比拟显著，丢包率越高，晋升越显著。

PART 05 总结

本文对QUIC实际中遇到的次要问题和相应解决思路做了一些分享，理论我的项目利用时，因为需要的多样性、现有服务架构的差别，须要就地取材，将QUIC的一些好的个性以比拟优雅地姿态利用。

关注拍乐云Pano，理解更多音视频相干技术、产品实际！