什么是httpdns

在移动客户端中加入一个域名解析模块，客户端通过 HTTP 的方式向网站的流量调度服务器请求 IP，流量调度服务器会根据用户所在位置给用户一个最优的IP。客户端在获取IP后直接用此IP来访问所需站点资源。网站使用 HttpDNS 面临较高的成本，我们可以选择国内公有云厂商比如又拍云（upyun.com）等的 HttpDNS 调度功能，可以有效防止 DNS 劫持。

DNS域名解析就是将我们熟知的域名转换为ip的服务。如将 www.baidu.com 转换为 61.135.169.125 这样的ip地址。

想要记住域名比较容易，但是想要记住ip就不容易了，由此可见dns服务是多么的重要。

dns不仅仅可以对域名解析出ip。它还能根据客户端的所在地理位置解析出对客户端最优质的ip。这个怎么理解呢，比如我在深圳访问 baidu.com ，那么dns服务器会将解析成就近的机房的ip地址，而不会让我去访问位于北京的机房。

这就是 全局负载均衡（GSLB，Global Server Load Balance） 。因为，为了保证服务应用的高可用性，往往会部署多个机房，每个地方都会有自己的IP地址。当用户访问某个域名的时候，这些IP地址可以轮询这些机房。另外尽可能希望，北京的用户访问北京的机房，上海的用户访问上海的机房。这样客户体验就会非常好，访问速度也会非常快。

看似十分完美的 GSLB 和 SLB。实则有很多的问题。

既然传统 DNS 问题这么多，那怎么解决呢？

有，那就是HTTPDNS

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

而使用HTTPDNS的往往是手机应用，需要在手机端嵌入支持HTTPDNS的客户端SDK。

在客户端的SDK里动态请求服务端，获取HTTPDNS的服务器列表。缓存到本地，随着不断域名解析，SDK也会在本地缓存DNS域名解析的结果。

当应用要访问一个地址时，先看下是否有缓存（这个缓存时手机应用自己做的，不走运营商的缓存，所以如何更新，合适更新全在自己的掌控之中）如果本地没有缓存，那就请求 HTTPDNS的服务器吧。而手机客户端当然知道收集在哪个运营商，在哪个地址，由于是直接的HTTP通信，HTTPDNS也能更好的返回结果信息，更好的做到全局负载均衡。

在 客户端 ，可以知道确切的地理位置信息，运营商。HTTPDNS可以根据这些信息返回最佳的服务节点。

如果有多个节点，还会考虑错误率，请求时间，服务器压力，网络状况等，进行综合选择。而非仅仅考虑地理位置。当有一个节点宕机或者性能下降时，尽快切换。

在 服务端 ，服务端可以配置不同的服务质量的权重，优先级，对客户端上报的错误率，请求时间，请求质量等数据，统计，分析，聚合，以此查看不同的IP的服务质量。

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

2016.4.1日，Google正式启用了 DNS-Over-HTTPS 域名安全查询服务

该服务支持以下参数：

edns_client_subnet 这里有个坑，比如你有海外需求，需要将 域名cname到海外著名的cdn厂商，比如fastly，akamai等，你需要确定cdn厂商认不认edns扩展，比如 akamai 的权威是不认 阿里httpdns ，腾讯httpdns 的edns 扩展的，也就是你用 ali，tencent 的httpdns 解析akamai 的是会调度错误的。

怎么测试权威是否支持我们的edns 扩展呢？

以 www.qq.com 为例

找到域名的权威。

对权威发起 subnet 查询, www.qq.com 被 cname 到 腾讯云上去了，看来权威在腾讯云上

看看是否有解析结果。

参考 1. 刘超老师的极客时间

2. https://blog.csdn.net/windyf2013/article/details/79727348

有用户反应产品偶然会出现『未能找到使用指定主机的服务器』问题，应该是 DNS 没有正确解析。从监控记录中并没有发现什么问题，各地的监测点的结果都很正常，那就应该是用户所处网络环境出了问题。

为了尽量提高产品可用性，进行了 HTTP DNS 的改造。

普通的网络请求，系统自动通过 DNS Server 将目标域名解析成 IP 地址，然后向这个 IP 地址发送请求完成数据交互。这个解析的过程对于 APP 来说是不可见的。

HTTP DNS 则是 APP 主动向 HTTP DNS Server 发送解析请求，Server 返回目标域名对应的 IP 地址，然后 APP 直接向目标地址发送请求，绕开了系统解析的这个环节，避免了用户所处环境带来的干扰。

当然 HTTP DNS Server 也是通过 IP 地址直接访问的，比如 DNSPod 免费版的 119.29.29.29，还有其他厂商可以自己寻找。

根据改动范围是否设计后端（包括运维）有两种方法

这种改造方案非常简单，后端 Web Server 将 IP 地址直接绑定到目标站点，APP 在发起请求前，直接将所有 URL 中自己域名的部分换为通过 HTTP DNS 获得目标 IP 即可。

当然如果后端有针对域名的逻辑也需要处理下，比如防盗链用的 Referer 校验等。

另外有的第三方库（比如支付宝）需要 APP 传入 Server 回调地址。这种是没必要改的，毕竟请求来自 IDC 机房等网络环境很好的场合。不过一定要改的话，这种地址可能在第三方平台上有绑定审核，实际动手前请提前准备审核。

不同公司合作开发或者一台 Server 托管了若干站点的情况，只能 APP 自己想办法了。这种稍微麻烦点，针对不同用途的 URL 需要做不同的处理。

iOS/Android 都有现成的第三方库可供使用，GitHub 上有新浪和七牛的项目

另外七牛项目的分别发布到了 CocoaPods 和 maven 上更易使用，所以推荐七牛。

---