什么是QUIC？
准备好迎接 HTTP/3——HTTP 协议最新和最伟大版本的互联网新时代。随着 HTTP3 的出现，网站所有者和互联网用户现在可以期待拥有比以往更快、更可靠和更安全的在线体验。这一切都归功于革命性的新传输协议，即 QUIC（快速 UDP 互联网连接）。
2021 年 5 月， IETF在RFC 9000中对 QUIC 进行了标准化，开始支持RFC 8999 、RFC 9001和 RFC 9002的支持。然后在 2022 年 6 月 7 日，IETF 在 RFC 9114中正式发布了基于 QUIC 的 HTTP/3 作为建议标准。
目前，QUIC 的部署正在全球范围内加速推进。随着QUIC IETF-v1协议标准的出现，越来越多的网站开始使用QUIC流量。据W3Techs统计，目前约有25.5%的网站使用HTTP/3。
CDNetworks作为网络领域的先行者，率先完成了对QUIC协议的全面支持。下表显示了 CDNetworks 支持的当前 QUIC 版本。
它是如何工作的？
从一个方面来说，QUIC = HTTP/2 + TLS + UDP，而UDP + QUIC = 传输层。
QUIC 采用 UDP 作为其传输协议，与 TCP 相比具有更低的延迟和更高的吞吐量，并且它还使 QUIC 能够绕过可能干扰 TCP 的网络中间件。 QUIC 包含基于 TLS 1.3 的内置加密协议，可在端点之间提供安全通信，并使第三方更难拦截和操纵互联网流量。从 SMB 等协议中加入一些命令和版本控制，然后混合一组新的协议概念和效率，这就是 QUIC 的用武之地——结合了 UDP 的速度和效率、TLS 的安全性，以及HTTP/2，为现代互联网创建可靠和高性能的传输协议。
为什么 QUIC 很重要？
在 QUIC 发布之前，HTTP 中使用 TCP 作为传输数据的底层协议。然而，随着移动互联网的不断发展，人们对实时交互和更多样化的网络场景的需求越来越大。此外，智能手机和便携式设备越来越成为主流，目前有超过 60% 的互联网流量通过无线传输。
然而，传统的TCP这种已经使用了40多年的传输层通信协议，在目前大规模远距离、移动网络差、网络切换频繁的背景下，存在先天的性能瓶颈，无法满足需求主要源于以下三个原因：
建立连接时握手延迟大
无论是HTTP1.0/1.1还是HTTPS、HTTP2，都是使用TCP进行传输。 HTTPS 和 HTTP2 也需要使用 TLS 协议进行安全传输。这导致两次握手延迟：
TCP 三次握手导致建立 TCP 连接的延迟。
完整的 TLS 握手至少需要 2 个 RTT 才能建立，而简化的握手需要 1 个 RTT 握手延迟。
对于很多短连接场景，这种握手延迟影响很大，无法消除。
队头阻塞
以 HTTP/2 多路复用为例，多个数据请求在同一个 TCP 连接上作为不同的流发送，应用层的所有流都必须按顺序处理。如果一个流的数据丢失，后面的其他流的数据将被阻塞，直到丢失的数据被重传，即使接收端已经收到后续流的数据包，也不会通知应用层。此问题称为 TCP 流的队头阻塞 (HoL)。
推动 TCP 协议更新并非易事
TCP 协议最初设计用于支持端口、选项和功能的添加和修改。然而，由于 TCP 协议的悠久历史以及众所周知的端口和选项，许多中间件（例如防火墙和路由器）已经变得依赖于这些隐式规则。因此，这些中间件可能无法正确支持对协议的任何更改，这可能会导致互操作性问题。
TCP协议在操作系统内核中实现，但由于Windows XP等许多老系统平台仍有大量用户，用户端操作系统版本升级非常困难。此外，TCP 用户对它的功能很满意，并且可能会抵制可能影响其行为的更改。所以，要快速推动TCP协议的更新并不是那么容易的。
为什么我们需要 QUIC？
QUIC的出现解决了最后一公里的网络传输问题。以下是 QUIC 的主要改进：
快速握手和连接建立
QUIC在两个方面进行了优化：
- 传输层使用UDP，减少了TCP三次握手中一个1-RTT的延迟。
- 采用最新版本的 TLS 协议，TLS 1.3，允许客户端在 TLS 握手完成之前发送应用数据，同时支持 1-RTT 和 0-RTT。使用 QUIC 协议，第一次握手协商需要 1-RTT，但之前连接的客户端可以使用缓存信息恢复 TLS 连接，只需 0-1 RTT。
经过身份验证和加密的数据包
传统的TCP协议头没有加密和认证，容易被中间人篡改、注入和窃听。相比之下，QUIC 数据包为安全性配备了重装。除了 PUBLIC_RESET 和 CHLO 等少数消息外，所有数据包头都经过身份验证，所有消息体都经过加密。这样QUIC报文的任何修改都能被接收端及时发现，有效降低安全风险。
如下图，紫色部分为Stream Frame包的认证头，黄色部分为加密后的内容：
改进多路复用以避免 HoL 阻塞
QUIC 引入了在连接上复用多个流的概念。 QUIC 通过为每个流设计和实现单独的流量控制，解决了影响整个连接的队头阻塞问题。
QUIC 的多路复用与 HTTP/2 类似。单个 QUIC 连接上可以同时发送多个 HTTP 请求（流）。但是，QUIC 的多路复用优于 HTTP/2 的地方在于，单个连接上的各个流之间没有顺序依赖关系。这意味着，如果流 2 丢失了一个 UDP 数据包，它只会影响流 2 的处理，而不会阻塞 数据传输 对于流1和3。因此，该解决方案不会导致队头阻塞。
此外，作为 QUIC 的一项新功能，HPACK 标头压缩格式的变体 QPACK 旨在减少通过网络传输的冗余数据量，从而有助于缓解 Head-of-Line Blocking。这样QUIC在弱网场景下可以接收到比TCP更多的数据。
可插拔拥塞控制
QUIC支持可插拔的Cubic、BBR、Reno等拥塞控制算法，也可以根据具体场景定制私有算法。 “可插拔”意味着它可以灵活地生效、更改和停止。体现在以下几个方面：
- 不同的拥塞控制算法可以在应用层实现，不需要操作系统或内核的支持，而传统的TCP拥塞控制需要端到端的网络协议栈才能达到控制效果。
- 允许单个应用程序的不同连接支持不同的拥塞控制配置。
- 应用程序无需停机或升级即可更改拥塞控制。我们唯一要做的就是修改配置并在服务器端重新加载它。
连接迁移
TCP 连接基于 4 元组：源 IP、源端口、目标 IP 和目标端口。如果其中任何一个发生变化，则必须重新建立连接。但是QUIC连接是基于一个64位的Connection ID，只要Connection ID不变就可以保持连接，不会断线重连。
例如，如果客户端使用IP1发送数据包1和2，然后切换网络，更改为IP2并发送数据包3和4，服务器可以根据数据包中的Connection ID字段识别所有四个数据包来自同一个客户端标头。 QUIC能够实现连接迁移的根本原因是底层UDP协议是无连接的。
前向纠错 (FEC)
QUIC还支持前向纠错（Forward Error Correction，FEC），通过动态添加FEC包，可以在较差的网络环境下减少重传次数，提高传输效率。
HTTP/3和QUIC将在更多领域展现其价值
随着 HTTP/3 和 QUIC 继续受到关注并得到更广泛的采用，无论是直播和视频流、视频点播、下载还是网络加速，我们都可以期待看到广泛的用例出现。这些技术的一些最有前途的应用场景包括：
实时应用
HTTP/3 和 QUIC 非常适合需要低延迟、高吞吐量连接的实时应用程序。这包括视频会议、在线游戏和实时流媒体等应用程序。基于QUIC更强的抗不良网络能力和连接迁移能力，可以有效改善视频启动时间，降低视频卡顿率和请求失败率。
物联网
物联网场景下，终端设备使用场景复杂、混乱，如高速移动、海上、山区等环境，设备可用的网络资源非常有限。基于 TCP 的消息队列遥测传输 (MQTT) 物联网通信协议经常会在重连过程中出现频繁的连接中断和较大的服务器/客户端开销。而QUIC的0RTT重连/1RTT建立能力和复用特性的优势在恶劣和不稳定的网络中得到体现，可以提高内容传输效率，提升用户体验。
云计算
随着越来越多的应用程序和服务迁移到云端，需要在客户端和服务器之间建立更高效、更可靠的连接。凭借处理多路复用流、低延迟握手和零往返时间恢复的能力，QUIC 可以增强基于云的计算系统的性能。
电子商务与金融支付
在电子商务中，QUIC 提高的可靠性和速度有助于确保客户即使在流量高峰期也能获得无缝顺畅的购物体验。 QUIC 提供必要的性能和安全功能来支持电子商务应用程序，例如快速页面加载时间和安全支付交易。
随着技术的不断发展和成熟，我们可以期待看到更加多样化和创新的用例出现，从而推动新应用程序和服务的开发。
CDNetworks 全平台支持 HTTP/3 和 QUIC
CDNetworks 预见了 QUIC 协议的功能潜力，并率先开发了它。为了迎接HTTP/3的新时代，CDNetworks在五年前就在平台上实现了对QUIC协议的支持，并在HTTP/3标准正式发布后顺应市场需求，对整个平台进行了基于QUIC的升级。原始 QUIC 完全支持所有版本的 gQUIC (Google QUIC) 和 iQUIC (IETF QUIC)。
在内部，CDNetworks 提高了平台的帧处理能力并优化了性能以降低机器消耗。根据我们的一份内部测试数据，在1Mbps码率的QUIC拉流场景下，新平台在相同业务并发条件下可提升带宽性能41%，平均CPU消耗降低28%。
针对直播场景，CDNetworks进行高强度质量优化，提升QUIC协议的重传效率和速率采样计算能力，优化UDP包传输和GSO（Generic Segmentation Offload）策略，有效解决视频流质量不稳定的问题在跨区域网络环境差的情况下。根据我们对使用 QUIC 和 TCP 协议的视频播放进行比较的直播拉取场景的测试结果之一，您可以看到以下数据：
[码率]
在无丢包环境下，QUIC和TCP码率相近，但在20%丢包情况下，QUIC码率保持一致，而TCP下降明显。
[视频流畅度]
就平滑度而言，如果在每个小时周期内为播放器重新填充缓冲区，则测试样本被视为卡顿。在非丢包环境下，由于QUIC对应用层封装额外进行了加密操作，所以流畅度略低于TCP。但是，在丢包情况下，QUIC 明显优于 TCP。
[TTFB]
在TTFB（Time to First Byte），即测试机发起播放请求到接收到第一个视频包的时间间隔方面，QUIC在20%丢包下保持一致的首包投递时间条件，而 TCP 增加了显着的延迟。
