资讯首页 新闻资讯 云计算测评 云服务商动态 技术频道
上云无忧 > 云计算资讯  > 新闻资讯 > 从TCP到QUIC:革命尚未成功,同志仍需努力

从TCP到QUIC:革命尚未成功,同志仍需努力

发布时间: 2023-01-27 14:21:27 |浏览量:382| 评论: 0

TCP诞生于1970年代,当时可能没有人能够预料到,几十年后的今天TCP还在被我们使用,并且仍是作为主流协议。
 
几十年来,TCP 增加了与可靠数据传输、流量控制、拥塞控制等有关的各种功能,但许多研究人员和从业者认为 TCP 可能已经快走到了尽头。自TCP诞生以来,互联网已成为社会的重要组成部分,但不幸的是,TCP未能跟上不断增长的需求。
 
好消息是,有一个候选协议——QUIC,可以取代TCP。QUIC协议可以使互联网传输继续发展,并解决困扰互联网的许多问题。
 
什么是 QUIC?

QUIC 是一种新的通用、安全、多路复用传输层网络协议。它的目标是成为 TCP 的继承者。QUIC 协议由当时谷歌的员工 Jim Roskind 于 2012 年开发,并于 2013 年公开宣布。
 
2015年,QUIC被提交给互联网工程任务组(IETF)进行标准化,但直到2021年5月,IETF才发布了QUIC的第一个标准化版本,即RFC 9000。同时,使用 QUIC 的 HTTP/3 的标准化版本也发布了。
 
QUIC 集成了许多类似 TCP 的属性以及 TLS 加密,并在UDP传输之上的应用空间中对它们进行分层。

为什么需要 QUIC?

TCP 已经服务了互联网几十年,但它可能即将走到它的尽头。TCP是专为有线互联网而设计的,其规模和范围与今天的无线网络完全不同,导致它无法跟上。QUIC 的目标是让网络更快、更高效、更安全,最重要的是,它是可进化的。
 
在 QUIC 出现之前,TCP 的主要替代方案是 UDP。简而言之,TCP 提供可靠的互联网传输,其中数据的传输是有保证的,而 UDP 提供了更快但不可靠的传输。QUIC 旨在将 TCP 的最佳特性与 UDP 传输层结合起来。
 
TCP 的主要限制包括:

TCP 只定义了 40 个字节的可选位,而且几乎被填满了,几乎没有空间来开发新功能。

许多中间件(如防火墙)都假定 TCP 数据包将以某种特定的方式结构化。如果数据包与他们的预期差异太大,它将被拒绝或延迟,这使得协议几乎不可能发展。

TCP 是在内核上实现的,因此对 TCP 传输的任何更新都需要经过新的内核修订。对于一些传统基础设施的公司来说,可能需要数年时间才能采用新功能。

因为TCP是传输层,加密(即TLS)不是内置的,所以必须在上面添加。这样导致的结果是建立安全连接需要很长时间,并且一些通过 TCP 发送的数据(例如数据包头)没有加密,从而导致安全漏洞。

我们的目标是让 QUIC 和 HTTP/3 一起使用,以取代 HTTP/1 或 HTTP/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 的优势

可扩展性

目前很难对 TCP 进行任何更改,并且 TCP 的 40 字节可选位几乎已完全被填满。TCP 没有任何版本协商字段位,而在合约中 QUIC 有 32 位。这为快速部署新版本以及供应商定义自己的专有版本提供了充足的空间。
 
可在用户空间实现

QUIC 可以在应用程序空间中实现,从而可以比在操作系统内核中实现的 TCP 更快地推出修改。这进一步增强了 QUIC 的可扩展性,允许快速的服务演进,甚至允许每天部署新功能。它还通过在上下文切换时涉及更少的开销来促进更高的响应能力。
 
更快的连接

Web 浏览需要快速建立连接。使用 HTTPS 时,TCP 连接需要“3 次握手”,然后在建立连接之前设置 TLS 协议。QUIC(基于 UDP)不需要 3 次握手,而且它在初始握手过程中交换了安全密钥,这使得建立加密连接的速度提高了一倍。
 
降低对丢包的敏感度

在 TCP 中,如果一个数据包被丢弃,所有后续的数据包都将被阻止,直到丢失的数据包被发送出去。这被称为“队头阻塞”,会显著增加延迟。
 
