编者按

　　2022年7月，APNIC首席科学家杰夫·休斯顿（Geoff Huston）撰文介绍了APNIC对互联网中QUIC（Quick UDP Internet Connections，快速UDP互联网连接）使用情况的测量工作。杰夫·休斯顿表示：“确保测量的‘正确性’是一项有趣的工作，也是我想分享的学习经验。”本文将从《QUIC协议使用观察》一文的结尾开始，继续讨论QUIC的使用情况。

杰夫·休斯顿 APNIC首席科学家

QUIC的使用率太低

　　我们使用了APNIC实验室的测量平台，该平台将测量过程嵌入到在线广告的脚本中。这些脚本会在用户客户端渲染广告的过程中请求一系列URL，然后通过检查服务器的响应来推断客户端的能力和行为（例如，是否支持QUIC）。

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

　　1.使用支持QUIC的Nginx服务器（v1.23.1版本）；

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

　　3.在HTTP响应内容中配置一条替代服务指令（Alternative Service），即Alt-Svc:h3=":443"，其目的是引导客户端使用HTTP/3进行后续资源获取。

　　通常，最后一个步骤替代服务指令（Alt-Svc）基本上是无效的。每个客户端都将接收一条广告作为一个独立事件，且脚本指示每个广告加载一次，所以客户端不应该对URL进行二次加载。对此，我们调整了测试脚本，让客户端等待两秒后再重复加载这个URL。我们认为，这种被延迟的重复加载足以让客户端执行替代服务指令。

　　我们对QUIC的测量始于2022年6月初，在这项工作中，我们同时测量了查询HTTPS记录的用户数和使用HTTP/3（QUIC）访问URL的用户数。图1比较了使用这两种方式请求HTTP/3的比例分布：

图1 在第一次和第二次请求中使用QUIC的分布情况

　　1.如果客户端在第一次请求时没有使用HTTP/3，而在第二次开始使用HTTP/3，我们就认为它使用了替代服务指令Alt-Svc触发机制；

　　2.如果客户端在第一次请求时就使用了HTTP/3，那么我们就认为它使用了DNS HTTPS触发机制。

　　这里存在的问题是，第二次请求QUIC（QUIC Second Fetch）的比例实在过低（3%~4%）。谷歌曾宣布，Chrome浏览器在2020年10月会增加对QUIC的支持，通过使用Alt-Svc指令来触发QUIC。Cloudflare的观测报告显示，30%的HTTP请求使用了QUIC。尽管我们不清楚该报告中的比例指的是流量数还是会话数，但无论是哪种情况，30%的QUIC使用量都比3%~4%要多。

　　是什么地方出了问题？

增加重复请求次数

　　我们的第一个想法是，在第一次请求两秒后就进行第二次请求还不够。在允许的情况下，Nginx服务器倾向于与客户端保持会话，以降低TLS（传输层安全）会话建立的成本，而HTTP/2支持这种会话重用。因此，也许重复请求一次是不够的。

　　于是我们把重复请求次数从一次增加到七次，共八次请求，每两次请求的调度间隔保持在两秒。这一调整改善了情况，将第二次资源获取使用HTTP/3的比例从4%提高到26%，如图2所示。

图2 将重复请求的次数从1提升到7

　　此时的测量结果有了明显改善，但仍然低于Cloudflare的数据。大约有一半的Chrome浏览器在重复请求过程中仍然没有切换到HTTP/3。

调整服务器端keepalive计时器

　　HTTP持久连接（HTTP persistent connection）有助于降低TCP连接（以及HTTPS的TLS连接）的开销。在一次请求结束后，服务器会在关闭会话前维持连接若干秒（keepalive过期时间）。这提高了服务器对客户端的响应效率，但同时也有一些额外的代价，比如需要消耗额外的内存来保持会话开放状态。

　　在我们的分析中，对于使用替代服务指令切换到HTTP/3的客户端来说，我们并不希望服务器维持HTTP/2连接。因此，我们需要寻找能够关闭初始HTTP/2会话的服务器，然后让客户端在后续的请求中开启新的使用QUIC和HTTP/3的会话，而不是在七次重复请求中看到很多间歇性行为。

　　我们尝试将Nginx服务器的keepalive时间设置为零秒，但这产生了意想不到的副作用，即禁用了服务器中的所有QUIC支持。显然，这不是预期的结果！

　　随后，我们将keepalive时间提高到1秒，因为非零值可以确保QUIC支持功能可用。图3显示了这种配置对QUIC会话数的影响。

图3 修改服务器端keepalive时间

　　显然，对于替代服务指令触发的类似Chrome浏览器的行为，实验达到了预期的效果。在后续的周期性测量中，我们发现所有测试中QUIC的使用比例都提高到了50%以上。

