翻译（机翻）apnic发布全球关于QUIC的使用统计调查报告

翻译（机翻）apnic发布全球关于QUIC的使用统计调查报告

几个月前，在2022年7月，我写了关于我们衡量互联网上QUIC使用水平的工作。让这个测量“正确”是一项有趣的练习，这是一次我想联系起来的学习经历。我们将从上一篇文章的结尾开始，然后从那里继续。

QUIC太少了！

我们使用APNIC实验室的测量平台，其中测量嵌入在线广告中的脚本中。广告脚本指示用户执行一些URL获取，并且为引用对象服务的服务器被仪器用于允许从服务器的操作中推断客户端的能力和行为。

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

• 使用包含QUIC支持的NGINX服务器v1.23.1。
• 使用具有定义的HTTPS资源记录（HTTPS RR）类型的URL域名，其值为alpn=“h3”。
• 对内容使用了替代服务指令，即Alt-Svc：h3=”:443”，旨在指导客户端使用HTTP/3进行后续检索。

通常，最后一项措施，即替代服务指令，在很大程度上是无效的。每个客户端都会将广告作为单个事件接收，脚本指示每个广告加载一次，因此客户端不应执行URL的第二次加载。在这种情况下，我们使用了脚本的变体，指示客户端等待两秒钟，然后重复此URL的加载。假设这种延迟的重复足以让客户根据替代服务指令采取行动。

QUIC测量于2022年6月初开始。在此测量中，我们测量查询HTTPS记录的用户数量和使用HTTP/3（QUIC）检索URL的用户数量。

图1比较了使用这两个触发进程的HTTP/3检索率。如果客户端在第一次检索中没有使用HTTP/3，但在第二次检索中更改为使用HTTP/3，我们假设它使用了Alt-Svc。如果客户端在初始检索中使用HTTP/3，那么我们假设它使用了DNS HTTPS机制。

图1-QUIC用于第一次和第二次获取。

问题是第二个获取率太低了。谷歌宣布，Chrome浏览器将于2020年10月增加对QUIC的支持，使用Alt-Svc指令触发QUIC。Cloudflare在其雷达报告中观察到30%的会话使用QUIC，尽管目前还不清楚该网站指的是流量还是会话计数。无论如何，30%使用QUIC的时间远高于3%至4%。

出了什么问题？

增加重复次数

我们的第一个想法是，第二次重复，安排在第一次获取后两秒钟，只是不够。如果可以的话，NGINX服务器更愿意保持与客户端的会话开放，以偿还TLS会话建立的成本，HTTP/2可以支持此会话重用。也许一次重复获取是不够的。

我们将重复获取的数量从1次增加到7次，总共进行了8次获取。获取之间的调度间隔保持在两秒。这一变化改善了画面，将第二次获取HTTP/3查询率从4%提高到26%（图2）。

图2-将后续获取次数从1提升到7。

结果是一个明显的改进，但它仍然低于Cloudflare测量值。我们看到大约一半的Chrome浏览器在重复间隔内仍然没有切换到HTTP/3。

调整服务器的保持计时器

HTTP中的持久连接有助于摊销在多个后续从同一客户端获取中建立TCP连接（和HTTPS的TLS连接）的开销。获取完成后，服务器将在关闭会话之前将连接再打开几秒钟（“kepalive”间隔）。这提高了服务器对客户端的响应能力，牺牲了服务器中一些额外的内存状态来保持会话打开。

在我们的案例中，这种服务器行为并不完全是我们希望使用替代服务指令切换到HTTP/3的客户端。我们正在寻找服务器关闭用于初始获取的HTTP/2会话，然后让浏览器客户端打开一个新的会话，希望每次都通过QUIC和HTTP/3进行第二次和后续获取，而不是我们在七个重复获取中看到的更间歇的行为。

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

然后，我们将保持时间器提高到一秒钟，前提是非零值将启用QUIC支持。这些行动对已看到的QUIC会话计数的结果如图3所示。

图3—改变服务器的保持时间值。

显然，对于由替代服务指令触发的类似Chrome的行为，这已经产生了预期的效果。在随后的获取周期中，QUIC的使用水平上升到测试的50%以上。

应该注意的是，略多于一半支持QUIC的样本在第二次获取时切换到使用QUIC，其余在第三次或之后的获取时切换到，在大约10%的获取序列中，客户端切换回使用TCP上的TLS。还指出，这个一秒计时器值具有在首次获取时禁用所有QUIC的副作用（由DNS HTTPS资源记录触发的使用，主要在Safari浏览器中看到）。

