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

文 / Grant Gross

译 / Alex

技术review：刘连响

原文链接 / https://www.ietf.org/blog/quicwg-more-security-internet-traffic/

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。