相比之下,QUIC 使用多路复用的 HTTP2 连接方案,它支持并发的多个数据流。如果一个数据流出现错误,导致丢包,其他数据流将继续发送数据包而不会中断传输。
 
下图是一个包含 3 个数据包的拥塞窗口的连接示例,其中数据包 0 被丢弃。在具有单个数据流的 TCP 连接中,后续数据包将被阻止。而QUIC 多路复用连接具有三个数据流,每个数据流独立运行。因此,数据流 2 和 3 仍在进行,只有数据流 1 的后续数据包被阻止。 
 
改进网络切换时的性能

QUIC 提供从一个网络到另一个网络的平滑过渡。例如,如果你在家使用wifi 在手机上观看视频,走出家门离开 wifi 范围后连接将会切换到 LTE。在这种类似的情况下,TCP 会终止连接,并使用新的网络创建一个新的连接,可能会影响观看体验,而 QUIC 可以实现无缝切换。
 
提高安全性和隐私性

QUIC 在传输层中内置了加密功能,可以验证整个有效负载,包括报头。TCP 在报头中不包含加密,容易受到攻击。因此,QUIC 默认支持安全的 TLS,这意味着完整的端到端安全性。
 
QUIC 的局限性

TCP 发明的时候还是有线连接,并且连接相当可靠,如今情况已然不同。QUIC 改善了不可靠、不可预测的无线链路,但它仍然没有改变互联网传输的本质。以下是 QUIC 的一些局限性:
 
迁移应用程序需要一定的努力

将应用程序从 HTTP/2 迁移到 HTTP/3,或从 TCP 迁移到 UDP 需要付出一定的努力。它需要将整个应用层实现和传输层实现转换到UDP,并在服务器端和客户端构建一个全新的解决方案。
 
对于资源有限的小型流媒体供应商来说,这是一个不小的挑战,这也解释了为什么率先采用该协议的是谷歌和微软这样的大型企业。
 
采用率有限

QUIC 的最大缺点是它的采用仍然有限。几乎每个 Web 浏览器都接受它来进行简单的 Web 浏览,但除了 Chromium 之外,没有一个将它定义为默认值。此外,在流媒体方面,除了谷歌和 Facebook 外,很少有人使用 QUIC,只有少数 CDN 供应商支持 QUIC。
 
开发者负担大

QUIC 建立在 UDP 上的部分原因是因为 UDP 被最少的中间盒和网络设备阻塞。但它仍然存在被阻止的风险,为了以防万一,基于 QUIC 的应用程序还必须设计成回退到 TCP。
 
这意味着基于 QUIC 的应用程序的开发人员要承担开发和维护两个不同版本的负担。好消息是,随着最新的 DEVOPS 结构和 HTTP 的 Alt-Svc 标签的使用,支持两种协议变得比以前简单得多。
 
无包检测

网络防火墙无法解密 QUIC 流量以检查数据包,因此潜在的恶意流量可能会在未被标准安全功能识别的情况下进入网络。因此,Cisco 和 Palo Alto Networks 等安全供应商通常会在端口 80(Web 服务器)和 443(TLS)上阻止 QUIC 数据包,假设它们可能包含恶意软件,迫使客户端退回到使用 HTTP/2 和 TCP 协议。
 
虽然这不会对内容消费者的体验有很大的影响,但它首先就违背了部署 QUIC 的目的。这一挑战需要得到解决,才能让QUIC在企业中得到广泛接受。
 
不包括一些 TCP 功能

有一些功能,例如节流,默认包含在 TCP 中。但是对于 QUIC,可能需要自己构建它们。
 
此外,HTTP3 缺少引入某些协议所需的功能。例如,HTTP3 规范仍然不支持分块传输,即将一个段分割成小块的能力,这是 HTTP1.1 支持的功能。这限制了可用于基于 QUIC 视频流的协议数量。
 
QUIC 可能需要更高的 CPU 使用率

有一些说法称,QUIC 所需的 HTTP3 在客户端和服务器端都使用了更多的 CPU 。然而,谷歌辩称,恰恰相反,QUIC 有助于延长电池寿命。无论哪种方式,一旦 QUIC 成为主流技术堆栈的一部分,这都不会成为一个重大问题。
 
