杰夫·休斯顿:再看 QUIC 协议的使用

2022-12-23 16:10:05 来源:教育快播网

编者按

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  作者:杰夫·休斯顿  翻译:张明明(清华大学)  责编:项阳

关键词: QUIC协议 APNIC
分享:
x 广告
x 广告

Copyright   2015-2022 魔方网版权所有  备案号:京ICP备2022018928号-48   联系邮箱:315 54 11 85 @ qq.com