　　值得注意的是，在支持QUIC的测试样本中，有略高于一半的样本在第二次请求时切换到了QUIC，其余的在第三次或以后的请求中切换。而在大约10%的请求序列中，客户端转而使用基于TCP的TLS。此外，keeplive定时器设置为1秒有一个副作用，它会禁止在第一次请求时使用QUIC（即通过DNS HTTPS资源记录触发QUIC的使用，这种方法主要在Safari浏览器中实现）。

　　看来，通过查询DNSHTTPS记录触发QUIC的浏览器面临的问题是，QUIC连接在建立之前就被关闭了。

　　IETF的QUIC标准（RFC9000）在第10.1节提到空闲超时（Idle Timeout）的概念。服务器的keepalive计时器值可能会被下层的QUIC传输使用，QUIC代码会在HTTP上下文建立之前提前关闭QUIC会话。

进一步调整服务器端keepalive计时器

　　为了测试这个理论，我们将服务器的keepalive参数从1秒上调到20秒。测试脚本依然执行间隔为2秒的七次重复请求，服务端keepalive超时时间设置为20秒。为了加快通过DNS触发QUIC的过程，我们在HTTPS记录中除了设置alpn="h3"之外，还增加ipv4hint和ipv6hint参数，以避免客户端进行额外的DNS查询。这里假设客户端代码会用这些参数（ipv4hint和ipv6hint）来代替进一步的显式DNS查询。

　　这些调整解决了QUIC使用率低的问题，如图4所示。

图4 将服务器端keepalive值改为20秒

　　假设客户端使用DNS HTTPS查询，较长的keepalive时间允许初始请求使用QUIC。因此我们再次看到，全球平均有1.9%的测试样本在首次请求中使用QUIC，而这个比例在部分经济体中高于6%。很难说能否通过进一步调整“keepalive计时器”和“测量脚本的探测次数”而得到更高的比例。

　　首先，我们无法获得QUIC的失败尝试数据，从客户端到443端口的UDP（用户数据报协议）数据包会被丢弃。其次，本地防火墙的激进过滤规则对其他服务（如使用6to4的IPv6-in-IPv4隧道）的鲁棒性产生了相当明显的影响，而且我们无法直接观察QUIC数据包的出站行为（outbound behaviour）。所以，这种方法的鲁棒性很难衡量。

　　无论在何种情况下，在全网有超过50%的部署率都是一项显著的成就。全球QUIC支持率的分布地图展示了几乎所有经济体对QUIC的支持水平，唯一一个支持率低于20%的主要经济体是中国，如图5所示。

图5 每个经济体的QUIC使用率（2022年8月）

观察发现

　　如果服务器支持通过QUIC传输数据，那么客户端会使用QUIC吗？

　　答案似乎是“会的”。大多数浏览器客户端会在服务器支持QUIC时使用它，但对于这种积极的回应，有一些警告事项。考虑到大多数浏览器客户端使用Chrome，而Chrome浏览器仍然使用替代服务指令实现到HTTP/3的切换，这意味着服务器配置和响应内容（如HTTP header）都需要开启QUIC支持。它还要求响应内容的构造能够依次满足多次请求。正如我们所发现的那样，这可能需要对keepalive参数进行仔细的调整，以允许客户端使用QUIC来进行后续请求。

　　从这个角度看，使用DNS HTTPS记录触发QUIC的方法似乎更可行，它可以确保QUIC更快建立连接、零往返时间（0-RTT）的会话重建、更好的多会话支持，以及从客户端和服务器第一次通信开始就使用端到端加密（默认加密策略）。

　　然而，随着互联网的持续增长，部署方式变更的速度会变得越来越缓慢。在这种情况下，变化不仅体现在客户端浏览器集合（相对小的集合）的行为上，也体现在一众服务器中（考虑到集中性，这也不是一个特别大的集合）。

　　虽然QUIC在为用户提供更快、更安全的体验方面有明显的优势，但它的缺点也取决于对DNS的各种配置系统进行修改的成本，以及协调DNS发布（配置）能力和服务端能力的成本。但是，这也未必会成为QUIC广泛部署的阻碍。

　　对Tranco域名列表的扫描（2022年8月31日）结果显示，该列表排名前25万的域名中，约有12.5%的域名有HTTPS记录。这些HTTPS记录大多具有类似的格式，包括指向Cloudflare服务器地址的hint字段。这并不表明域名服务器中普遍配置了HTTPS记录，而是因为一个被广泛使用的内容分发网络（CDN）平台实现了这种支持。

　　在Cloudflare的案例中，服务托管于Cloudflare的域名，其域名权威服务器也是由Cloudflare提供和维护的，因此增加HTTPS记录相对简单。鉴于人们普遍希望加快HTTP内容传输，其他内容传输平台（包括各种CDN）很可能在不久的将来支持QUIC。

　　为了让浏览器更普遍支持QUIC，下一步的进展可能依赖于Chrome浏览器的代码发布时间，以实现通过DNS HTTPS记录作为触发器，在初始请求时启用QUIC。

　　来源：APNIC
　　作者：杰夫·休斯顿
　　翻译：张明明（清华大学）
　　责编：项阳