说起 DNS 协议，相信大家都能说出来几句，不是很陌生。
它主要做两个功能：根据名称查到具体的地址;针对多个地址做负载均衡，而且可以在多个地址中选择一个距离我最近的地方，让我访问。
看起来这种方式无懈可击，但其实也有些问题。
传统 DNS 存在的问题
1. 域名缓存问题
客户端想要访问一个网址的时候，其实它首先是去看本地的缓存里面有没有这个地址，如果有就直接访问，如果没有才会去询问上级领导。
但是这个时候就会有个问题：比如在阿粉上高中的时候，我知道学校旁边有个超好吃的店，后来阿粉再想吃的时候，想都没想，直接去了那家店，结果发现人家关门了，当时阿粉的心情是非常失望。
同样，本地缓存也会出现这个问题，有的时候那个地址已经换掉了，但是因为本地缓存中有原来的地址，所以不会向上一级询问，将你导向原来的地址，结果就是访问不到界面，由此带来的用户体验不是很好。
还有个问题：假设我在北京海淀区，淘宝的应用因为某种原因没有在海淀区设置数据中心，然后我访问的时候，一直都是将我的访问请求发送到朝阳区。后来呢，淘宝在海淀区增加了数据中心，但是当我访问的时候，本地缓存依旧会将我的请求，导向到朝阳区那边，这样造成的结果就是：
对于客户来说，让他绕远路了。明明一个区域就可以解决的事情，偏偏要跨区域。就像明明在这里可以买到东西，偏偏让你跑到另外的地方去买，你开心嘛?
对于商家来说，也就是淘宝，我设置了新的数据中心，结果呢，客户的请求没能到这里，那我还费钱费力的去做这件事干嘛?又没有提高用户的体验，对不对。
2. 出口 NAT 问题
在网关那里，很多机房都会在出口配置 NAT ( Network Address Translation )，即：网络地址转换。
也就是说，从这个网关出去的包，都会换成新的 IP 地址，当请求返回的时候，在网关这里，再将 IP 地址转换回去，这样造成的结果就是，权威的 DNS 服务器，没办法通过这个地址，来判断用户到底是来自哪个运营商，而且极有可能因为误判运营商，导致跨运营商访问，从而导致网速极慢。
3. 解析延迟问题
DNS 的查询过程，需要递归遍历多个 DNS 服务器，才能得到最终的解析结果，这会带来一定的时延，甚至是解析超时。
HTTPDNS 的工作模式
DNS 解析有很多问题，那怎么办呢?再回到最初的起点：直接 IP 地址?显然不合适啊。
这就引出了 HTTPDNS 。说白了就是，它不走传统的 DNS 解析，而是走自己搭建基于 HTTP 协议的 DNS 服务器集群。这些集群分布在多个地点，当客户端需要 DNS 解析的时候，直接通过 HTTP 协议进行请求这个服务器集群，就可以得到最近的地址。这样做就相当于每个客户端都是基于 HTTP 协议的，自己实现自己的域名解析，自己做一个自己专属的地址簿，而不是使用统一的地址簿。
但是默认的域名解析都是走 DNS ，所以如果想要使用 HTTPDNS 的话，就需要绕过默认的 DNS 路径，这样就不能使用默认的客户端。
使用 HTTPDNS 的，一般都是手机应用，所以只需要在手机端嵌入支持 HTTPDNS 的客户端 SDK 就 OK 了。这样就可以通过自己的 HTTPDNS 服务器和相关的 SDK ，实现了从依赖别人，到自己上网查询，自己想去哪儿去哪儿，想干什么干什么，岂不是快哉~
HTTPDNS 工作模式具体可以描述如下：当手机要访问一个地址的时候，我会先看本地缓存里面有没有，如果有就直接访问，这个缓存是手机应用自己做的，至于如何更新，何时更新，那是手机应用的客户端的事情;如果没有的话呢，就需要请求 HTTPDNS 服务器，在本地 HTTPDNS 服务器的 IP 列表中，选择一个发出 HTTP 的请求，会返回一个要访问的网站的 IP 列表。因为是直接的 HTTP 通信，所以 HTTPDNS 服务器能够准确知道这些信息，所以可以做到精准的全局负载均衡。
写到这里，这篇文章想要表达的是两点：
传统的 DNS 有很多问题:比如域名缓存问题，出口 NAT 问题，解析延迟问题
为了解决上述问题， HTTPDNS 通过客户端 SDK 和服务端，通过 HTTP 的形式，直接调用解析 DNS 的方式，绕过了传统的 DNS 的这些缺点，从而实现了智能的调度。
