大家好，又见面了，我是你们的朋友全栈君。
分析任播CDN的性能
摘要
内容分发网络在决定将客户端引导到哪个CDN服务器时，必须在多种策略中进行权衡。基于DNS的重定向需要一个复杂的全球流量管理器，而任播则依赖于BGP协议来引导客户端到CDN前端。任播操作简单，可扩展性强，且天然抵御DDoS攻击。然而，这种简单性是以精确控制客户端重定向为代价的。我们研究了在一个全球性的、对延迟敏感的CDN中使用任播的性能影响。我们分析了Bing搜索服务中数百万客户端测量结果，以比较任播与单播到附近前端的性能。我们发现，尽管缺乏精确控制，任播通常表现良好，但它将大约20%的客户端引导到次优的前端。我们还展示了可以通过一个简单的基于历史的预测方案来改善这些客户端的性能。
关键词
任播；CDN；测量；
引言
内容分发网络是互联网基础设施的重要组成部分。CDN在全球部署前端服务器，并将客户端引导至附近的可用前端，以减少带宽、提高性能并保持可靠性。我们将关注一种CDN架构，该架构将客户端引导到附近的前端，前端终止客户端的TCP连接，并将请求转发到数据中心的后端服务器。CDN面临的主要挑战是将每个客户端映射到正确的前端。对于延迟敏感的服务（如搜索结果），CDN尝试通过将客户端映射到附近的前端来减少客户端感知的延迟。
CDN可以使用多种机制将客户端引导到前端。最流行的两种机制是DNS和任播。Akamai开创了基于DNS的重定向策略。它提供了对客户端-前端映射的细粒度和接近实时的控制，但需要在基础设施和运营方面进行大量的投入。
一些较新的CDN如CloudFlare依赖于任播，从多个位置广播相同的IP地址，使得客户端与前端的映射完全依赖于互联网路由协议。任播只提供对客户端与前端映射的最小控制，并且在设计上对性能不可知。然而，部署基于任播的CDN非常简单且成本低廉——除了部署前端服务器本身外，不需要额外的基础设施投资。实践证明，任播方法非常稳健。
在本文中，我们的目标是回答以下问题：任播是否将客户端引导到附近的前端？如果存在不佳的重定向，其对性能的影响是什么？为了研究这些问题，我们使用了Bing的基于任播的CDN数据。我们在搜索堆栈中加入了仪表，以便一小部分搜索响应页面携带一个JavaScript信标。在搜索结果显示之后，JavaScript测量四个前端的延迟——一个是任播选择的，另外三个是JavaScript定位的附近前端。我们比较这些延迟以了解任播性能，并确定部署DNS解决方案可能带来的收益。
我们的结果描绘了任播性能的复杂图景。对于大多数客户端来说，尽管缺乏集中控制，任播仍然表现良好。然而，任播将大约20%的客户端引导到次优的前端。当任播未将客户端引导到最佳前端时，我们发现客户端通常仍然会到达附近的替代前端。我们证明，任播的这种不效率足够稳定，我们可以通过一个简单的预测方案来引导这些未被任播充分服务的客户端进行DNS重定向，从而提高15%-20%的客户端性能。像任何此类研究一样，我们的具体结论与我们测量的CDN当前的前端部署密切相关。然而，作为我们所知的此类研究的首次尝试，结果揭示了关于CDN性能的重要见解，证明了任播能够为大多数客户端提供最佳性能。
客户端重定向
CDN可以通过多种方式将客户端引导到前端。DNS：客户端将通过属于CDN的域名获取CDN托管的资源。客户端的本地DNS解析器（LDNS），通常由客户端的ISP配置，将接收DNS请求以解析域名并将其转发给CDN的权威名称服务器。CDN根据哪个LDNS转发请求，根据性能决定返回哪个IP地址。DNS重定向使用较小的DNS缓存TTL值进行相对精确的控制，从而在小时间范围内重定向客户端。
由于CDN必须以LDNS的粒度而不是客户端进行决策，因此基于DNS的重定向会面临一些挑战。LDNS可能与其服务的客户端相距甚远，或者可能服务于分布在大的地理区域的客户端，使得权威服务器可以做出没有良好的单一重定向选择。这种情况在公共DNS解析器（如Google Public DNS和OpenDNS）中非常常见，这些解析器为大量的地理位置不同的客户提供服务。针对这个问题的建议解决方案是EDNS客户端-子网前缀标准（ECS），其允许客户端的实际IP地址的一部分被转发到权威服务器，允许根据ip段来决策调度。
任播：任播是一种路由策略，在全球很多地方都有相同的IP地址。然后，BGP根据BGP的最佳路径概念将客户端路由到一个前端位置。由于任播将客户端重定向的实现推迟到互联网路由层面，因此它提供了操作简单性。任播比基于DNS的重定向具有优势，因为每个客户端重定向都是独立处理的——避免了上述的LDNS问题。
任播有一些众所周知的挑战。首先，任播，或者说BGP协议，意识不到网络的性能，所以它不会对路径上网络质量的变化做出反应。其次，任播不知道服务器负载。如果一个特定的前端变得超载，那么很难逐渐将流量从这个前端引导出去，尽管这个领域已经有了最近的进展。简单地撤销路线以使该前端离线可能导致附近前端的级联超载。第三，任播路由选择改变会导致正在进行的TCP会话终止并需要重新启动。在以短流量为主的网络环境下，这在实践中似乎不是问题。包括Cloudflare，CacheFly，Edgecast和Microsoft在内的许多公司都运行成功的基于任播的CDN。
其他重定向机制：尽管在客户端发起请求之前，任播和DNS将客户端引导到前端，但前端的响应也可以将客户端引导到其他服务器以获取其他资源，例如，HTTP状态代码3xx或基于清单的重定向通常用于视频。这些方案增加了额外的RTT，因此不适用于延迟敏感的Web服务，如搜索。我们在本文中没有进一步考虑它们。
方法论
我们的目标是回答两个问题：1）在指导客户到附近的前端方面，任播有多有效？2）与传统的基于DNS的单播重定向方案相比，任播性能如何？我们试用Bing的基于任播的CDN来回答这些问题。这个CDN在世界各地拥有数十个前端位置，全部都在同一个由微软运营的自治系统内。我们使用来自真实客户端到Bing CDN前端的任播和单播测量结果。在第4节中，我们将这个CDN与其他CDN进行比较，并展示客户端到前端的网络距离。
3.1 路由配置
所有测试的前端位置都有任播和单播IP地址。任播：Bing目前是一个任播CDN。所有生产搜索流量都是使用来自所有前端的任播服务。单播：我们还为每个前端位置分配一个唯一的/24前缀，它不提供生产流量。只有与前端最近的对等点的路由器才公布前缀，强制流量进入前端附近，而不是进入微软的骨干网的不同位置并穿越骨干网到达前端。这种路由配置允许在单播和任播之间进行最好的直接比较，因为在特定对等点进入的任播流量也将到达最近的前端。
3.2 数据集
我们在研究中使用了主动和被动测量，如下所述。
3.2.1 被动测量 Bing服务器日志为每个搜索查询提供有关客户端请求的详细信息。对于我们的分析，我们使用客户端IP地址、位置，以及在特定请求中使用了哪些前端。这个数据集是在2015年4月的第一个星期收集的并代表了数百万的查询。
3.2.2 主动测量
为了主动测量来自客户端的CDN性能，我们将JavaScript信标注入Bing搜索结果的一小部分。结果页面完全加载后，信标指示客户端获取四个测试URL。这些URL会触发一组DNS查询给我们权威的DNS基础设施。DNS查询结果是用于测量多样性的随机前端IP，我们将在第3.3节中进一步讨论。
信标通过下载URL指向的资源来测量这些前端的延迟，并将结果报告给后端基础设施。我们权威的DNS服务器也将他们的查询日志推送到后端存储。每个测试URL都有一个全球唯一的标识符，允许我们将来自客户端的HTTP结果与服务器端的DNS结果结合起来。
JavaScript信标实现了两种技术来提高测量质量。首先，为了从我们的测量中消除DNS查找的影响，我们首先发出预热请求，以便后续测试将使用缓存的DNS响应。虽然DNS延迟可能是Web浏览性能不佳的一些方面的负责，但在本工作中，我们关注的是客户端和前端之间路径的性能。我们设置的TTL比测试信标的持续时间长。其次，使用JavaScript来衡量获取开始和结束之间的已用时间已知不是性能的精确测量，而W3C资源计时API提供了从符合标准的Web浏览器中获取准确的资源下载定时信息。信标首先使用原始时间记录延迟。完成后，如果浏览器支持资源定时API，则信标替换为更准确的值。
我们研究从2015年3月和4月的数百万搜索查询中收集到的测量数据。我们将来自测量的客户IP地址聚合到/24前缀中，因为它们倾向于本地化。为了反映每个/24前缀查询的数量在前缀中严重偏斜，对于被动测量和主动测量，我们给出了一些我们的结果，用相应前缀的查询数加权为/24测量。
3.3 选择测量的前端
我们测量的主要目标是比较任播与通过将客户指向最佳性能前端所获得的性能进行比较。从每个客户端到每个前端的测量会带来太多的开销，但是我们无法预先知道哪个前端对于特定客户端在给定时间点是最佳选择。
我们使用三种机制来平衡测量开销和测量准确性，从而揭示最佳选择方案并获得足够的测量结果。首先，对于每个LDNS，我们只考虑LDNS的十个最接近的前端（基于地理位置数据）作为候选者考虑返回到该LDNS的客户端。最近的研究表明，LDNS对客户位置的接近程度很好：不包括8%的公共dns，只有11-12%的需求来自离LDNS 500公里以上的客户。在图1中，我们将显示我们的地理位置数据足够准确，客户的最佳前端通常在该集合内。
为了进一步降低开销，每个信标只对前端进行四次测量：（a）对任播路由选择的前端进行测量；（b）对被判断为在地理上最接近LDNS的前端的测量；和（cd）对从其他九个候选者中随机选择的两个前端进行测量，并且选择前端的可能性是通过距离客户端LDNS的距离加权的（例如，第三最接近的前端被选中的可能性高于第四最接近的前端）。第三，对于我们大部分的分析，我们将测量结果按照/24前缀进行聚合，并考虑到前端的性能分布，所以即使不是每个客户端每次都测量到最好的前端，我们的分析也是稳健的。
为了部分验证我们的方法，图1显示了从客户机/24到前端的最小观察延迟的分布。带标签的第N行包括从最近的N个前端到LDNS的延迟测量。结果显示，我们最初包含更多前端的延迟降低，但是例如，在为每个前缀添加五个前端之后，我们看不到什么降低。所以，如果我们测量的距离超过了我们在信标测量中包含的最近的十个前端，我们并不期望最小延迟会改善许多前缀。
CDN规模和地理分布
本文的结果是特定于Bing的任播CDN部署。在本节中，我们描述了部署的规模，显示了我们的部署与大多数其他CDN类似，具有几十个前端服务器位置，特别是大部分任播CDN，尽管它是该部署中最大的部署之一。在粗糙的规模内。我们然后测量这几十个前端位置在客户到最近前端的距离方面的分布情况。我们对CDN性能的描述是理解任播性能的重要第一步。未来工作的一个有趣的方向是理解如何将这些性能结果扩展到具有不同服务器数量和位置的CDN以及不同的域间连接性。
我们根据服务器位置数量来比较我们的CDN和其他CDN，这是影响CDN和任播性能的一个因素。我们检查了21个CDN和内容提供商，其中有公开的数据。四个CDN是极端的异常值。ChinaNetCenter和ChinaCache在中国各有100多个节点。以前的研究也发现谷歌在全球有超过1000个地点，而众所周知Akamai也有1000多个地点。虽然这种部署规模往往在CDN中流行，但实际上却是例外。忽略中国的大规模部署，我们发现公开数据的第二大的CDN是CDNetworks（161个地点）和SkyparkCDN（119个地点）。我们研究的其余17个CDN（包括ChinaNetCenter和ChinaCache在中国以外的部署）有17个地点（CDNify）和62个地点（Level3）。在数量方面，Bing CDN与Level3和MaxCDN最为相似。具有较小部署的知名CDN包括Amazon CloudFront（37个位置），CacheFly（41个位置），CloudFlare（43个位置）和EdgeCast（31个位置）。CloudFlare，CacheFly和EdgeCast是任播CDN。
为了给出前端分布密度的视角，图2显示了客户端到最近前端的距离，由客户端Bing查询量加权。最近的前端的中间距离是280公里，第二最近的是700公里，第四最近的是1300公里。
任播性能
我们使用测量来评估任播支付的性能惩罚以换取简单的操作。图3基于数百万次的测量数据，并在几天的时间内收集起来，并激励我们接受这个项目。
正如第3节所述，每个JavaScript信标的执行都会产生四个测量结果，一个用于任播选择的前端，另一个用于附近的单播前端。对于每个请求，我们发现任播和最低延迟的单播前端之间的延迟差异。图3显示了任播性能比三个单播前端中最好的部分慢的请求。大多数时候，在大多数地区，任播都表现良好，表现和最好的三个附近单播前端一样好。然而，对于20%的请求，任播速度至少要慢25ms，对于客户端来说，只有10%的任播测量速度比100ms或更慢。
这个图表显示了为某些客户使用基于DNS的重定向可能效果更好，剩下的客户则是使用任播更好。请注意，这不是一个上限：为了得出这个结论，我们必须轮询每个信标执行中的所有前端，这个开销太大了。也不能保证部署的基于DNS的重定向系统能够实现图3所示的性能改进——为了达到这种效果，基于DNS的重定向系统必须实际上十分精确。尽管如此，这个结果足以让我们更详细地研究任播性能，并寻求改进方法。
糟糕的任播路线的例子：理解任播性能的一个挑战是弄清楚为什么客户被引导到遥远或者表现不佳的前端。为了排除故障，我们使用了RIPE Atlas测试平台，这是一个8000多个主要在家庭网络监测点的网络。我们发布了来自同一ISP-metro区域内的Atlas探测器的traceroute，我们观察到客户端的性能较差。我们观察在我们的分析中，许多情况都属于两种情况之一。1）BGP对基础拓扑结构缺乏洞察力导致任播做出次优选择；2）ISP的域内路由策略选择远程对等点与我们的网络。
在一个有趣的例子中，一个客户端与两个宣布任播路由的边界路由器的距离大致相同。任播选择路由到路由器A。然而，在我们的网络内部，路由器B非常接近前端C，而路由器A具有到最近的前端，前端D的更长的域内路由。在BGP通告中没有办法沟通这个内部拓扑信息。
其他几个例子包括客户端在前端附近的情况，但ISP的内部策略选择在远处的对等点切换流量。然后Microsoft intradomain策略将客户端的请求引导到离对等点最近的前端，而不是客户端。我们观察到的一些例子是一个运营商从丹佛到凤凰城的客户，另一个从莫斯科到斯德哥尔摩的运输。在这两种情况下，每个来源城市都存在直接对等关系。
受这些案例研究的影响，我们试图定量地理解任播性能。我们要问的第一个问题是，任播性能是否差，仅仅是因为它偶尔引导客户到地理位置远的前端，就像莫斯科的客户去斯德哥尔摩的时候那样。
任播是否将客户引导到附近的前端？在一个遍布全球主要城市地区的大型CDN中，大多数ISP将会从许多不同的地点看到前端的BGP通告。如果这些点之间的对等是一致的，那么ISP从客户到前端花费最低的路径往往是地理上最接近的。由于任播不是负载或延迟感知，所以地理邻近度是预期性能的一个很好的指标。
图4显示了在生产Bing流量的一天内，所有客户端到客户端到任播前端的距离分布情况。一行按查询量权重客户端。考虑到更活跃的客户，任播被认为在所有百分位数上表现更好。我们看到大约有82%的客户是在2000公里以内的前端，而客户端的87%在2000公里以内。
发布者：全栈程序员栈长，转载请注明出处：https://www.php.cn/link/a5537a7ededd2ffe4de474cc615ef5be
以上就是Analyzing the Performance of an Anycast CDN（含论文谷歌翻译，人工补正）的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/34437.html
微信扫一扫 
支付宝扫一扫 
