QUIC协议使用观察

文/Geoff Huston (APNIC首席科学家)

快速UDP互联网连接（QUIC）是一种网络协议，最初由谷歌公司开发和部署，最近（2021年5月）在互联网工程任务组（IETF）中被标准化（标准文档RFC 9000）。

QUIC并不是一个最近才被提出的协议，它是由谷歌在2012年开发，并在2013年8月发布的第29版Chromium浏览器中包含了最初的公开版本。QUIC的诞生初衷是试图完善互联网协议（IP）中传输控制协议（TCP）的基本操作，并非想从根本上改变流控制程序和流管理，而是通过改变传输功能在终端主机内的实现位置，从而改变该功能的变更控制者。

互联网协议中的TCP协议已经被实现为操作系统的底层功能。应用程序通过接口与TCP交互，实现I/O（输入/输出）操作的基本开/关和读/写功能。数据流完整性和流控制的细节也在很大程度上对应用程序是隐藏透明的。这些内容当然使得应用的操作变得更简单，但这种简单性也伴随着其自身的问题。

TCP有它自身的问题，在基于网络（Web）的服务方面尤其如此。如今，大多数网页都不是简单的单体对象。它们通常包含许多独立的组件，包括图像、脚本、自定义框架、样式表等等。其中每一个组件都是独立的对象。如果使用配备了原始HTTP实现的浏览器，即使它们是从同一个IP地址获取资源，每个对象也都将在一个新的TCP会话中被加载。为复合型网络资源中每个不同的网络对象建立一个新的TCP会话和一个新的传输层安全（TLS）会话的开销可能会变得非常大，而复用已经建立的TLS会话从同一服务器上多次获取资源则变得十分有吸引力。

但是这种在单个TCP会话中复用若干数据流的方法也有其问题。在单个会话中复用多个逻辑数据流会在流处理器之间产生不必要的相互依赖，并可能导致线头阻塞的情况，即当前活动流的传输停滞会阻塞同一TCP会话中其他所有排队获取的流。因此结论是，如果我们想通过在协议中引进并行行为来提高这种复合型连接的效率，那么我们就需要现有TCP以外的实现方式。

当然，这听起来比实际情况要简单得多。一些类别的应用程序和服务的开发者希望看到TCP行为的改变，但实现这些变化取决于操作系统平台的维护者。这种成本和收益的转移往往会导致一种僵局，即对于那些需要进行这种改变的人来说，改变的动机是不充分的。通过允许应用程序直接控制其自身希望的传输服务行为方式，可以获得更直接的结果。

这就是用户数据报协议（UDP）发挥作用的地方。UDP是一个狭窄的“垫片”协议，使得应用程序可以直接控制IP层的基本数据报行为。一个应用程序可以实现自己的端到端传输协议，并加载该传输协议的控制结构及其有效载荷，并将两者进行组合作为UDP有效载荷。在这一点上，应用程序对传输协议有完全的控制权，可以按照自己的意愿定制传输协议的行为，而无需等待任何第三方。

QUIC的简要概述

QUIC是一种端到端传输协议，基于UDP数据报流实现，如图1所示。

图1 TCP和QUIC在HTTP架构中的比较

QUIC采用了TCP的流完整性和流控制功能的组合，将其与TLS的会话加密功能相结合，实现了更灵活的多流处理版本，还增加了对地址敏捷性的更好支持，以容忍各种各样的网络地址转换（NAT）行为。

QUIC连接标识符

为了方便地穿透NAT，QUIC实现了连接标识符（connection IDs）。每个端点都会生成连接标识符，使得收到的带有该连接标识符的数据包被路由到使用该连接标识符的进程。在QUIC版本协商期间，这些连接标识符被交换，此后每个发送的QUIC数据包都包含远端当前使用的连接标识符。

这种连接到端点的身份（连接标识符）与QUIC使用的IP地址和端口号之间的语义区分形式类似于主机身份协议（HIP）。QUIC的固定端点标识符允许会话在端点IP地址和端口的变化中持续存活。如果一个传入的QUIC数据包使用相同的连接标识符，即使源IP地址和UDP端口号可能已经改变，也可以被识别为现有流的一部分。

QUIC对多数据流的支持