使用HTTPS记录的DNS查找的浏览器似乎遇到了QUIC连接在建立之前关闭的问题。

QUIC（RFC 9000）的IETF规范包括空闲超时（第10.1节）；底层QUIC传输也可能正在使用服务器的保持性计时器值，并且QUIC代码正在建立HTTP上下文之前提前结束QUIC会话。

进一步调整服务器的保持计时器

为了测试这一理论，我们将服务器的保持参数从1秒调整到20秒。

此时，测量脚本正在执行七次重复获取，每隔两秒安排一次。服务器的保持超时设置为20秒。此外，为了加快DNS触发路径，除了alpn=“h3”字段外，我们还在HTTPS记录中添加了ipv4hint和ipv6hint字段，允许客户端绕过额外的DNS查询，假设客户端代码将接受这些字段来代替进一步的显式DNS查询。

这些变化似乎解决了我们在低QUIC计数下一直面临的主要问题（图4）。

图4—将服务器的保持时间值更改为20秒。

较长的保持值允许初始获取使用QUIC，假设客户端是使用DNS HTTPS查找的客户端，因此我们再次看到使用QUIC作为全球平均值的样本的首次获取值为1.9%，而一些经济体在首次获取时使用QUIC高于6%。通过进一步探索保持计时器和测量脚本中后续获取的调度，很难判断这个速率是否可以推到更高的值。我们无法访问的数据是QUIC连接尝试失败的数据，其中从客户端到服务器的出站路径会丢弃发送到端口443的UDP数据包。过于热情的本地防火墙过滤规则对其他服务的健壮性产生了相当显著的影响（例如使用6to4的IPv6-in-IPv4隧道），我们无法直接查看QUIC数据包的出站行为，因此这种方法的稳健性具有挑战性。

无论如何，整个互联网的部署率超过50%绝非易事。QUIC支持的世界地图显示了几乎所有经济体对QUIC的支持水平。唯一一个QUIC支持水平低于20%的主要经济体是中国（图5）。

图5——每个经济体的QUIC使用情况，2022年8月。

观察

如果服务器支持通过QUIC交付内容，那么客户端会使用QUIC吗？

答案似乎是“是”，因为大多数浏览器客户端在提供QUIC时都会使用，但对这种积极回应有一些警告。鉴于大多数浏览器客户端使用Chrome，而Chrome仍然使用替代服务指令切换到HTTP/3进行后续获取，这意味着服务器和内容都需要启用QUIC使用。它还要求构建内容，以便能够按顺序使用多个获取。正如我们所发现的，这可能需要仔细调整kepalive参数，以允许客户端切换到使用QUIC进行后续获取。

在这方面，DNS HTTPS记录方法作为QUIC的触发机制看起来更可取，允许QUIC属性更快的连接建立、零往返时间（0-RTT）会话重建、卓越的多会话支持以及从客户端和服务器首次接触点使用的端到端传输参数的完全加密。

然而，随着其持续增长，在互联网上部署变革正变得越来越缓慢。在这种情况下，变化不仅在于客户端浏览器集的行为（这不是一个大集合），也在于服务器的集合（同样，考虑到中心性压力，这不是一个特别大的集合）。虽然QUIC在为用户提供更快、更安全的体验方面有一些明显的优势，但缺点似乎是更改DNS的各种配置系统以及将DNS发布的功能与服务器端功能协调的成本。但这可能不像看起来那样成为广泛采用的障碍。

在对Trarico域名列表（2022年8月31日）的扫描中，在该列表中排名前25万个域名中，其中约12.5%拥有HTTPS记录。这些HTTPS记录大多具有类似的格式，包括指向Cloudflare服务器的地址提示字段值。因此，在某些方面，这并不表明服务器中普遍采用HTTPS记录，而是广泛使用的单个内容分发网络（CDN）平台使用此结构。在Cloudflare的情况下，Cloudflare托管的服务名称由Cloudflare运营的权威服务器提供服务，因此包含适当的HTTPS记录相对简单。鉴于加快HTTP内容交付元素的几乎普遍愿望，其他内容交付平台在不久的将来也可能采用QUIC支持。

浏览器世界中普遍采用QUIC的下一步很可能在于Chrome浏览器发布代码的时间，以添加HTTPS DNS记录作为在初始获取时启用QUIC的触发器。APNIC实验室提供QUIC使用测量。

link：https://blog.apnic.net/2022/09/07/a-second-look-at-quic-use/