QUIC和互联网传输的未来

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

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

影音探索 #011#——QUIC

当上世纪 70 年代 TCP 被发明的时候，我想没有人会预料到 50 年之后我们仍然在使用它。但事实是，我们现在还在使用 TCP。

在过去几十年中，TCP 不断发展，并新增了与可靠数据传输、流量控制、拥塞控制等相关的各种特性。但许多研究者以及包括我在内的从业者都认为 TCP 已至末路。自从 TCP 发明以来，互联网已经成为社会生活中非常重要的组成部分，但遗憾的是，TCP 并没有与时俱进以满足不断增长的需求。

不过鼓舞人心的消息是，在代替 TCP 方面，有一位最重要的 “候选人”—— 它能够使互联网传输继续发展，并解决许多困扰互联网多年的问题。具体来说，这个有可能替代 TCP 的协议被人们称为 QUIC，人们对 QUIC 的出现激动不已。但这种激动是否合理，我们将在今后的文章说明。本文我们将来了解发明 QUIC 的原因以及 QUIC 的使用人群。

什么是 QUIC?

QUIC 是一种通用、安全、多路复用的传输层新型网络协议。它的目的是替代 TCP（目前是互联网上用于数据传输的主流协议）。2012 年，QUIC 协议由当时还在谷歌任职的 Jim Roskind 开发。2013 年，QUIC 正式对外公布。

2015 年，QUIC 被提交给 IETF 进行标准化，但是直到六年以后，也就是 2021 年 5 月，IETF 才发布了第一版标准化的 QUIC，被命名为 RFC 9000。同时，IETF 还发布使用了 QUIC 的 HTTP/3 标准化版本。

QUIC 吸纳了很多与 TCP 类似的属性，还有 TLS 加密，将它们置于 UDP 传输之上的应用层中。

为什么需要 QUIC？

虽然 TCP 已经 “英勇地” 服务多年，但它很可能已经走到了尽头。它最初设计用于有线互联网，根本没有想到今天的无线互联网会发展到如此容量和规模。许多专家很清楚，它无法适应今日互联网的发展。而 QUIC 的出现可以使网络更快、更高效、更安全，而最重要的是，可以不断发展。

在 QUIC 出现以前，TCP 的主要替代选择是 UDP。简而言之，TCP 提供了可靠的互联网传输，其中可以确保数据的传输，而 UDP 提供了更快、但却非可靠的传输。QUIC 的目的就是结合 TCP 的最佳特性和 UDP 传输层。

TCP 的主要限制包括：

TCP 仅定义了 40 字节的可选位，且几乎全部填满。结果就是，没有新特性的位置了。

许多中间件（如防火墙）假设 TCP 数据包将以某种确定方式构造。如果数据包与它们的预期相差太大，就会被拒绝或者延迟，这使得 TCP 协议几乎无法发展。

由于 TCP 在内核里实现，那么任何 TCP 传输的更新都需要经过新的内核修改。对于一些基础设施相对陈旧的公司来说，需要耗费数年才能采用新的特性。

TCP 是传输层，没有内置加密（即 TLS），所以它需要在上层增加。导致的结果就是需要很长时间才能建立安全连接，并且一些通过 TCP 传输的数据（比如数据包头部）没有被加密，从而产生安全漏洞。

QUIC 和 HTTP/3 一起使用的目的就是代替 HTTP/1（或 2）和 TCP 的组合，以及解决 TCP 协议所带来的一些已知问题。

QUIC 如何解决 TCP 所带来的挑战？

首先，在 UDP 之上构建 QUIC 这一务实的决定所带来的优势相当明显。UDP 在互联网上被广泛部署，所以无需从零开始定义传输层（如从零开始，可能要耗费几十年）。

相较于 TCP，UDP 的开销要少很多，这个特点使它更快速、更简单也更高效。但它存在一个重大缺陷，那就是缺乏可靠性。UDP 无法确保每个通过它发送的数据包传输，也无法确保数据包以准确顺序发送给接收方。

QUIC 继承了 TCP 的特性，将它们构建于 UDP 之上，并添加了更多其他特性。TCP 是传输层，TLS 和 HTTP2 位于其上方的应用层，QUIC 同时包含了应用层和传输层机制。因此，它的目的就是代替 TCP 传输层。

QUIC 使用 UDP 作为底层传输协议，同时内置 TLS 加密，并结合了 TCP 的可靠性相关特性。QUIC 在应用层（即用户空间）获得进一步实现。因此，无需更新内核，你就可以进行大量修改。

谁在使用 QUIC？

作为一种通用传输协议，QUIC 可以用于许多基于互联网的工作流，但部署的第一步就是将网页浏览转移到 QUIC，因为它所带来的最直接的好处就是基于 HTTPS 的 Web 浏览。

