共计 3732 个字符，预计需要花费 10 分钟才能阅读完成。
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，理解更多音视频相干技术、产品实际！
