LiveVideoStack

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

QUIC

LiveVideoStack 2022年6月9日

翻译：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优势。