一个QUIC会话可以支持多个流配置。双向流将客户端和服务器事务放入一个匹配的上下文中，例如HTTP/1的传统请求/响应事务就需要这样。客户端将被期望与服务器打开一个双向流，然后在流中发出一个请求，同时从服务器产生一个匹配的响应。服务器有可能向客户端发起一个双向的推送流，其中包含一个没有初始请求的响应。控制信息是使用单向控制流传输的，其中一方可以在有需要的情况下向另一方传递信息。用于支持控制流的底层单向流接口也向应用程序公开。

QUIC不仅可以支持许多不同的流配置，而且可以在一个端到端的QUIC会话中支持不同的流配置。当然，这不是一个新的概念，HTTP/2协议就是一个很好的例子。它是一个应用层协议，增加了多路复用和流框架，以便在一个单一的传输数据流中携带多个数据流。然而，HTTP/2使用的单一TCP传输流可能会遇到线头阻塞的问题，即所有叠加数据流在单一TCP会话中“命运共享”。如果其中一个数据流传输停滞，那么所有的叠加数据流都可能受到影响，也可能停滞。

QUIC提供一种略微不同的复用方法，其中每个叠加数据流可以使用自己的端到端流量状态，一个叠加流的暂停并不意味着任何其他同步流受到影响。

在HTTP/2中，在相同的两个端点之间复用多个数据流的部分原因是为了减少为每个TCP会话设置TLS安全关联的开销。当单个数据流各自发送一个小对象时，这可能是一个主要问题，而且有可能遇到这样的情况：复合型网络对象获取的TCP和TLS握手部分占据了大部分的总下载时间和数据量。

QUIC将安全关联作为利用UDP数据流实现的端到端状态，由于它们基本上重复使用已建立的安全会话状态，因此可以以非常轻量级的方式启动单个数据流。

QUIC 加密

从以上对于TLS的提及可以看出，QUIC使用了端到端加密。这种加密是在UDP有效载荷上进行的，因此一旦TLS握手完成，随后的QUIC数据包交换中只有很少的内容是明文的，如图2所示。

图2 TCP和TLS与QUIC的比较

QUIC中暴露的是公共标志（public flags）。QUIC数据包的这一初始部分由连接标识符组成，允许接收方将数据包与端点关联起来，而无需解密整个数据包。QUIC版本（version）也是公共标志的一部分。这在最初的QUIC会话建立中使用，此后可以被省略。

QUIC数据包的其余部分是私有标志（private flags）和有效载荷（payload）。这些数据都是加密的，不能被窃听者直接看到原始数据。私有标志包括数据包的序列号（sequence number），这个字段用于检测重复和丢失的数据包。它还包括所有流量的控制参数，包括窗口广告（window advertisements）。

以上是TCP和QUIC之间的关键区别之一。在TCP中，协议的控制部分是明确的，因此链路中的网络设备能够检查端口地址并推断应用类型，以及检查连接的流状态。即使只分析一部分TCP连接中单向流动的数据包，网络设备也能推断出相关的传输往返时间（round-trip time）和数据传输率。而且，类似NAT，操纵ACK（确认字符）流中的接收窗口（receive window）将允许网络设备对连接进行流量控制，并以一种双方都无法感知到的方式降低传输速率。将所有这些控制信息放在QUIC数据包的加密部分，可以确保没有中间网络设备直接看到这些信息，也没有网络设备对连接流进行操控。

大家可以认为：QUIC执行的是20世纪80年代假设的一个观点。这就是，端到端传输协议不与网络共享。网络“看到”的都是无状态的数据报，而终端可以安全地认为端到端传输控制字段中包含的信息是以保护其不受第三方审查和改变的方式在网络上进行传输的。

QUIC和IP分片

简短的回答是不！QUIC数据包是不能被分片的。实现这一目标的方法是让QUIC HELLO数据包被填充到最大数据包尺寸。如果最大尺寸的数据包被分片，那么最初的HELLO交换则无法完成。允许的最大数据包尺寸至少是1200字节。如果端点通过某种路径MTU发现程序确认了设置的可行性，则允许端点使用更大尺寸的最大数据包。

用于测量QUIC使用的配置