作为 TCP 的继任者，QUIC 只能与 HTTP/3 一起使用。为了使用该协议，客户端和网站都需要支持它，但因为只有少数网站使用 HTTP/3，所以这也成为了 QUIC 协议被广泛采用道路上的一个阻碍。根据 W3Tech [1]，截止 2021 年 10 月 2 日，约 35% 的网站仍然在使用 HTTP/1；约 45% 的网站迁移到了 HTTP/2，而只有大约 20% 的网站正在使用 HTTP/3 和 QUIC。

截止 2021 年中旬，QUIC 占据了互联网流量的 12%。谷歌是第一家（也是最有名的）采用 QUIC 协议的公司（毫不意外，毕竟 QUIC 协议是由谷歌员工开发的）。在其生态中，谷歌拥有自己的服务器、应用程序、服务和客户端，所以它很容易实现 QUIC，并将众多应用迁移到新的框架。30% 的 YouTube 流量已经转移到了 QUIC。

接着是 Facebook（现更名为 Meta），它已经将 70% 的流量迁移到了 QUIC。Facebook 和 Instagram 移动应用程序都已经在最大限度地使用 QUIC。

这就是 QUIC 协议采用所面临的现状。微软只有少量流量使用了 QUIC；在流媒体领域，只有 YouTube 和 Facebook Live 支持了 QUIC。流媒体视频接近 80% 的 Web 流量，大部分依然使用的是 TCP。流媒体巨头公司 Netflix 和 Amazon Prime 都没有支持 QUIC。不过，微软有将其 VPN 产品从 TCP 迁移到 QUIC 的倾向 [2]。

目前支持 QUIC 的生态包括：

浏览器： Chrome（默认）、Edge、Firefox、Safari 和其他默认使用 TCP 的浏览器（但将 QUIC 作为可选选项）。

应用：所有来自谷歌的应用，如 Gmail 和 YouTube；Facebook 的应用；Uber。

服务器 / CDN： Akamai、微软、Apple、谷歌、Cloudflare、Fastly、Caddy 和 NetApp。其中一些 CDN 已经验证了 QUIC 的实现，但几乎它们所有的流量都还在使用 TCP。

Web 服务器： LiteSpeed、H20、Ngnix 和 Apache。

负载均衡器： LiteSpeed 和 F5 BIG-IP。

技术社区项目：基于 chromium 实现的 libquic、反向代理（充当反向代理服务器的 Docker 镜像）。

编程语言： Go（quic-go）、Quic.NET（C#）。

如你所见，基于 Web 的基础设施已经开始向 QUIC 迁移，但是在大多数情况下，QUIC 还不是默认选项，而且一些大公司依然没有支持 QUIC。

为什么这么久才推出 QUIC？

QUIC 依然是一个新标准，它的目的是重新设计互联网的诸多方面。而对如此众多的特性进行标准化需要时间。虽然 QUIC 在 2013 年首次提交给 IETF，但直到 2021 年 5 月才正式推出，所以它仍然没有获得不同生态的完全支持。

QUIC 首次公布与正式标准化之间相隔时间太久，这使得很多厂商开始开发自己的协议版本。他们在获取到最初发布的 QUIC 后，将自己的版本构建在其上。但是他们所使用的协议不同于最终及官方版本。因此，QUIC 有很多不同的版本，其中一些并不支持官方版本的必备特性，且不同的厂商需要时间将自己的版本调整为与 2021 官方版本保持一致。我们可以看到，这种过渡还处在早期阶段，比如实现了自己的 gQUIC 版本的谷歌正在迁移到 IETF 发布的 QUIC 版本。

也就是说，更加广泛的 QUIC 采用依然要面临许多挑战，包括企业安全规定对 QUIC 的接受度、支持 TCP 回退的请求以及规范依然相当基础这一事实。我将在后续文章中更加详细地说明其中一些挑战。

QUIC 拥有互联网传输的潜力

TCP 是为过去的互联网时代所设计的协议，它无法适用于今日的互联网，而 QUIC 的目的是解决 TCP 的许多问题，使互联网变得更安全、更灵敏并且可以不断发展。需要谨记的是，我们现在仍处在 QUIC 协议部署的早期阶段，接下来的几年我们将见证它是否能够完成成为 TCP 继任者的使命。QUIC 的潜力不仅仅是成为 TCP 的替代方案，它在实时协议上的一些标准化举措有可能使其代替在视频会议和云游戏中使用的实时通信协议（如 WebRTC）。

注释：

[1]https://w3techs.com/technologies/details/ce-http3

[2]https://techcommunity.microsoft.com/t5/storage-at-microsoft/smb-over-quic-is-now-in-public-preview/ba-p/2482964

致谢：

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

原文链接：

https://www.compiralabs.com/post/quic-and-the-future-of-internet-transport/

----------------------------------------------

历时五年，HTTP/3 终于标准化了！

昨日，IETF QUIC 和 HTTP 工作组成员 Robin Mark 在推特上宣布，历时 5 年，HTTP/3 终于被标准化为 RFC 9114！详情参见：

https://www.rfc-editor.org/rfc/rfc9114.html