多种协议实现

由于 QUIC 的第一个 IETF 版本的发布用了 5 年多的时间,目前市场上有 60 个 QUIC 版本实现,它们是在规范发布之前开发的。因此,他们中的大多数不支持完整的规范。只有在不同版本与已发布的 QUIC 规范保持一致后,QUIC 才能得到广泛采用。
 
互联网针对 TCP 进行优化

TCP 传输已经存在了几十年,多年来,通过在软件(如操作系统内核)和硬件(如网络接口和智能网卡)中构建卸载功能,TCP应用程序得到了彻底的优化。QUIC在现阶段具有明显的劣势。一旦QUIC被广泛采用,这种优化也有望在QUIC中实现,所以这只是暂时的劣势。
 
QUIC vs. TCP:对体验质量的影响

QUIC 支持一些独特的功能,并在新功能实现方面提供了更大的灵活性。因此,基于 QUIC 的应用程序有望提供优于 TCP 实现的 QoE 优势。
 
以下是 QUIC 有望带来 QoE 优势的两个常见用例:
 
Web 浏览 :QUIC 支持内置 TLS 并快速建立连接。在大多数连接时间较短的情况下可提供显着的性能优势,例如安全网站的下载时间更快。谷歌声称在 QUIC 上运行的应用程序的页面加载时间减少了 10%。
 
视频流:QUIC 支持某些有望改善视频流QoE的功能。到目前为止,预测的影响有限,因为它的实现逻辑与 TCP 类似,但在某些情况下 QUIC 的好处已经得到体现。例如,QUIC 能够减轻“队头阻塞”,可以为具有中高丢包率的网络提供 QoE 优势。
 
谁在使用 QUIC?

作为一种通用传输协议,QUIC 可用于许多基于互联网的工作流,但其部署的第一步是将网页浏览转移到 QUIC,因为它的一个直接好处是基于HTTPS的网页浏览。
 
由于 QUIC 作为 TCP 后继者的实现仅适用于 HTTP/3,因此客户端和网站主机都需要支持它才能使用该协议。这也是QUIC被广泛采用的障碍之一,因为只有少数网站使用 HTTP/3。根据W3Techs的数据,目前只有大约 20% 的人在使用 HTTP/3 和 QUIC。
 
截至 2021 年年中,QUIC 占互联网流量的 12%。第一个也是最著名的 QUIC 采用者是谷歌(这并不奇怪,因为它是由谷歌的员工开发的)。谷歌在自己的生态系统中拥有服务器、应用、服务和客户端,30% 的 Youtube 流量已经过渡到 QUIC。
 
Facebook 也已经将超过 75% 的流量迁移到了 QUIC。Facebook 和 Instagram 移动应用都已经在最大程度上使用 QUIC。
 
2021年为止支持 QUIC 的生态系统包括:
 
浏览器:Chrome(默认);Edge、Firefox、Safari 和其他浏览器默认使用 TCP,但可以选择 QUIC。
 
应用:谷歌旗下所有手机应用,如Gmail、YouTube等;Facebook的应用;Uber。
 
服务器/CDN:Akamai、Microsoft、Apple、Google、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 于 2013 年首次提交标准化,但直到 2021 年 5 月才发布,因此仍未得到不同生态系统的完全支持。 
 
QUIC 的首次发布与其正式标准化之间的巨大时间差导致不同的供应商开发了自己的协议版本。他们以 QUIC 为基础,并在此基础上建立了自己的版本,但他们的基础与最终的官方 QUIC 协议不同。这导致有很多 QUIC 版本流传开来,其中一些可能不支持正式发行版的全部功能,不同的供应商需要一段时间才能将他们的版本与2021年发行版保持一致。例如,谷歌开发了自己的风格 gQUIC,正在迁移到 IETF 发布的 QUIC 版本。
 
也就是说,QUIC 的广泛采用仍然面临许多挑战。

*本文系SDNLAB编译自CompiraLabs网站

更多【新闻资讯】相关文章

有话要说

全部评论

暂无评论
官方微信
联系客服
400-826-7010
7x24小时客服热线
分享
  • QQ好友
  • QQ空间
  • 微信
  • 微博
返回顶部