现在让我们转向测量QUIC和HTTP/3在现今互联网中使用情况的任务。为了实现这一点，我们已经使用了APNIC实验室的测量平台，其中的测量任务被嵌入到在线广告的脚本中。该广告脚本引导用户执行一些URL获取操作，并对提供参考对象的服务器进行探测，以便从服务器的响应推断出客户端的能力和行为。

在这种情况下，客户端被指示加载一个基本的URL对象（一个最小的1×1像素的“斑点”），其中URL的域名部分对每个单独的测量是唯一的。为了建立一个QUIC测量，我们采取了以下步骤。

使用了支持QUIC的nginx服务器v1.12.7。

使用了一个具有HTTPS RR类型DNS记录的URL域名，其值为alpn="h3"。

在内容上使用了一个替代服务指示，即Alt-Svc: h3=":443"，其目的是引导客户端使用HTTP/3进行后续资源获取。

通常情况下，最后一个步骤即替代服务（Alt-Svc）指示，基本上是无效的。每个客户端都是作为一个单一的事件来接收广告的，脚本指示每个广告加载一次，所以客户端不应该对URL进行第二次加载。在这种情况下，我们对脚本进行了修改，指示客户端等待两秒，然后重复加载这个URL。假设这种延迟的重复足以让客户端对Alt-Svc指令采取行动。

在这个实验中，我们有五分之一的时间执行这种重复的URL获取。

QUIC测量

QUIC测量开始于2022年6月初。在这个测量中，我们同时测量了查询HTTPS记录的用户数量和使用HTTP/3（QUIC）访问URL的用户数量。该测量结果显示在图3中。

图3 2022年6月的QUIC测量结果

有趣的是，查询HTTPS DNS类型的用户数量在10%～15%之间，而使用HTTP/3进行资源获取的用户数量则低得多，只有1.5%的用户。如果客户端浏览器支持HTTP/3，而且也被配置为查询这种DNS记录类型，那么为什么使用HTTP/3的后续访问会更低？我们以后再来讨论这个问题。

查看每个经济体使用HTTP/3用于资源获取的分布情况也很有意思，如图4所示。

图4 每个经济体的QUIC使用情况

在丹麦、瑞典、挪威和瑞士，QUIC的使用率较高，而在亚洲、南美洲和非洲的大部分地区则较低。

哪些用户使用HTTP/3？

通过使用每次HTTP获取中提供的浏览器字符串，并将其与使用的协议（HTTP/2或HTTP/3）相匹配，我们可以获得一个关于哪些平台和浏览器使用HTTP/3进行对象获取的概况（见表1）。应该注意的是，浏览器字符串作为一个数据源并不完全可靠，存在误差，但其提供了一个相对可接受的结果，即哪些浏览器和哪些平台正在使用HTTP/3进行资源获取。

表1 系统平台使用HTTP/3的分布情况

为了比较，表1还提供了没有使用QUIC的系统平台分布。很明显，这里的主要变化是较多的苹果iOS设备（iPhone和iPad）使用了HTTP/3。

浏览器对于HTTP/3的使用分布情况见表2。

表2 浏览器使用HTTP/3的分布情况

同样，表2中与QUIC是否启用存在主要差异是Safari浏览器，这与表1中的iOS平台表现一致。

在这个阶段，似乎在今天的互联网中观察到的对于HTTP/3和QUIC的使用，有接近一半是由iOS平台和Safari浏览器贡献的。

QUIC数据包尺寸

正如标准文档RFC 9000所指出的：“UDP数据报不得在IP层被分割”。其还强调：“客户端必须确保包含初始数据包的UDP数据报的UDP有效载荷至少为1200字节，必要时可以增加PADDING（填充）帧”。这意味着QUIC的实施必须将最大数据包的尺寸限制在一个保守的数值，以避免路径分片的发生。

对这些限制的一种处理方式是使用某种形式的路径MTU发现程序并使用发现的最大数据包的尺寸。另一种方法是选择一个数据包的尺寸，确保不会存在被分片的情况。

为了回答目前QUIC使用的最大数据包尺寸的问题，我们观察了每个QUIC会话并记录了最大数据包尺寸。图5展示了观察到的数据包尺寸的分布。

图5 QUIC最大数据包尺寸的分布

最常见的会话数据包尺寸是1200字节（46%的会话）。其次最常见的尺寸是1250字节（18.5%的会话）和1252字节（16.4%的会话）。没有一个会话的数据包尺寸超过1357字节。

