一、常规DNS调度策略原理
以CDN系统为例(其他业务系统大多采用类似的策略),来说明一下多地域部署服务如何实现用户访问请求调度的。
Step 1:客户端(假设IP地址为IP1)向Local DNS(假设IP地址为IP2)发出域名解析请求(假设请求的域名为www.taobao.com )
Step 2:Local DNS代理客户端向权威服务器发起域名解析请求
Step 3:权威服务器根据域名( www.taobao.com )和IP2(对应的地域和ISP)进行调度并返回对应的解析结果。
Step 4: 客户端根据调度返回的IP发起业务访问请求。
二、调度精确性问题
2.1 问题描述
从上面的调度过程可以看出,业务系统会根据客户端的local dns IP来判断客户所处地域和运营商,并根据该地域和运营商来调度到就近的服务节点。
可以看出,当客户的Local DNS与客户的地域和运营商不匹配时,此时按照Local DNS来调度就会出现调度不精确的问题。
下面看几个来自客户的反馈(探测结果来自AliCDN昆仑探测工具):
探测的客户端IP和Local DNS IP以及对应的地域,运营商如下所示:
客户端IP | 220.249.84.** |
220.249.84.** |
客户端归属 | 武汉联通 | 武汉联通 |
Local DNS IP |
183.61.13.** |
222.73.134.** |
Local DNS 归属 | 珠海电信 | 上海电信 |
很容易看出,Local DNS地域和运营商与客户端都不匹配,此时按照Local DNS IP调度会对用户体验造成非常大的影响(国内跨运营商的访问延迟和带宽都存在非常大的问题,相信大家有深刻体验)。
2.2 问题影响面
根据我们的经验,影响的客户端占比在3%-7%之间。
2.3 原因
无线场景下主要由于以下两个方面因素导致:
(1)国内三大运营商Local DNS布点不足且不均匀,大量流量集中在2000个以内的Local DNS上,大的Local DNS对应的流量超过5Gb
(2)很多手机(尤其是山寨机)Local DNS配置不准确
如果扩展到全网(含有线访问请求),还需要考虑一个因素:
(3)公共DNS(如google 8.8.8.8,阿里的223.5.5.5,223.6.6.6)导致调度系统无法识别Local DNS的具体位置。
三、解决办法
业界当前常见的解决思路都是通过获取客户端的IP来精确定位客户端地域和运营商,实现上,有三种方式:
(1)HTTPDNS
客户端通过HTTP请求向httpdns服务器发出域名解析请求,此时httpdns服务器可以拿到客户端的精确IP,并基于客户端IP进行调度。
(2)edns client subnet
通过dns包中加入客户端IP信息,使得DNS调度系统可以拿到客户端IP并进行调度。
(3)http 302跳转
当调度系统给出的调度结果不准确时,业务服务器仍然可以根据客户端IP来判断调度是否合理,并且在必要时通过302跳转来实现重定向进而实现精确调度。
三种方式的优缺点对比如下:
客户端修改 | Local DNS修改 | 权威DNS修改 | 系统开销 | 使用范围 | |
HTTPDNS | 有 | 无 | 低 | 最广 | |
edns client subnet | 无 | 需支持edns client subnet | 需支持edns client subnet |
低 | 中等 |
http 302 | 有(需支持302跳转) | 无 | 高 | 最差 |
HTTPDNS综合来看是最优的解决方案,当前阿里云已经推出了
HTTPDNS商业化产品。