网络协议-HTTPDNS协议

DNS 有两个功能，第一个是根据名称查找对应的地址，另一个是可以针对多个地址负载均衡，能在多个地址中找一个离你最近的地方访问。

但是这个地址簿也会给你指错路，明明你要找的饭店就在眼前，它却给你推荐到五公里以外。

传统DNS 存在哪些问题？

1. 域名缓存问题

缓存的域名信息有可能失效了

2. 域名转发问题

如果A运营商的客户请求一个域名，正常情况下A运营商会自己请求权威DNS 服务器。但也会有这样的情况，A运营商的DNS 偷懒，它转给B 运营商的DNS，B 运营商的DNS 去请求权威NDS 服务器时，会误以为这个客户是运营商B区域的，所以返回的IP 地址是运营商B区域的地址。

3. 出口NAT问题

网络包在网关出口的时候，通过NAT（网络地址转换）将从这个网关出去的包换成新的IP地址。当然请求返回的时候，这个网关还会将IP 地址转换回去，这对于访问是没有问题的。但对DNS 就有问题了。

因为一旦做了网络地址的转换，权威DNS 服务器就没法通过这个地址来判断客户端到底来自哪个运营商。

4. 域名更新问题

如果像百度这样的应用，当它的一个机房出了问题，这时需要修改权威DNS，将域名指向新的IP地址，但是如果更新太慢，那很多用户都会出现访问异常。

5. 解析延迟问题

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

HTTPDNS 的工作模式

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

HTTPDNS 相当于每个客户端，都有自己的域名解析。自己做一个自己的地址簿，而不使用统一的地址簿。

解析HTTPDNS的工作模式

客户端有SDK，

HTTPDNS服务器，

本地缓存DNS 解析的结果，

HTTPDNS 的缓存设计

关键在于缓存没办法及时更新。

HTTPDNS 在解析的过程中，不像老DNS 协议那样递归调用一圈，一个HTTP的请求就能搞定，要实时更新的时候，马上就能起作用。

HTTPDNS 的缓存设计为三层，分为：客户端、缓存、数据源三层。这和通常的应用架构也比较像，分为：应用、缓存、服务端。

只要有缓存模式，就存在缓存过期、更新、不一致的问题，解决思路也是很像的。

同步更新的优点是实时性好，缺点是多个请求同时发现过期时，同时请求HTTPDNS 多次，这是一种浪费。

异步更新的优点是，可将多个请求发送合并成一个HTTPDNS 的请求，减少HTTPDNS 的压力。

异步的缺点也很明显，就是不能及时更新缓存。这个问题可以用数据预热或者 预加载解决。

Refresh-Ahead 机制，业务只访问缓存，当过期的时候定期刷新。

HTTPDNS的调度设计

由于客户端嵌入了SDK，因而就不会因为本地DNS的各种缓存、转发、NAT、让权威DNS服务器误会客户端所在的位置和运营商，而可以拿到第一手资料。

HTTPDNS服务端要权衡，客户端所在的位置，请求时间、服务器压力，网络状况等，进行综合选择，当有一个节点宕机或者性能下降要及时切换。

在服务器端，应用可以通过调用HTTPDNS 的管理接口，配置不同的服务质量的优先级、权重。HTTPDNS会根据这些策略综合地理位置和路线状况算出一个排序，优先访问那些优质的、延时低的IP地址。

客户端可以根据不同的移动网络运营商WIFI 的SSID 来分维度缓存。不同的运营商或者WIFI解析出来的结果会不同。

小结

传统的DNS有很多问题，比如：解析慢、更新不及时。因为缓存、转发、NAT等问题将客户端的位置和运营商判断错误。
HTTPDNS 通过客户端SDK 和服务端，通过HTTP协议直接调用解析DNS 的方式，绕过了传统的DNS 的这些缺点，实现了智能调度。