浅谈AnyCast在CDN服务过程中的加成

MagicQ 11月前 949

一、前情提要

关于CDN是的概念可参考https://project-help.cn/thread-124.htm


二、CDN的调度

CDN的核心是由最近的节点覆盖用户,那最近是什么概念?举个栗子,A、B、C三个用户均在邯郸且A用户使用联通网络,B用户使用移动,C用户使用广电网络,同时邯郸有CDN边缘节点,那A、B、C用户在访问邯郸节点的时候就是最近的吗?不然。


2.1 智能DNS

讨论这个话题前,就需要牵连出智能DNS(GSLB的核心功能),所谓智能DNS就是根据用户IP提供不同的解析结果。

要想正确调度,前提是能够获取到用户的IP,常规处理办法是单纯的看LocalDNS是哪的,这样的判断方式简单粗暴,逻辑层少了很多东西,故障处理起来也比较简单。

But,LocalDNS的地址又不一定代表本网,栗子又来了:运营商I1的DNS配置成了Forward而非递归,Forward到运营商S2或者兄弟省I2的DNS上,这时候GSLB就会判断原本来自I1的用户是来自于S2,产生了“错误”调度。原因仅仅是因为GSLB看到的“用户IP”是I2。又或者说海南的用户用的是北京的DNS,同样会导致调度“错误”。

为了解决这种“错误”调度的问题,又引入了其他玩法:


2.2 302 redirect

HTTP Status Code的定义里,3xx代表跳转,具体请参考RFC2616,前面说到造成解析“错误”的根本原因是用户IP地址的判断,而TCP链接一般来说没有中间层的问题(其实是有的,就是代理,但是对于代理来说,所有流量均需要通过代理来穿透,换句话说对于Server端来说它才是Client,所以这时候调度正确的判断条件是是否与代理服务器位置最近)。

经过DNS调度后,Client request 被引到“最近的”边缘设备上,这时候这个边缘发现Client的IP地址本身跟我其他节点更近,遂返回302 redirect(不用301、307等Code的原因请参考RFC定义,这里提醒一下,此调度是临时动作,可能下一次就调度到其他设备上了)response,客户端被重新调度到正确的节点。

But,这种处理方式仅适合于大文件下载,如文件下载和视频,小文件(文本、图片等资源)也可以用302二次调度,但不会去那么做,原因在效率。众所周知,TCP的最大有效载荷为1446bytes(链路MTU为1500,即单数据包最大1500bytes几乎都成所有人默认的数值了,虽然说那个数字更大后可以获得更好的网络传输速度吧;以太头为14bytes;IP头为20bytes;TCP头大小是非固定值,一般最小为20bytes),本身302数据也需要发给Client,这时候配合上TCP窗口大小同时返回多个数据包,这时候就会出现用302再次调度比直接返回更耗时的效果,毕竟晚0.1s用户拿到资源就有流失客户的风险。


2.3 ECS(EDNS Client Subnet)

ECS是在DNS的的一个扩展功能,用来弥补GSLB无法准确获取用户实际来源而引入的,RFC - ECS,2016年由google和CDN鼻祖akamai主持制定相关标准。

在LocalDns向上层DNS需求解析结果的时候,可以携带在扩展信息里携带原始客户端的IP地址或IP段,上层DNS可通过其来判断用户位置而非LocalDns的IP地址。

但是,目前支持ECS的并没多少。。。


三、AnyCast

AnyCast即任播,传统行业里主要用的就是单播unicast,在IPTV等视频领域还有一个兄弟叫multicast,在局域网内还有一个兄弟叫broadcast。

差别如下:

单播 unicast 是1对1的,可以理解为私教,行为主体是要学习的人,学习的人自己找私教1对1授课

多播 multicast 是1对多的,可以理解为 教练,行为主体是要学习的人,教练一直在授课,学生具备选择权,可选择自己感兴趣的内容听,但无论什么时候来都是学的当然教练在授的内容。

广播 broadcast 也是1对多的,但是广播仅在局域网内有,可以理解为老师在班级上给学生授课,无论学生敢不敢兴趣,学生都会听到老师讲的内容。至于听到后学生理不理会就看学生自己了。

任播 anycast 也是1对多的,跟其他几个兄弟相比,任播有点任性,类似吉野家这种连锁餐厅,你无论在北京还是上海都有它且菜品味道、价格都一样。

anycast的实现依靠的是BGP(边界网络路由协议),数据包在寻路的时候会参考路由跳数、优先级、负载等择优选择。

常见的使用anycast协议的场景就是DNS,如电信public dns 114.114.114.114 or google public dns 8.8.8.8等。

传统AnyCast应有场景为传输协议为UDP的场景,毕竟数据包的路由每次都是可变的,可能会发生TCP SYN报文由绿点收到了,但是接下来syn ack报文由黄点收到导致TCP建链失败。

Anycast-BM.svg

但UDP数据这种不可靠传输,数据包前后可以无关联性,才促使UDP在AnyCast的状态下有了更好的提成,可以无视解析结果从路由上到达最近的边缘设备,毕竟同样给在邯郸的两个人互相打招呼的数据包都有可能绕到上海来完成。

随着互联网的发展,大厂对缩短时间的要求可以说“丧心病狂”,开始尝试使用ANYCAST作为三层路由协议支撑TCP业务。随着网络设备的更新换代,更多的设备支持以 协议+sourceIP+DestIP 作为转发数据包的依据,造就了同一个TCP链里的数据包多次经过时不在出现每次路劲不相同的情况,具备了AnyCast协议支持TCP的条件,慢慢的一些人开始引入了AnyCast。

支持AnyCast的计算节点,时延低很多

支持AnyCast的跟不支持AnyCast的对比结果来看也是:

《数据占位。。。》


四、总结

在很多时候,有些技术看着可怕,但实际使用之后就会发现很有用、有效,有CDN选型需求的也可以多调研调研。HTTP2、QUIC、边缘计算在向你们招手。。。

最新回复 (0)
    • 运维开源项目互助社区—致敬开源
      2
        立即登录 立即注册 
返回