QUIC会成为互联网传输的颠覆者吗？

翻译：Alex

技术审校：刘连响

本文来自 Compira Labs，作者为 Ravid Hadar。

▲扫描图中二维码了解音视频技术大会更多信息▲

 

影音探索 #012#

当计算机科学家注意到 TCP 的限制性使它无法继续支持新的、更加先进的互联网服务时，他们对 QUIC 的兴趣便与日俱增。作为传输协议，QUIC 是替代 TCP 的最重要 “候选人”，它将有可能为互联网数据传输打开新的局面。

在昨天的文章中，我们讨论了什么是 QUIC、它的目的以及工作原理。现在我们要回答一个稍许不同的问题：它真的值得采用吗？接下来，本文将深入探索使用 QUIC 的优势和劣势。

QUIC 的优势

QUIC 的支持者指出它可以使互联网更高效、快速、安全且不断发展。

1∕可扩展性

更改 TCP 并不容易，因为其中的中间件抗拒更新，而且 TCP 40 字节的可选位几乎全部填满（更多相关信息，请阅读 QUIC 和互联网传输的未来）。

TCP 没有任何版本协商（version negotiation）扩展位，相比之下，QUIC 有 32 位，所以它有很多空间部署新版本，厂商也可以利用这些空间定义自己的专属版本。

2∕用户空间实现

QUIC 能够在应用层实现，与在操作系统内核中实现的 TCP 相比，它可以更快地进行更新。这进一步提高了 QUIC 的可扩展性，使得服务可以非常快速地演进，从而新的特性每天都能得到部署。同时它还能在上下文切换时通过调用较少的开销而实现更高的响应能力。

3∕更快建立连接

Web 浏览特别需要快速建立连接，因为用户通常会开启多个、短暂的连接。当使用 HTTPS 时，TCP 在建立连接前，需要 “三次握手” 以及后续的 TLS 协议设置。

QUIC（基于 UDP）不需要三次握手，加上它会在初次握手时交换安全密钥，从而使它在建立加密连接时速度提升了一倍。

4∕降低对丢包的敏感度

使用 TCP 时，如果丢失一个数据包，接下来所有的数据包都会停止传输，直到丢失的那个数据包被发送，这种现象被称为 “队头阻塞”，它会导致延迟明显增加。

相比之下，QUIC 使用的是类似 HTTP/2 的多路复用模式，可以同时支持多个数据流。如果一个数据流发送错误，导致丢包，那么其他数据流会继续发送数据包，而不会阻塞传输。

下图的示例中显示了包含三个数据包的拥塞窗口的连接，其中 0 号数据包被丢弃。在只有单一数据流的 TCP 连接中，后续的数据包被阻止。QUIC 的多路连接拥有三个数据流，每个都能独立操作。因此，2 号和 3 号数据流仍然在正常传输，只有 1 号数据流中后续的数据包被阻止。

5∕切换网络时的性能提升

切换网络时，QUIC 可以实现平稳过渡。比如，如果你使用家里的 wifi 观看手机上的视频，然后你走出家门，家里的 wifi 便切换到 LTE，或者当你一直忙于观看视频，在不同的移动基站间移动时。

在以上这些场景中，TCP 将切断连接，并通过新的网络创建新的连接，进而影响到你的观看体验。而 QUIC 则能够实现无缝连接。

6∕提升的安全性和隐私保护

QUIC 在传输层中内置了加密功能，从而验证整个负载（包括 header）。TCP 在 header 中不包含加密，使它非常容易受到攻击。QUIC 默认支持安全的 TLS，意味着端到端完全安全。

QUIC 的局限性

TCP 发明时，网络都是有线连接，而且相当可靠。但显然，情况已经发生改变。QUIC 对非可靠、无法预测的无线连接进行了改进，但并没有改变互联网传输的本质，它的局限性导致它只能改变某些特定使用场景。下面列举了一些额外的 QUIC 局限性：

1∕迁移 app 面临巨大挑战

将 app 从 HTTP/2 迁移到 HTTP/3（或者从 TCP 迁移到 UDP）要费很大力气。整个过程需要将整个应用层实现和传输层实现转移到 UDP，并在服务端和客户端构建全新的解决方案。

这对于流媒体领域中资源相对有限的小厂商而言无疑挑战重重，同时也解释了谷歌和微软这样的科技巨头可以率先采用 QUIC 协议的原因。

2∕采用受限

QUIC 的最大问题就是它的采用依然受限。几乎每个浏览器都接受使用 QUIC 进行简单的网页浏览，但是除了 chromium，没有浏览器将它设置为默认选项。

除此之外，在流媒体领域，除了谷歌和 Facebook（现更名为 Meta）之外，少有公司使用 QUIC。只有少数 CDN 提供商支持 QUIC，而其中的一些也只是验证了 QUIC 的实现，并没有为大规模部署准备好。这就带来了问题：如果你推出了使用 multi-CDN 并基于 QUIC 的新服务，那么将只有 20% 的访问使用 QUIC，因为你无法向用户证明它对用户体验的显著影响。

3∕QUIC 包含 TCP 回退

QUIC 之所以被构建在 UDP 之上，部分原因是极少有中间件和网络设备拦截 UDP。但确实存在被拦截的风险，所以基于 QUIC 的 app 必须设计成能够回退到 TCP，以防万一。

