DNS与HTTPDNS

https://www.cnblogs.com/jimmyhe/p/11279762.html

DNS服务器

• 根DNS服务器：返回顶级域DNS服务器的IP地址

• 顶级域DNS服务器：返回权威DNS服务器的IP地址

• 权威DNS服务器：返回相应主机的IP地址

  流程图：

负载均衡

• 内部负载均衡：可以配置域名，每次返回不同的ip
• 全局负载均衡：高可用，如果某个服务器挂了，在DNS里直接删除对应ip，埃博征访问。

示例：DNS访问数据中心中对象存储上的静态资源。

假设全国有多个数据中心，托管在多个运营商，每个数据中心三个可用区。对象存储通过跨可用区部署，实现高可用性。在每个数据中心中，都至少部署两个内部负载均衡器，内部负载均衡器后面对接多个对象存储的前置服务器。

1. 当一个客户端要访问object.yourcompany.com时，需要将域名转为ip，所以请求本地DNS解析器。
2. 本地DNS解析器查看是否有本地缓存这个记录，如果有则直接使用
3. 如果没有，请求本地的DNS服务器。
4. 本地的DNS服务器一般部署在你的数据中心或所在运营商的网络中，本地DNS服务器需要查看本地是否有缓存，如果有则返回。
5. 若无，本地DNS需要递归的从根DNS服务器，查到顶级域名服务器，最终查到权威DNS服务器，返回给本地DNS服务器。

对于不需要做全局负载均衡的简单应用来讲，权威DNS服务器可以直接将object.yourcompany.com域名解析为一个或多个ip地址，服务端可以通过多个ip地址，进行简单的轮询，实现简单的负载均衡。

• 全局负载均衡器（GSLB, Global Server Load Balance），在DNS服务器中，一般通过配置cname的方式，给object.yourcompany.com起一个别名，然后告诉本地DNS服务器，让他请求GSLB解析这个域名，在解析这个过程中，通过自己的策略实现负载均衡。

• GSLB可以分运营商和地域，第一层GSLB，通过查看请求他的本地DNS服务器所在的运营商，就知道用户的运营商，通过起别名，告诉本地DNS服务器去请求第二层的GSLB。

  第二层GSLB查看请求他的本地DNS服务器的地址，知道了用户的地理位置，将距离用户位置比较近的region里，六个内部负载均衡的地址，返回给DNS服务器。

  本地DNS服务器将结果返回给本地DNS解析器，然后解析器返回给客户端

  客户端得到了6个ip地址，可以通过负载均衡的方式，随机或者轮询选择一个可用区进行访问。

DNS存在的问题

1. 域名缓存问题

   本地做一个缓存，直接返回缓存数据。可能会导致全局负载均衡失败，因为上次进行的缓存，不一定是这次离客户最近的地方，可能会绕远路。

2. 域名转发问题

   如果是A运营商将解析的请求转发给B运营商，B去权威DNS服务器查询的话，权威服务器会认为你是B运营商的，就返回了B运营商的网站地址，结果每次都会夸运营商。

3. 出口NAT问题

   做了网络地址转化后，权威的DNS服务器，没法通过地址来判断客户到底是哪个运营商，极有可能误判运营商，导致跨运营商访问。

4. 域名更新问题

   本地DNS服务器是由不同地区，不同运营商独立部署的，对域名解析缓存的处理上，有区别，有的会偷懒忽略解析结果TTL的时间限制，导致服务器没有更新新的ip而是指向旧的ip。

5. 解析延迟

   DNS的查询过程需要递归遍历多个DNS服务器，才能获得最终结果。可能会带来一定的延时。

HTTPDNS工作模式

定义：不走传统的DNS解析，而是自己搭建基于HTTP协议的DNS服务器集群，分布在多个地点和多个运营商，当客户端需要DNS解析的时候，直接通过HTTP协议进行请求这个服务器集群，获得就近的地址。

1. 在客户端的SDK里动态请求服务端，获取HTTPDNS服务器的ip列表，缓存到本地。SDK也会在本地缓存DNS域名解析的结果。这个缓存和本地DNS的缓存不一样，不是整个运营商统一做的，而是手机应用来做的，如何更新，何时更新。

2. 如果本地无，就需要请求HTTPDNS的服务器，在本地的ip列表中，选择一个发出HTTP请求，返回一个要访问的网站的ip列表。手机客户端知道手机坐在的运营商，可以精确做到全局负载均衡。

• HTTPDNS的缓存设计

  解析的过程不需要本地DNS服务递归调用一大圈，一个HTTP请求直接搞定，本地也有缓存，过期时间，更新时间都可以自己控制。

  缓存设计模式三层：客户端，缓存，数据源

  • 对于应用架构，就是应用，缓存，数据库。tomcat，redis，mysql
  • 对于HTTPDNS来说，就是手机客户端，dns缓存，httpdns服务器

  例如dns缓存在内存中，也可以持久化到存储上，app重启后，就可以尽快的从存储中加载上次积累的解析结果。

  sdk中的缓存会严格按照缓存过期时间，如果没有命中，或已经过期，则不允许使用过期记录，会发起一次解析，保障记录是新的。

  解析可以是同步或异步的。

  同步更新的优点是实时性好，缺点是如果有多个请求都发现过期的时候，会同时请求HTTPDNS，浪费资源。对应到应用架构中缓存的Cache-Aside机制，先读缓存，不命中读数据库，同时写入到缓存。

  异步的优点是多个请求都过期的情况可以合并为一个，同时可以在即将过期的时候，创建一个任务进行预加载，防止过期之后再刷新成为预加载。缺点是当请求拿到过期数据，如果可以请求就没问题，如果不能请求，则失败，等下次缓存更新后，再请求方能成功。

  对应于应用架构中缓存的Refresh-Ahead机制，即业务仅仅访问缓存，当过期就定期刷新。

• HTTPDNS调度设计

  客户端嵌入了SDK，在客户端HTTPDNS服务端可以根据手机的国家，省市地点，运营商，选择最佳的服务节点。

小结：

• 传统的DNS有解析慢，更新不及时，转发跨运营商，nat跨运营商等问题，影响了流量的调度。
• HTTPDNS通过客户端sdk和服务端，直接解析dns，绕过了传统dns缺点，实现智能调度。