DNS与HTTPDNS

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缺点，实现智能调度。