QUIC连接的可靠性

互联网上的每个新协议都有一个与现有中间件（网络中的中间设备）有关的潜在问题。许多数据包过滤器在可接受协议和端口的指定范围内运行，使用UDP 443端口的加密有效载荷也不例外。因此，了解互联网中QUIC协议的健壮程度是合乎情理的。

如果我们能够可靠地检测QUIC连接的两端，就可以查看从客户端发送至服务器的初始QUIC数据包的可靠性，以及从服务器发送回来的响应QUIC数据包的可靠性。不幸的是，我们不能控制客户端，所以只能分析第二种可靠性，即从服务器发回客户端的响应数据包，以及是否有从客户端收到的后续数据包。

表3展示了这些QUIC响应数据包在24小时内的测量结果。在这里，我们是在服务器上对连接进行观测的。如果我们看到了初始连接数据包，但没有后续的数据包，表明QUIC连接失败。鉴于我们无法观测到初始QUIC数据包的发送是否存在失败的情况，因此观察到的失败率是一个下限。

表3 QUIC连接失败率

触发QUIC连接

如前所述，有两种机制允许服务器向客户端发出信号，表明它能够使用QUIC支持HTTP/3会话。简而言之，这些机制是：

在内容头中包含一个Alt-Svc指示，即Alt-Svc: h3=":443"。

一个包含有HTTPS RR类型DNS记录的URL域名，其值为alpn="h3"。

客户端使用的是哪一种？

测量方法是服务指示只在第二次获取时使用，而基于DNS的方式可以在第一次使用时建立。在这个实验中，我们使用了两个不同的测试。对于执行测量脚本的五分之一（22%）的客户端来说，其执行了两次资源获取，间隔时间为两秒，其中第二次仅通过在URL获取的参数中添加一个额外的字段来区分。其余的客户端则执行一次获取。这两次获取允许服务器通知客户端，在第一次获取时通过Alt-Svc头表明支持HTTP/3，然后在第二次获取时使用HTTP/3。

表4对比了使用这两个触发过程的HTTP/3获取率。如果客户端在第一次获取中不使用HTTP/3，但在第二次获取中使用HTTP/3，我们认为它使用了Alt-Svc机制。如果客户端在单个获取场景中使用HTTP/3，我们假定它使用了DNS HTTPS机制。

表4 QUIC连接触发率

很明显，Alt-Svc触发机制比基于DNS的机制的使用多四倍。造成这种差异的原因是在最近发布的iOS平台上Safari浏览器使用了基于DNS的机制，而Chrome浏览器则使用Alt-Svc指示。鉴于约有90%的观察到的客户端使用了Chrome浏览器，那么在整体客户端上的触发率也可以认为是5%。而在整个测量样本集中看到的1%的基于DNS机制的触发率源于20%～25%的Safari iOS客户端。

QUIC更快吗？

使用QUIC的动机之一是，建立QUIC会话的开销低于建立TCP会话和TLS会话的串行延迟。所以询问观察到的实践是否与这一理论相符是很有意义的。

我们将比较客户端使用HTTP/2加载一个对象（安全会话中的1×1像素gif）的测量时间和同一客户端使用HTTP/3加载同一对象的测量时间。在客户端的时间测量中存在许多变量，包括与浏览器内部任务调度有关的变量，但这些单独的因素应该在足够大的样本集上被抵消。

图6显示了距离中心点+/-500ms的时间差的计数。累积分布显示，QUIC在2/3的样本中更快（如图7所示）。

图6 资源获取时间差异的比较：QUIC与非QUIC

小结

很明显，HTTP/3和QUIC正在今天的互联网中形成一些明显的部署趋势，这主要是由于苹果的Safari在最近发布的iOS和MacOS中产生的影响。

QUIC对于IP数据包分片进行了保守的规定，最大的数据包尺寸被控制在1200～1360个八位字节范围内。

尽管苹果客户端正在使用DNS HTTPS机制，由于Chrome浏览器在互联网上的广泛使用，QUIC的主要触发机制仍然是Alt-Svc指示。

重要的是，HTTP/3和QUIC通常比TCP和TLS快。

我们将继续开展这一实验，在未来几个月内跟踪QUIC的部署情况。