Anycast在上下文中的应用和比较：两个系统的故事

398Anycast in Context：A Tale of Two Systems（英语：ATale of Two Systems）托马斯·科赫哥伦比亚大学伊森·卡茨-巴塞特哥伦比亚大学可丽哥伦比亚大学马特·考尔德微软/哥伦比亚大学卡尔文·阿迪USC/ISI约翰·海德曼USC/ISI摘要Anycast用于提供包括网页和DNS在内的内容，并且Anycast部署正在增长。然而，之前对根DNS的研究表明，任播部署会导致显着的通货膨胀，用户经常被路由到次优站点。我们重新评估选播性能，首先扩展之前的根DNS膨胀分析通货膨胀在根DNS中非常普遍，影响了95%以上的用户。然而，我们随后展示了根DNS延迟对用户来说几乎不重要，因为缓存是如此有效。 这些发现使我们产生了一个问题：通货膨胀是任播固有的吗？或者通货膨胀在重要的时候可以被限制吗？为了回答这个问题，我们考虑微软在这里，延迟比根DNS更重要也许是因为这种需求，只有35%的CDN用户经历过任何通货膨胀，他们经历的量小于根DNS。我们表明，CDN任播延迟几乎没有通货膨胀，由于广泛的对等和工程。这些结果表明，先前声称的任播低效率反映了对单个应用程序的实验，而不是任播的技术潜力，并且它们证明了在测量系统性能时上下文的重要性。CCS概念• 网络→网络性能分析关键词Anycast、根DNS、路由、延迟、CDN。ACM参考格式：Thomas Koch，Ke Li，Calvin Ardi，Ethan Katz-Bassett，Matt Calder，and JohnHeidemann. 2021 年 Anycast in Context ： A Tale of TwoSystems.在ACM SIGCOMM 2021会议（SIGCOMM '21），2021年8月23日至27日，虚拟活动，美国。 ACM， 纽约州纽 约 市， 美 国 ， 20 页 。https://doi.org/10.1145/3452296.34728911引言IP任播是一种路由方法，其中地理上不同的服务器（称为任播站点）都使用相同的IP地址。它被许多操作域名系统（DNS）[1，7，允许制作本作品的全部或部分数字或硬拷贝供个人或课堂使用，无需付费，前提是复制品不以营利或商业利益为目的制作或分发，并且复制品在第一页上带有此通知和完整的引用。版权的组成部分，这项工作所拥有的其他人比ACM必须尊重。允许用信用进行提取 复制，或重新发布，张贴在服务器上或重新分发到列表，需要事先特定的许可和/或费用。请求权限请发邮件至permissions@acm.org。SIGCOMM©2021计算机协会ACM ISBN 978-1-4503-8383-7/21/08。- 是的- 是的十五块https://doi.org/10.1145/3452296.347289131，39，65]和内容分发网络（CDN）[16，21，30，65，75]部署，部分原因是它能够改善客户端的延迟并减少每个任播服务器上的负载[45，55，64]。然而，研究认为，与给定部署站点可以实现的最低延迟相比，任播通 常 提 供 次 优 性 能 [51 ， 54 ， 67] 。 值 得 注 意 的 是 ，SIGCOMM2018 年 的 论 文 《 Internet Anycast ： Performance ，Problems，&Potential》已经引起了人们的注意，即Anycast可以将延迟增加数百毫秒[51]，这给论文的读者留下了对Anycast的不良印象。相反，其他研究表明，微软的任播CDN [ 16 ]和谷歌公共DNS [ 50 ]的通胀率相当低，但使用了不同的也许是因为这些研究的结论非常不同，我们发现社区中的一些专家对任播有负面的看法特别是，看起来令人惊讶的是，Anycast在生产系统中继续得到更多的采用和增长-如果它导致通货膨胀，为什么还要继续使用Anycast呢？为了理解任播低效率的影响，以及它在通货膨胀的情况下的广泛使用，我们退后一步，将任播作为实际应用程序/服务的一个组成部分进行评估。影响用户的性能取决于任播部署、在服务中如何使用任播以及用户如何与服务交互。 为了看到这些效果，我们考虑了任播在两个现实世界系统中的作用：根DNS和微软的任播CDN服务Web内容。这些应用程序有不同的目标，它们是互联网的关键组件，并且它们是两个占主导地位的，研究最多的任播用例。我们分析了根DNS [39]数据包跟踪，这些数据包可通过DITL [26]获得，并且在现有的任播研究中有特色[23，51，54，58，69]，与以前的工作相比，覆盖范围有所增加。13个根字母独立运行，具有不同的部署策略，使研究不同的任播部署提供相同的服务。我们分析了来自几乎所有根DNS信件的两天未采样数据包捕获，包括来自数百万个递归解析器的数百亿个查询，代表全球所有用户进行查询，为我们提供了广泛的覆盖范围。我们还使用与根DNS相同的方法检查Microsoft微软我们分析了来自数百个国家/地区的超过10亿Microsoft用户的全球测量结果，从而全面了解CDN性能。通过这些测量，我们提出了迄今为止最大的关于任意投射延迟和膨胀的研究我们首先验证并扩展了之前关于任播部署中膨胀的工作[51]。 虽然这项工作主要集中在一个单一的根字母，我们分析几乎399SIGCOMM根DNS 通过将根DNS捕获与全球范围的用户行为跟踪相结合，我们发现比以前认为的更多的用户经历了一些膨胀（平均超过95%），多达40%的用户经历了超过100 ms的膨胀到某些根字母（§3）。然而，由于每个递归解析器可以优先查询其性能最好的根字母，因此每次查询根字母的平均膨胀比以前认为的要低–递归是否必须为用户实现优先查询策略，以便膨胀不会损害用户性能？答案是一个响亮的“不”-使用新的方法，将DNS查询分摊到受益于缓存查询结果的用户，我们发现用户几乎无法感知根字母之间的延迟和膨胀差异-大多数用户每天与根DNS交互一次（§4）。 延迟是最小的，因为根DNS记录的缓存与递归解析器的长TTL。到根DNS的膨胀的任播路由可能是延迟无关紧要的结果，导致根操作员没有为此进行优化，或者膨胀可能是任播路由中固有的，如先前工作中所建议的。为了确定是哪种情况，我们使用了微软CDN的测量结果，发现如果微软CDN的延迟被假设为单个根字母膨胀，则会导致每个页面加载数百毫秒的额外延迟。这种增加的延迟会对用户的整体体验产生负面影响，特别是与根DNS相比。关键的区别是，用户在获取Web内容时会对Microsoft的CDN产生几个RTT，而由于DNS缓存，用户很少等待对根DNS的查询（第5.1节）。在这种情况下，我们测量了微软CDN中的实际通货膨胀，发现通货膨胀保持相对较小（§5.2），特别是与单个根字母相比。为了解释为什么这些部署中的膨胀如此不同，我们对比了用户、Microsoft CDN和根之间的AS级连接性和膨胀我们发现，微软能够通过广泛的对等和工程投资来控制通货膨胀（第7.1节），尽管随着部署规模的扩大，效率会提高（第7.2节）。通过与根DNS和CDN运营商的讨论，我们发现最近的根DNS扩展（令人惊讶地）是由减少延迟和减轻DDoS攻击的愿望驱动的，而CDN扩展是由市场力量驱动的（§7.3）。这两种部署中的性能比较使我们能够从以前的工作中获得结果[16，23，51，69]。 尽管根膨胀很大，但用户很少体验到它，这使得它对平均查询的影响非常小。相比之下，用户频繁与CDN交互，并且那里的通货膨胀很小。考虑到运行微软CDN和根DNS的组织的经济激励，这些通胀结果是有道理的虽然我们希望这些结果适用于其他使用任播的延迟敏感服务，因为它们具有类似的经济激励，但我们工作的一个关键要点是，任播必须在使用它的服务的上下文中进行分析（§7.3），因此我们不能对普遍性做出明确的声明。因此，我们并不反驳过去的说法，即任播可以膨胀lasting，但我们扩大这些研究表明，在它的计数，任播性能可以相当不错。这篇论文不涉及伦理问题。2方法和数据集我们使用DNS数据包捕获和全局CDN测量的组合来测量延迟和膨胀。根DNS数据是现成的[26]，而CDN数据是专有的。我们使用RIPE Atlas [71]中的测量值补充这些数据集我们在附录A中总结了许多数据集的特征、优点和缺点。2.1根DNS我们讨论的两个系统中的第一个是根DNS，它是全球DNS基础设施的关键部分 DNS是互联网的基本查找服务，通常将主机名映射到IP地址[22，56]。要将名称解析为其结果，用户将DNS请求发送到递归解析器（递归）。 递归查询权威DNS服务器，因为它从根到顶级域（DNS），然后沿着树向下遍历DNS树。 递归缓存结果以根据记录的TTL来响应未来的请求。根DNS服务器由13个字母提供，每个字母都有不同的任播部署，有6到254个任播站点（截至2021年7月），由12个组织运行。根DNS站点可以是本地的或全局的-本地站点服务于小的地理区域或某些AS（通过限制来自该站点的任播BGP公告的传播来控制），而全局站点是全局可达的我们使用三个数据集：对于最终用户，我们使用来自南加州大学的美国科学院（ISI）的长期数据包捕获，以及来自两位作者日常使用的DNS和浏览器测量。 对于DNS服务器，我们在大多数根服务器上使用48小时数据包捕获，来自互联网生命中的一天（DITL）[26]。从ISI捕获的数据包提供了根DNS查询的本地视图递归解析程序运行BIND v9.11.14。从2014年到现在的捕获反映了通过递归解析器的端口53的所有流量（传入和传出）。我们使用2018年的跟踪（约1亿次查询），因为它们与我们的其他数据集在时间上重叠。 这个递归解析器接收了来自笔记本电脑上的数百名用户以及网络研究小组的一些台式机和机架式计算机的查询，因此结果可能会偏离典型人群。在我们使用的时间段内，我们没有发现测量实验或其他明显的异常。我们使用DNS-OARC存档的2018年 DITL捕获[26]来获得根DNS使用的全局视图DITL每年发生一次，每次事件都包括来自大多数根服务器的数据2018年DITL发生在2018/04/10-12，包括12个根字母（除G根外）。 来自I root的痕迹是完全匿名的，所以我们没有使用它们。来自B根的跟踪是部分匿名的，但仅在/24级别。 我们的分析不依赖于比/24更具体的地址，因此我们使用来自B根和除G和I之外的所有其他根的所有数据。尽管2018年DITL比最近的DITL更老，但它比最近的DITL更完整;在附录B.3中，我们对2020年DITL进行了分析，发现我们的主要结论没有变化。由于我们的目标是部分了解根DNS延迟如何影响用户，因此我们过滤DITL中不影响用户延迟的查询以及由递归生成的查询，我们没有用户数据。我们描述了DITL的这种预处理以及随后将根查询卷与Microsoft的CDN用户人口计数连接起来400∩⟨⟩⟨⟩SIGCOMM在对所有根的519亿次日常查询中，我们丢弃了310亿次对不存在的域名的查询和20亿次PTR查询。大约28%的不存在的域名查询是来自基于Chromium的浏览器的NXDomain劫持检测[4，34，73]，因此涉及机器启动而不是浏览延迟。先前的工作表明，其余的是由其他故障自动化软件产生的[28]。类似地，虽然PTR查询有一些用途（跟踪路由和在身份验证期间确认主机名），但它们不是典型用户Web延迟的一部分。 在附录B.1中，我们发现包含无效的DNS查询会显著改变我们可以得出的关于用户如何与根DNS交互的结论，并且我们为这一步骤提供了更多的理由。接下来，我们删除私有IP空间中前缀的查询[38]（占所有查询的7%）。最后，我们只分析IPv4数据，排除IPv6流量（占查询的12%），因为我们缺乏v6用户数据。DITL中的DNS查询源通常是递归解析器，因此捕获本身无法提供有关每个用户进行了多少次DNS查询的信息为了估计每个用户的延迟，我们使用2019年收集的每个递归的Microsoft用户的近似数量（我们拥有的最早的用户数据此用户数据来自Microsoft DNS数据，该数据将唯一IP地址视为“用户”。此定义低估了使用网络地址转换的单个IP地址的多个人类用户。Microsoft将递归映射到用户IP地址，并使用现有技术，当用户获取内容时，该技术会使用户请求Microsoft控制的域的DNS记录[17，53]。我们通过递归解析器/24加入DITL捕获和Microsoft用户计数，聚合DITL查询量和Microsoft用户IP计数，每个都按/24前缀1分组，以增加我们拥有用户数据的递归量。 这种聚合是合理的，因为许多组织使用相同/24内的托管服务器作为递归[31，63]。先前的工作也发现，高达80%的/24是搭配的[ 29 ]。我们在附录B.2中为这个预处理步骤提供了额外的理由，通过显示DITL中a/24中的所有地址几乎总是路由到同一个任播站点。为了简单起见，我们将这些/24称为递归，尽管每个/24可能包含几个递归。我们将这个查询量和用户计数的连接数据集称为递归DITL CDN。为了使我们的结果更具可重复性，并作为比较点，我们还使用来自APNIC的公共互联网人口用户计数数据来摊销根DNS查询[37]（即，而不是使用专有的Microsoft数据）。APNIC首先从Google广告投放网络收集按国家分列的IP地址清单，从而获得这些AS用户人口估计数 APNIC将IP地址的分布转换为ASN的分布，按国家互联网用户数量进行标准化。 我们使用Team-CymruIP到IP映射将DITL捕获中看到的IP地址映射到它们各自的AS[25]，并通过IP累积查询。我们能够将99.4%的DITL IP地址映射到IP地址，占DITL查询量的98.6%。对于公共DNS服务来说，递归与它们所服务的用户在同一个AS中的假设显然是不正确的，但我们不会努力纠正这些情况。总的来说，我们认为微软的用户数量1我们在计算之前通过递归/24聚合用户IP地址，以确保我们不会重复计算用户。R28R47R74R95R110图1：微软 较小环中的站点也在较大环中，图例表示该环中的站点数量。为了提高可读性，我们没有显示一些前端太靠近彼此用户群体以圆圈的形式显示，圆圈的半径与该区域的用户数量成正比，这表明微软已经在用户集中的区域部署虽然这些数据更准确，但其他研究人员更容易获得APNIC的数据，因此提供了一个有用的比较。2.2微软我们还分析了微软的大型任播CDN，该CDN为来自100多个网站的10亿多用户提供Web内容。用于微软CDN的流量分配在存在点（PoP）进入其网络，并被路由到服务于内容的任播站点之一（前端）。Microsoft将其部署组织为站点组（称为环），这些站点组符合不同程度的法规限制（例如， ISO 9001，HIPAA），每个都有自己的任播广告。 这些环具有这样的性质，即在一个较小环中的一个位置也在所有较大环中。其他CDN必须在类似的监管限制下工作[2]。因此，来自去往微软CDN的用户前缀的流量可能会在不同的前端结束（取决于应用程序使用的环），但通常会在同一PoP进入网络。用户通过任播路由到环，并通过其任播地址从前端获取网络内容用户总是被路由到应用程序的监管限制所允许的最大环（不考虑环之间的性能差异）。微软在图1中，我们展示了微软环是根据它们所包含的前端的数量来命名的，前端是根据它们所属的最小环来标记的（否则所有前端都将被标记为R110）。为了提高可读性，我们没有显示一些前端太靠近彼此。 圆是平均用户位置，其中圆的半径与该区域中的用户数量成比例。图1表明，前端位置往往靠近大量人口，为大多数用户提供至少一个低延迟选项。附录F说明了各地区的延迟差异。用户位置按地区聚合，这是Microsoft内部使用的地理区域，用于将世界划分为产生类似流量的区域，因此包含类似数量的用户。一个地区通常对应于一个大都市区。我们指的 是 区域AS粒度的用户，因为同一区域AS位置的用户通常被路由到相同的前端，因此（通常）经历类似的延迟。全国共有508个地区401⟨⟩⟨⟩∩⟨⟩（）（查询次数（，）是对所有站点的查询总数SIGCOMM欧洲135个，非洲62个，亚洲102个，南极洲2个，北美洲137个，南美洲41个，大洋洲29个为了研究微软CDN的性能前端的服务器端日志收集有关用户TCP连接的信息，包括用户IP地址和TCP握手RTT。 使用这些RTT作为延迟测量，我们计算从一个区域的用户，AS位置到服务他们的每个前端的平均延迟。2Microsoft使用内部数据库确定用户的位置和AS客户端测量来自Microsoft操作的测量系统 [17]。 延迟度量是Microsoft用户通过HTTP获取小图像所需的时间。3测量系统指示使用CDN服务的客户端向多个环发布测量结果，这使得我们能够消除由于托管在具有不同客户端足迹的不同环上的服务而导致的延迟模式的偏差（例如，企业对住宅业务）。微软收集用户群体的数据，记录用户的位置和AS。由于这些测量直接来自最终用户，我们不知道用户访问了哪个前端 对于客户端测量和服务器端日志，我们收集了15，000个区域和AS位置的超过10亿用户的统计数据。我们还使用RIPE Atlas来ping任播环，因为我们不能共享绝对延迟数字。 我们将这些结果与我们测量CDN用户延迟的（私有）数据进行校准。我们总共从500多个AS的1，000个RIPEAtlas探测器收集了7，000个ping测量值，以增强CDN延迟测量。（随机选择探针，并对每个环测量三次。）3路由到根DNS是膨胀早期的工作已经发现到根DNS的查询距离通常显着膨胀[13，23，51，67，69]。与此类似，我们我们发现，尽管存在地理上较近的站点，但查询通常会传输到较远的站点。我们以多种方式扩展这种理解 虽然以前的工作只考虑了根DNS活动的子集，并专注于递归而不是用户的地理膨胀，但我们计算了几乎所有根字母的膨胀，并将膨胀放在用户的上下文中，而不是递归解析器。这些贡献之所以重要，有几个原因。首先，考虑更多的根字母使我们能够评估不同部署中的通货膨胀，并且使用大多数字母，我们可以评估根DNS系统。由于递归会对多个根目录进行查询，而不是试图推断在等效单播部署中将存在哪种膨胀。首先，用于确定单播膨胀的测量平台的覆盖范围，例如RIPE Atlas（任播研究的优势点[51，69]）并不具有代表性[10]。其次，计算单播膨胀需要知道从DITL中看到的每个递归到每个根字母的最佳单播替代方案，这将难以用RIPE Atlas近似，因为一些字母不公布其单播地址。第三，我们发现将延迟与理论下限进行比较是有价值的，因为用户到最佳单播替代方案的路由可能仍然会膨胀。我们通过查看递归解析器指向的站点来测量根DNS的两种类型的膨胀DITL捕获是一个丰富的数据源，因为它们为我们提供了一个关于哪些递归访问哪些位置的全局视图（2.1节）。我们的通胀分析涵盖224个国家/地区及22，243个AS（截至2021年7月，Atlas涵盖约3，700个AS）。我们计算第一种类型的通货膨胀（1））-13个根字母中的10个以上，省略了不提供数据的G，H在2018年只有一个网站（因此通货膨胀为零），以及I，其中匿名化阻止分析。地理膨胀在高级别上衡量与最近的前端相比用户如何路由到站点（即，效率）4.我们计算第二种类型的膨胀（2））由于畸形的DITLPCAP，我们的延迟膨胀分析进一步排除了D和L根。延迟膨胀使用测量的延迟来确定膨胀，因此它反映了由于物理通行权和连接、不良路由和对等选择而导致的约束。我们计算了每个根，解析器/24，任播站点的平均延迟，我们至少有10个测量，为我们提供了解析器的延迟，代表了这些根的DITL查询量的40%3.1方法为了计算地理通货膨胀，我们首先使用MaxMind [ 41 ]在我们的DITL CDN数据集中地理定位所有递归，遵循先前的方法，该方法确认MaxMind对于地理定位递归解析器是适当准确的，以评估通货膨胀[51]。然后，我们计算每个递归向根服务器发送查询的地理膨胀（按光纤中的光速缩放） ，GI（，���）=2（∑（，���） （，���）−min（，���））（1）���������字母，有利于那些具有低延迟[60]，系统性能并且膨胀可以（并且确实）与部件性能不同（其次，我们通过用户数量来加权递归解析器当我们在一起时，（，）是通过检索向站点查询的查询次数，我们通过对具有大覆盖率的延迟（与地理位置相对）膨胀进行分析来扩展先前的工作先前的任播研究已经将膨胀分为两种类型，单播和任播，试图梳理出任播具体向查询添加了多少延迟[13，16，51，69]。出于几个原因，我们选择考虑相对于部署的通货膨胀，2我们还研究了其他的一些问题（例如，第95位），并发现定性结果相似。3DNS解析和TCP连接时间被排除在外。在根递归解析器中，递归解析器是光纤中的光速，系数2表示往返延迟，递归解析器和站点之间的距离是递归解析器和站点之间的距离，求和和最小化都是在本信部署中的全局站点上进行的（有关局部和全局之间的区别，请参见第2.1我们只考虑全局站点，因为我们不知道哪些递归可以到达局部站点。对于可以到达本地站点的递归[4]测量拓扑膨胀（在互联网拓扑上传播的额外距离，超过最短路径传播延迟）是很有趣的，但是使用现有的方法很难做到这一点而不牺牲显著的覆盖范围。这让我们可以看到用户如何受到通货膨胀的影响最后，402（）∑（）3×3SIGCOMM而是到达全局站点，则等式（1）（和等式（2））可能低估实际通货膨胀。GI������是一个膨胀的近似值，当执行一个从递归到根部署���的查询时 ，在所有站点上平均。递归的总体地理膨胀是所有根的经验平均值。即使来自相同递归/24的查询通常一起路由，由于中间AS中的负载平衡，它们也可能被路由到不同的站点（参见附录B.2了解这种情况发生的频率），因此我们对递归的站点进行平均地理膨胀调查地理膨胀是有用的，因为它显示了我们的结果与之前的工作相比如何，有多少用户被夸大了，它给了我们一个衡量“效率”的标准（第7.2节）。我们还计算延迟膨胀，再次考虑DITL中的递归查询模式。我们计算延迟膨胀LI（i，i），用于递归根目录的用户1.00.90.80.70.60.50.40.30.20.10.01.00.90.8M -5E -15D -20K -52突击步枪ts所有RooL -138歼-68C -10A -5B -20 20 40 60 80 100 120 140每个根查询的地理膨胀（ms）（a）LI（λ，λ）=（( , )3 2���–最小 值，最大值（2）0.70.60.50.4其中，（，）是递归0.3位置和其他变量如等式（1）中所示。 先前工作0.20.1注意到路由的延迟很少小于大圆0.0两个端点之间的距离除以2[46]，因此我们使用20 25 50 75 100 125 150 175 200每个根查询的延迟膨胀（ms）最好的延迟递归可以实现的下限 延迟膨胀是由于路由或扩展物理互联网（例如，铺设纤维）。一个限制是我们没有考虑到DITL跟踪中某些查询的源地址可能是伪造的。欺骗更有可能使我们计算出的膨胀更大，特别是在欺骗对象远离它所欺骗的物理接口的情况下（即，从我们的角度来看，当实际上源地址被欺骗时，路由看起来是膨胀的）。我们不试图纠正这些情况，因为很难区分合法的不良路由和欺骗流量。3.2结果图2a展示了根DNS查询经历任何地理膨胀的可能性（等式2a）。（1））大致随着部署规模（y轴截距）而增长，扩展了先前工作中的结果，这些结果呈现了正交的聚合视图[51]。的所有根行考虑到每个递归将其查询分布在不同的根上。 在图2a中，它具有最低的y截距，这意味着几乎每个递归都经历了至少一个根的膨胀，并且膨胀递归的集合在各个根之间变化。因此，我们的分析表明，几乎每个用户在查询根DNS时都会（平均）遇到膨胀， 10.8% 的用户可能会膨胀超 过 2 ， 000 km（ 20ms）。图2b示出了对这些根的查询经历频繁的延迟膨胀（等式2b）。（2）），其中20%至40%的用户经历大于100 ms的膨胀（B根是明显的例外，但只有2个站点，因此膨胀不太有意义）。延迟膨胀从大约零开始，这是从我们选择的（2））。 与地理膨胀相比，延迟膨胀在尾部特别大。例如在（b）图2：使用地理信息（2a）和TCP RTT估计（2b）测量的通货膨胀。一般来说，较大的部署更有可能膨胀路径，并且根中的膨胀相当大。图例表示2018年DITL期间每个字母的全球站点数量第95���百分位C根具有240 ms的等待时间膨胀，但仅具有70 ms的地理膨胀。然而，根DNS作为一个整体的膨胀并不像行AllRoots所示的单个根字母那么糟糕，这考虑到递归可以优先查询低延迟根服务器[60]。我们的延迟膨胀度量显示Croot比以前认为的更膨胀，将35%的用户膨胀超过100 ms，达到以前工作中报告的20%[51]（尽管与以前工作的比较并不完美，因为测量的是不同的）。其他先前的工作发现了显著的根膨胀，但由于膨胀以不同的方式呈现，因此很难直接比较结果[23，69]。很明显，路由到单个根字母经常被夸大，许多查询比需要的多走数千公里，对一些用户来说被夸大了数百毫秒4根DNS延迟和通货膨胀几乎无关紧要随着对根DNS膨胀的更深入了解，人们可能会想知道为什么根字母的膨胀在不断增长的部署和根DNS我们现在展示了根DNS膨胀不会导致太多用户可见的延迟。4.1测量根DNS延迟很重要根DNS服务器托管TLD的记录（例如，COM，ORG）。大约有一千个TLD，几乎所有的TLDCDF用户CDF用户B - 两个一 - 五个M - 五个C - 十个EK - 十五岁- 五十二J -68F -94All根403SIGCOMM对应的DNS记录具有两天的TTL因此，由于本地解析器的共享缓存，人们可能会认为根DNS延迟对用户来说无关紧要 最近的工作甚至表明根DNS可以完全废除[5]或在很大程度上被递归中的抢占式缓存所取代[48]。我们提供了几个原因，为什么我们发现有必要显式测量根DNS延迟对用户的影响，而不是使用直觉。首先，在专业和研究社区中，根DNS受到了很多关注。例如，一些专家在谈话中问我们为什么CDN使用Anycast，当Anycast在根DNS中膨胀时。 SIGCOMM2018年的论文&《Internet Anycast：Performance，Problems，Potential》已经引起了人们的注意，即Anycast可以将根DNS的延迟增加数百毫秒[ 51 ]。 来自rootletters的博客文章讨论了延迟改进和通货膨胀减少[3，14，61，79]-为什么延迟对root很重要？此外，在过去5年中，根DNS站点的数量稳步增加，从516个增加到1367个，增加了一倍多。为什么有这么多的投资在更多的网站？其次，定量分析系统，尤其是大规模运行的全球系统，是有价值的，即使我们可以直观地定性地推理这些系统而不进行分析。我们使用来自13个根字母中的11个的数据进行分析，使我们能够真正全面地了解用户如何与根DNS进行交互。我们只知道另一项研究是关于缓存如何影响根DNS查询的[44]，但该研究是旧的，仅限于一个递归解析器，并且没有将DNS查询置于用户体验的上下文中。第三，虽然TTL的记录是两天，递归解析器的实现可能是错误的。我们注意到每天有数百万次对递归记录的查询被一些递归程序发送到根字母（第4.3节），并发现流行的BIND递归解析器软件中存在一个错误，导致对根的不必要查询（附录E）。因此，提出关于根DNS延迟的论点需要仔细分析。4.2我们如何衡量根DNS测量根DNS延迟如何影响用户提出了几个挑战。要将根DNS延迟放到上下文中，我们必须了解（1）当应用程序进行根查询时，用户应用程序性能如何受到影响，（2）在给定缓存的情况下，终端主机和递归解析器与根DNS交互的频率，（3）来自任播部署的延迟是什么，以及（4）这些影响如何随位置和根字母而变化。这些挑战既激发了我们随后的分析，也突出了先前工作的局限性，这些工作没有捕捉到根DNS延迟的这些微妙之处[23，51，58，69]。因此，精确确定根DNS延迟如何影响用户将需要全局的操作系统级控制来选择递归并查看操作系统DNS缓存;全局应用程序级数据来查看何时进行DNS查询以及此延迟如何影响应用程序性能;全局递归数据来查看缓存、根查询及其延迟;以及全局根跟踪来查看如何路由对根的查询。 截至2021年7月，只有谷歌可能拥有这些数据，而收集这些数据将是一项艰巨的任务。为了克服这些挑战，我们从两个角度来看待根DNS交互：本地（靠近用户）和全局（跨多个超过10亿用户）。我们的本地视角精确地测量了根DNS查询如何在用户浏览会话中摊销，而我们的全球分析则估计了全球用户对根执行的查询数量。4.3根DNS延迟几乎无关紧要本地视角：为了获得根DNS查询如何在小群体中分摊的精确度量，我们在ISI使用递归解析器的数据包捕获（§2.1）。我们还从两个作者的计算机上进行测量，以观察单个用户如何与根服务器（没有共享缓存）交互，因为ISI跟踪并没有为我们提供有关用户体验的上下文。 来自两名用户的数据有限，这反映了我们在第4.2节中确定的挑战。然而，这些实验提供了这些作者如何与根DNS交互的精确测量（以前没有研究过），补充了本文大部分使用的全球规模数据。使用ISI收集的痕迹，我们计算查询任何根服务器的用户请求的递归解析器的一部分。 我们将此度量称为根缓存未命中率，因为它近似于在用户查询的情况下在递归的缓存中找不到缓存记录的频率。这是近似的，因为解析器可能已经为每个用户查询发送了多个根请求，并且某些根请求可能不是由用户查询触发的。解析器的每日根缓存未命中率范围为0.1%到2.5%（未显示），中值为0.5%。2018年的整体缓存未命中率也为0.5%。特定的缓存未命中率可能会因用户查询行为和递归解析器软件而异，但显然由于共享缓存，未命中率很小。附录D显示了根DNS延迟对ISI用户的最小影响，以及ISI用户经历的DNS延迟的CDF。由于ISI的测量只能告诉我们根DNS查询的生成频率，因此我们接下来将研究根DNS延迟与最终用户应用程序延迟的比较。在两个作者在解析器和互联网之间。我们运行了四周的实验，并观察到平均每日根缓存未命中率为1.5%考虑到本地用户无法从共享缓存中获益，较大的缓存未命中率是有我们还使用浏览器插件来测量平均每日活跃浏览时间和平均每日累积页面加载时间，因此我们可以将DNS延迟纳入考虑范围。活动浏览时间定义为用户与页面交互所花费的时间（超时为30秒），而页面加载时间定义为window.onLoad事件发生之前的时间。每日根DNS延迟中位数是每日页面加载时间中位数的1.6%和每日活动浏览时间中位数的0.05%，这意味着即使没有共享缓存，这些用户在加载网页时也几乎察觉不到根DNS延迟。一般来说，我们高估了DNS和根DNS延迟的影响，因为DNS查询可能是作者机器上运行的任何应用程序（不仅仅是浏览）的全局视角：为了获得用户如何与根DNS交互的全局视角，我们接下来研究全局查询404∩SIGCOMM1.00.80.60.40.20.0理想CDNAPNIC标记为理想的行不使用DITL查询量来计算每日用户查询计数，而是表示一种假设场景，其中每个递归查询针对所有SQL记录的每个TTL恰好一次，并将这些查询均匀地分摊到其各自的用户群体中（我们使用Microsoft用户计数来计算理想）。由此产生的假设每日查询计数中位数为0.007可能代表了一个未来，在这个未来，缓存以递归的方式工作，在不必要的理想也证明了假设重现的程度10−3 10−2 10−1 100 101 102 103每天的用户数图3：每个用户对每TTL仅查询一次会低估用户的延迟由于根DNS（§4.2）的经验根每天的APNIC线代表不同的用户-我们已经展示了根DNS延迟，因此路由膨胀计数数据集。理想线给出了关于递归查询行为的理想化假设。大多数用户每天等待不到一个对根的查询，无论我们使用哪个用户数据递归的行为 正如4.2节所讨论的，很难在解析器上建模缓存以及缓存如何节省用户延迟，因为缓存隐藏了用户查询模式（通过设计）并且与递归实现不同。 为了克服这一挑战，我们使用了一种新的方法，通过将DNS查询模式与用户数据相结合，在大量用户群体中分摊查询。给定递归对根服务器的查询量和使用DITL捕获的每个递归的用户计数（§2.1），我们估计用户每天等待的根查询数量图3是每个用户每天预期查询次数的CDF，其中线路CDN和APNIC使用不同的用户-count dataset（§2.1）和lineIdeal使用了我们下面描述的假设 图3表明，大多数用户每天等待的根查询不超过一个，不管我们使用的是哪个用户数据。为了生成图3中的每一行，我们除以（即，将每个递归向根服务器进行的查询的数量与递归表示的用户的数量进行分摊。我们对这个商进行加权（即， 每个用户的每日查询），并计算得到的CDF。 我们通过首先计算每个站点的每日查询率（即，总查询数除以总捕获时间），然后将这些速率跨站点求和。我们包含了跨根服务器捕获的几乎所有根查询，因此图3提供了用户如何与根DNS交互的真正全局视图CDN和APNIC这两行分别对应于将DITL查询分摊到Microsoft和APNIC用户数上。因此，每一行代表的“用户”集合在技术上是不同的，但我们将它们放在同一个图上进行比较。尽管根查询背后的两种估计用户计数的方法非常不同（CDN使用内部测量系统，而APNIC使用按国家分列的互联网人口估计数），但对这些用户群的查询进行分摊，仍然得出关于用户如何与根域名系统互动的同样高水平的结论，这表明我们的方法和结论是合理的--用户很少与根域名系统互动，平均每天执行一次查询。尾部的用户可能是垃圾邮件发送者，有bug的递归软件，或者代表比DITL CDN建议的用户更多的递归（例如， 蜂窝网络）。 APNIC用户估计数不受NAT的影响，并且APNIC的尾部较小。对大多数用户来说，这并没有什么区别这一结果提出了一个问题-是路径的根膨胀，因为任播内在的结果膨胀？ 或者说，在这种情况下，延迟不重要是否会导致没有针对延迟进行优化的任播部署，因此往往会有膨胀的路由？为了回答这些问题，我们转向一个新的系统，使用任播服务延迟敏感的内容5微软CDN的延迟问题我 们 证 明 了 延 迟 （ 因 此 通 货 膨 胀 ） 在 获 取 Web 内 容 时 对Microsoft用户来说确实很重要，这与根DNS中的大多数用户不同，主要是由于获取Web内容时用户产生的RTT数量。5.1页面加载中的RTT为了估计用户在与Microsoft页面加载中的RTT数量取决于各种因素，因此我们的目标是降低数量。我们将RTT的数量设为下限，因为下限是CDN膨胀影响的保守度量，因为延迟膨胀随着每个额外的RTT而累积，并且较大的页面（更多RTT）将受到更多影响。我们提供了一个估计这个下限的基础上建模和评估的一组网页托管的Microsoft 由于篇幅限制，我们在附录C中包含了我们的测量和方法的全部细节。5.2Microsoft我们现在测量用户如何受到MicrosoftCDN延迟的影响。首先，使用RIPE Atlas探测器的测量结果，我们证明CDN延迟会导致用户在获取Web内容时出现显著延迟。然后，使用客户端测量和服务器端日志，我们还表明，延迟通常会随着站点的增加而因此，微软有一个主要的动机来限制用户所经历的通货膨胀，并且在微软的CDN的情况下，对更多的任意播放网站的投资对用户体验的积极影响要比在根中大得多。对用户体验的积极影响是最近扩展的主要原因（§7.3）。CDF用户CDN405⟨⟩⟨⟩⟨⟩⟨⟩⟨⟩SIGCOMM1.00.90.80.70.60.50.40.30.20.1020CDN每RTT延迟（ms）4060 80100120因此，图4a可能低估了用户通常经历的延迟。用户可以体验每页最多1，000 ms的任播延迟负载，并且，对于大型部署（例如， R95），一半的RIPEAtlas探测器在每次页面加载时经历大约100 ms的延迟（图4a）。因此，毫不奇怪，微软CDN的延迟会影响用户体验，