这意味着 app（基于 QUIC）的开发者要同时开发和维护两个不同的版本（由于 TCP 回退和受到限制的采用率），导致他们的负担很重。

好消息是，随着最新的 DEVOPS 结构与 HTTP 的 Alt-Svc 标签的使用，支持两种协议要比以前简单得多。

4∕无法检查数据包

网络防火墙无法解密 QUIC 流量来检查数据包，所以潜在的恶意流量非常有可能没有被标准安全功能检测出来而进入网络。因此，思科和 Palo Alto Networks 等安全厂商通常会在端口 80（Web 服务器）和 443（TSL）拦截 QUIC 数据包（认为它们包含恶意软件），迫使客户端回退使用 HTTP/2 和 TCP 协议。

但上述操作并不会显著影响内容用户体验，因为正确实现的流媒体服务会默认回退到 TCP+TLS，但这种操作可能会阻止率先部署 QUIC 的想法。只有解决这一挑战，QUIC 才能被各大企业广泛接受。

5∕不具备某些 TCP 特性

人们理所当然地使用 TCP 中所默认包含的一些特性（比如 Throttling）。但使用 QUIC，你可能需要自己构建这些特性。

除此之外，HTTP/3 缺乏一些采用某些特定协议时所需的特性。比如，HTTP/3 仍然不支持成块传输（chunked transfer，即将视频切片分割为小块的能力），但 HTTP1.1 却支持该特性。这就限制了用于基于 QUIC 的视频传输的协议数量。

因此，尽管 QUIC 支持大部分常见传输协议（如 HLS、MPEG-DASH），但目前它无法支持更多新的协议，这些协议主要用于降低 glass-to-glass 延迟，比如依赖于成块传输的 LL CMAF（Low Latency Common Media Format）。

glass-to-glass 延迟： 指显示器屏幕和相机镜片之间的延迟，也可以叫做 “端到端延迟”，意思是开始（ 捕获）并结束（显示）之间整个传输管道上的延迟 [1]。

6∕更容易被 fingerprinting

恶意行为者很可能嗅探到互联网用户与所访问网站之间的网络流量，并通过被发现的数据包创建与特定网站相对应的不同模式，这种操作被称为 web fingerprinting。在早期流量连接阶段，TCP+HTTPS 似乎更能抵御 fingerprinting。

7∕QUIC 可能需要更高的 CPU 使用率

一些观点认为 QUIC 所需的 HTTP/3 在客户端和服务端都占用了更多的 CPU 资源。然而，谷歌却持相反观点，认为 QUIC 有助于延长电池寿命。

无论如何，一旦 QUIC 进入主流技术栈，这一问题预计不会有太大影响。

8∕需要实现的协议众多

由于 IETF 历经 5 年多才发布第一版 QUIC，所以目前市面上有 60 种 QUIC 版本实现，都开发于 QUIC 标准之前。因此，大部分 QUIC 版本或不支持完整的 QUIC 标准，或只支持自己版本的实现。只有当不同版本的 QUIC 与官方标准保持一致时，它才能被广泛采用。

9∕互联网依然针对 TCP 进行优化

TCP 传输已经存在几十年，多年以来，TCP 应用通过在软件（如操作系统内核）和硬件（如网络接口和智能 NIC）中构建卸载性能而彻底得到了优化。而 QUIC 却不具备这一能力。它基于 UDP，位于用户空间内，所以它的端点，以及一些中间件功能在现阶段存在明显的劣势。不过，一旦 QUIC 被广泛采用，就会得到这种优化，所以这对于 QUIC 而言只是暂时性问题。

QUIC vs TCP：对于质量体验的影响

QUIC 支持某些独特的特性并在新的特性实现方面提供了更多灵活性。因此，对比 TCP，基于 QUIC 的应用有望在 QoE 方面带来更多优势。

下面是两个 QUIC 带来 QoE 优势的常见用例：

Web 浏览： QUIC 支持内置 TLS，并能够迅速建立连接。在大部分连接时长较短的情况下（如安全网站的快速下载时长），它可以提供明显的性能优势。谷歌声称运行在 QUIC 上的应用页面下载时长缩短了 10%。

视频流： QUIC 支持的某些特性有望提升视频流的 QoE。目前为止，因为 QUIC 的实现逻辑与 TCP 相似，所以可预测的影响已受到限制。但在一些情况中，还是可以体验到 QUIC 所带来的好处，比如，QUIC 减少队头阻塞的能力为具有中高丢包率的网络所带来的 QoE 优势。

QUIC 也许是 “改进者”，不是 “颠覆者”

QUIC 确实为互联网用户带来了渐进式的增益，但对于它是否是真正的 “颠覆者” 这一观点还存在争议。目前存在充分的理由采用 QUIC，但 QUIC 所带来的问题以及早期采用者所遇到的挑战都在 “鼓励” 一种观望态度。

注释：

[1]https://cloud.tencent.com/developer/article/1346159

致谢：

本文已获得作者 Ravid Hadar 授权翻译和发布，特此感谢。

原文链接：

https://www.compiralabs.com/post/quic-is-it-the-game-changer-for-internet-delivery