【网易云信】DNS 调度原理解析

DNS 简介

DNS,现代互联网发展最不可或缺的服务之一,咱们从访问网页到发送电子邮件,无时不刻都使用着DNS为咱们提供的服务。你们都知道,DNS的核心工做就是将域名翻译成计算机IP地址,一个完整的DNS解析过程以下:git

图片描述

一、用户发出 www.sina.com.cn 的域名解析请求,首先查询本地缓存中是否有该域名对应的IP,若是有直接返回,不然,进行第二步;
二、本地缓存服务器向根域名服务器发起 DNS 查询请求,根域名服务器会发送一个回复说,.cn 的域名我已经委派给.cn 这台域名服务器了,给你这台服务器的地址,你去哪里查吧。
三、本地缓存服务器收到这个答复后又向.cn 域名服务器查询,如此迭代,最后.sina.com.cn 的 DNS 服务器会收到这个请求,返回域名的实际IP给本地缓存服务器。
四、本地缓存服务器收到这个答复后,会将这条记录返回给客户端,同时将该记录写入本身的缓存中,以便备查。github

DNS 调度原理

如今,大部分应用和业务都采用域名做为服务的入口,所以用 DNS 来负载均衡和区域调度是很是广泛的作法,网易云也有着一套基于 DNS 的调度系统。某些用户在进行直播推流时用的并非网易云的直播 SDK,而是一些第三方的推流软件,如obs,这样就不能使用咱们的 GSLB 全局调度服务器来调度。对于这些用户,咱们使用 DNS 调度的方式,对不一样地域的请求返回不一样解析结果,将请求调度到离用户最近的服务器节点,从而减小延迟访问。web

图片描述

咋一看,DNS 调度这么简单方便,那为何不让全部的用户都走 DNS 调度呢?想知道缘由?来,咱们继续讲。算法

  • 地理位置调度不许确

在 DNS 解析过程当中,与权威服务器通讯的只有 DNS 缓存服务器,因此权威服务器只能根据 DNS 缓存服务器的IP来进行调度。所以 DNS 调度有一个前提:假定用户使用的缓存DNS与用户自己在同个网络内,即至少在同一个 AS(自治域)内,在该前提下,DNS 的解析才是准确的。一般状况下,用户使用 ISP 提供的本地缓存(简称 local DNS),local DNS 通常与用户在同个网络内,这时候 DNS 调度是有效的。
但近些年,很多互联网厂商推广基于 BGP Anycast 的公共 DNS (Public DNS),而这些
Anycaset IP 的节点通常是远少于各个ISP的节点,例如可能广州电信用户使用了某公共 DNS,但该公共 DNS 里用户最近的是上海电信节点,甚至更极端的如 Google DNS 8.8.8.8,在中国大陆没有节点(最近的是台湾)。而不幸的是国内有很多用户使用了 Google DNS,这其实下降了他们的网络访问体验。总的来讲,使用公共 DNS,实际上破坏了上文的前提,致使 DNS 区域调度失效,用户觉得获得了更快更安全的 DNS 解析,但实际获得了错误的解析,增长了网络访问延迟。
传统 DNS 协议的区域调度过程示例以下图,假定某业务以 foo.163.com 对外提供服务,在北京和东京各有一个节点,业务指望国内大陆的用户访问北京节点,而非大陆用户则访问东京节点。由于权威是根据 DNS 缓存来决定返回的结果,因此当用户使用不用的 DNS 缓存时,可能会解析到不一样的结果。缓存

图片描述

2011 年,Google 为首的几家公司在提出了一个 DNS 的扩展方案 edns-client-subnet (如下简称 ECS),该扩展方案的核心思想是经过在 DNS 请求报文里加入原始请求的 IP(即 client 的 IP),使得权威能根据该信息返回正确的结果。目前,该方案仍处于草案阶段。该方案很好地解决了上述提到的 remote DNS 致使解析不许确的问题,但也带了一些问题:安全

  • 至少须要 cache 和权威都支持,才能完成完整的 ECS 解析
  • ECS 给 cache 增长了很大的缓存压力,由于理论上可能须要为每一个IP段分配空间去缓存解析结果

图片描述

  • 规则变动生效时间不肯定

当缓存服务器向权威服务器查询获得记录以后,会将其缓存起来,在缓存有效期内,若是收到相同记录的查询,缓存服务器会直接返回给客户端,而不须要再次向权威查询,当有效期事后,缓存则是须要再次发起查询。这个缓存有效期便是 TTL。
虽然 DNS 的缓存机制在大多数状况下缩短了客户端的记录解析时间,但缓存也意味着生效同步的延迟。当权威服务器的记录变动时,须要等待一段时间才能让全部客户端能解析到新的结果,由于极可能缓存服务器还缓存着旧的记录。
咱们将权威的记录变动到全网生效这个过程称为 propagation,它的时间是不肯定的,理论上的最大值便是 TTL 的值,对于记录变动或删除,这个时间是记录本来的 TTL,对于记录新增则是域的 nTTL 值。
若是一个域名记录本来的 TTL 是 18000,能够认为,变动该记录理论上须要等待 5 个小时才能保证记录能生效到全网。假设该域名的业务方但愿缩短切换的时间,正确的作法是,至少提早5个小时修改记录,仅改小 TTL,例如改成5分钟,等待该变动同步到全网以后,再进行修改指向的操做,确认无误再将 TTL 修改成本来的值。
虽然 DNS 协议标准里建议缓存服务器应该记住或者缩短 TTL 的值,但实际上,有一些DNS缓存会修改权威服务器的 TTL,将其变大,这在国内几大运营商中是很常见的。例如,某域记录的 TTL 值实际上设置为 60,但在运营商的 DNS 缓存上,却变成 600 或者更大的值,甚至还有一些 DNS 缓存是不遵循 TTL 机制。这些都会影响域名的实际生效时间。服务器

  • 高可用

为避免受 DNS 缓存的影响,须要保证 DNS 中 A 记录的 IP 节点高可用性。对此,网易云
DNS 调度系统采用的方案是在同一区域的多台直播服务器节点之间作负载均衡,对外只暴露一个虚 IP,这样,即便某台服务器宕机,负载均衡能迅速感知到,排除故障节点,而对 DNS 而言,由于虚 IP 不变而不受影响。微信

图片描述

总结

如今,你们应该知道了 DNS 调度的利弊了吧,因此推荐你们仍是用咱们网易云的直播 SDK 哦,接入更加精准的调度系统,保证用户体验。若是您说您就是喜欢用第三方的推流软件,那请不要使用公共 DNS 服务已避免调度结果不许确。网络


随着音频处理和压缩技术的不断发展,效果更好、适用范围更广、性能更高的算法和新的技术必将不断涌现,若是你有好的技术或者分享,欢迎关注网易 MC 官方博客以及微信公众号:负载均衡

关注更多技术干货内容: 网易云信博客
欢迎关注 网易云信 GitHub
欢迎关注 网易云信官网

官网微信公众号:
图片描述

相关文章
相关标签/搜索