头图

IETF访谈: HTTP/3全球份额持续增长,QUIC前景一片光明

LiveVideoStack
本篇文章为IETF近期对Lucas Pardue 关于QUIC标准化工作的访谈。作者为IETF Blog 记者Grant Gross。

文 / Grant Gross

译 / Alex

技术review:刘连响

原文链接 / https://www.ietf.org/blog/qui...

Lucas Pardue 来自伦敦,IETF QUIC工作组联合主席,同时也是CloudFlare(一家美国网络基础设施和网站安全公司)的高级软件工程师。


IETF Blog:QUIC工作组是做什么的?它是什么时候成立的?

Pardue: QUIC工作组汇聚了你能想到的各类人才,包括研究人员、从业人员、工程师、开发者、政策制定者、基础设施运营商、服务提供商等。从2016年开始,我们一直在进行QUIC 第一个版本的标准化工作,包括传输行为、丢包检测、恢复、拥塞控制、安全问题等,并与HTTP工作组一起,致力于适用于QUIC协议的HTTP。

很多人可能知道,关于QUIC 的工作早在 2016 年之前就开始了。我们以此为起点,并写下章程,该章程帮助我们创建了一套包含工作组和IETF社区共识的文档。随着RFC的发布,工作组完成了QUIC第一个版本的标准化工作,随后又踏上了新的征程。现在我们的工作重点是协议的维护和演进,并不断产生可以用到QUIC丰富扩展性功能的新想法。我们的未来一片光明。


IETF Blog:QUIC 如何提高使用它的服务的性能、隐私和安全特性?

Pardue:默认情况下,QUIC传输协议是安全的,这意味着它能为所有服务提供包括完整性、真实性和机密性在内的强大特性。今天使用TCP协议的服务(无论有没有TLS)都应该将QUIC作为可以直接代替TCP的协议。工作组目前正在研究的Unreliable Datagram extension(非可靠数据报扩展)将在未来代替DTLS或者其他此类协议。与TCP不同,QUIC关键在于保护数据包元数据,很少有信息暴露给被动观测者,且中间无人能操纵序列号和选项。这为传统的流量管理方式带来了挑战,但同时也解决了一个大问题——僵化。

当第三方在不与你协调的情况下修改你的流量时,他们会对协议和协议遍历的系统做出假设。当第一方(端点)想要改进或试验时,就有可能跟这些假设产生冲突。极端情况下,它会使扩展变得毫无意义,甚至破坏协议。安全的QUIC 可以防止这种不协调的串改,并为我们提供了一个可以不断前行的优质平台。现在,多亏了0-RRT,QUIC 可以实现快速握手,并且许多实现都拥有了智能拥塞控制。未来,QUIC的基础性能只会变得越来越好。 

在性能方面,避免队头阻塞是QUIC的杀手锏(通过流的多路复用实现),我会在后面的回答中进一步说明。该性能不像QUIC 的其他特性那样可以直接替换,需要使用 QUIC 的应用程序在与独立流交互时保持智能。


IETF Blog:QUIC 的部署范围有多广?它是如何广泛部署的?

Pardue: 由于 QUIC 工作组一直致力于制定规范,我们已经看到了许多客户端和服务端代码的实现。其中一部分已经工作于生产环境中,如 Web 浏览器和面向公众的服务。2019 年 9 月,Cloudflare 向所有人公开提供 QUIC 和 HTTP/3 支持。我们非常高兴看到人们开启QUIC并使用 Chrome、Firefox 和 Safari 等浏览器的Dev/Canary/Nightly Channel进行测试。随着规范接近成熟,看到客户端支持开始进入稳定Channel并在默认情况下开启,这是非常令人高兴的。 

终端用户应开始受益于 QUIC 所提升的安全性和性能,而无需采取任何手动操作。根据 Cloudflare Radar 的数据,2021 年 1 月中旬,HTTP的全球份额约为:HTTP/1.1 占 24%,HTTP/2 占75%,HTTP/3 不到 1%。到 2 月中旬,HTTP/3 的使用率增长到略高于 5.5%,HTTP/2 下降到 69%,HTTP/3 的增长取代了 HTTP/2 的使用。到 5 月中旬,HTTP/3 占 HTTP 流量份额的 12%。

当越来越多的浏览器和网站使用QUIC, 我们预计这一增长趋势会持续下去。


IETF Blog:为什么流的多路复用和加密传输协议如此重要?

Pardue: 我已经在上面第二个问题中解释了防止串改是如何起作用的,所以这里不再重复。但我们不要忘记,私人通信就应该是私密的。加密传输是提高用户安全性和隐私的基础——它为应用开发者提供了额外的安全保障,如 Web源模型、同源策略和限制 Web API 以保护上下文。QUIC 的多路复用可以缓解队头阻塞的现象。一旦发生队头阻塞,丢包会阻止其后面的所有内容。这可能会影响终端用户体验的方方面面。

如果某些关键网站脚本被不太紧急的数据所阻塞,你可能会被困在一个空白页面上。如果你丢失了视频流的一部分,就不能直接跳转到余下的视频流,而你可能最终会在缓冲或手动重新加载时观看旋转的图标,并希望恢复之前视频未丢失时的状态。QUIC 有缓解队头阻塞的方法,如果使用得当,可以提高体验质量,尤其是在处理常规网络问题方面。

TCP 中有一个逻辑字节流,其中发送的数据需要保证按顺序接收。TCP 流被分成多个segment,以便使用 IP 在网络上传输,由于不能确保网络的可靠性,可能会造成丢包或者segment的重新排序。TCP 的工作就是处理此类事件并按预期呈现数据流。这通常很有效,但有时队头阻塞会使情况变得糟糕。想象一下,你在不同的数据包中发送了序列 A、B、C、D、E,而第三个丢失了。接收器获得序列 A、B、D、E,它无法向应用程序展现这四个值,只能展现第一个连续范围 A、B。

QUIC协议可以解决这个问题。每个流是独立的,由一个 62 位的整型数值标识,就像它自己的 mini-TCP,都在一个共同的保护机制下传输。发送者可以选择将 A、B、C、D、E 拆分为不同的流,并且发送者可以按任何顺序读取它们。

如果包含其中一个值的数据包丢失,没关系,你只需在它到达时读取所有内容!然而,挑战是按照发送的顺序回读序列。流 ID的作用就在这里,但实际发生的方式由应用程序映射(如 HTTP/3)描述。解决队头阻塞是可能的,但调整它以获得最佳体验质量将是下一个机会。 


IETF Blog: QUIC下一步有什么计划?

Pardue: 我对 QUIC 的下一阶段十分期待。随着人们部署QUIC版本1,我们将学习并确认潜在的改进。QUIC 的版本控制和可扩展性丰富且稳健。我们更新了工作组章程,以不断拓宽工作范围,同时也会采纳一些新想法,如更加智能的重传。我们正在考虑使用qlog这样的模块来实现更丰富的标准化端点日志记录。就个人而言,我非常高兴看到QUIC 所实现的应用层可能性。IETF 已经在 QUIC 基础上成立了MASQUE和WebTransport工作组。未来一片光明。

IETF: The Internet Engineering Task Force,互联网工程任务组,成立于1985年底,是全球互联网最具权威的技术标准化组织,主要任务是负责互联网相关技术规范的研发和制定,当前绝大多数国际互联网技术标准出自IETF。

阅读 62
138 声望
26 粉丝
0 条评论
你知道吗?

138 声望
26 粉丝
宣传栏