但凡使用域名来给用户提供服务的互联网企业，都或多或少地无法避免在有中国特色的互联网环境中遭遇到各种域名被缓存、用户跨网访问缓慢等问题。
问题
16年10月，为了解决web页面被劫持后展示非应用广告，同时支持iOS的https规划，https服务上线。11月湖南的用户大面积出现无法访问的情况。客户端的日志提示：‘connection close by peer’,’ssl handshake aborted: I/O error during system call’。
在用户帮助下，发现http请求正常，基于ip的https请求正常，基于域名的https请求异常。而部分用户投诉运营商后，维护人员进行的操作是换了一个dns解析地址，访问就可以正常了。可以猜测是部分运营商的localDNS只缓存了80端口的http的域名解析结果，对于443端口的https无法正常解析。出现这种情况会有比较多的原因，比如运营商为了减少网间结算，或者推送广告。缓存服务器的运维水平差异也会导致类似的结果。
国内运营商LocalDNS造成的用户访问异常可以归为下三类：
域名缓存。
就是LocalDNS缓存了域名的解析结果，不向权威DNS发起递归。解析转发。
指运营商自身不进行域名递归解析，而是把域名解析请求转发到其它运营商的递归DNS上的行为。
同样也是运营商为了节省自己成本的举动。LocalDNS递归出口NAT
LocalDNS递归出口NAT指的是运营商的LocalDNS按照标准的DNS协议进行递归，但是因为在网络上存在多出口且配置了目标路由NAT，结果导致LocalDNS最终进行递归解析的时候的出口IP就有概率不为本网的IP地址。
对于类似的问题，普遍的解决方法有如下几种：
实时监控+商务推动
我们尝试了投诉工信部，联系湖南运营商，均石沉大海。若是有反馈，可想也是周期非常长。绕过自动分配DNS，使用114dns或Google public DNS
114dns是国内最大的中立缓存DNS，而Google又是秉承不作恶理念的互联网工程帝国巨鳄。但是问题来了：
（1）如何在用户侧构造域名请求：对于PC端的客户端来说，构造一个标准的DNS请求包并不算什么难事。但在移动端要向一个指定的LocalDNS上发送标准的DNS请求包，而且要兼容各种iOS和android的版本的话，技术上是可行的，只是兼容的成本会很高。
（2）推动用户修改配置极高：如果要推动用户手动修改PC的DNS配置的话，在PC端和手机客户端的WiFI下面还算勉强可行。但是要用户修改在移动互联网环境下的DNS配置，其难度不言而喻。完全抛弃域名，自建connectcenter进行流量调度
这是在用户量比较大，有较多网络资源情况下进行的工作。如果要采用这种方案，首先就得要拿到一份准确的IP地址库来判断用户的归属，然后再制定个协议搭个connect center来做调度，然后再对接入层做调度改造。这种方案和2种方案一样，不是不能做，只是成本会比较高。
分析
在跟用户沟通的过程中，发现主要的互联网比如百度、淘宝的https服务都是可以正常使用的。除了大厂对于资源解析的影响，是否也有其他的技术方案可以解决这样的弱联通问题。12月阿里云的拜访给我们建议了httpdns方案。
HttpDNS可以说是为移动客户端量身定做的基于Http协议和域名解析的流量调度解决方案，专治LocalDNS解析异常以及流量调度不准。
HttpDNS的原理非常简单，主要有两步：
客户端直接访问HttpDNS接口，获取业务在域名配置管理系统上配置的访问延迟最优的IP。（基于容灾考虑，还是保留次选使用运营商LocalDNS解析域名的方式）
客户端向获取到的IP后就向直接往此IP发送业务协议请求。以Http请求为例，通过在header中指定host字段，向HttpDNS返回的IP发送标准的Http请求即可。
HttpDNS优势：
从原理上来讲，HttpDNS只是将域名解析的协议由DNS协议换成了Http协议，并不复杂。但是这一微小的转换，却带来了无数的收益：
根治域名解析异常：由于绕过了运营商的LocalDNS，用户解析域名的请求通过Http协议直接透传到HttpDNS服务器IP上，用户在客户端的域名解析请求将不会遭受到域名解析异常的困扰。
调度精准：HttpDNS能直接获取到用户IP，通过结合自有专利技术生成的IP地址库以及测速系统，可以保证将用户引导的访问最快的IDC节点上。
实现成本低廉：接入HttpDNS的业务仅需要对客户端接入层做少量改造，无需用户手机进行root或越狱；而且由于Http协议请求构造非常简单，兼容各版本的移动操作系统更不成问题；另外HttpDNS的后端配置完全复用现有权威DNS配置，管理成本也非常低。总而言之，就是以最小的改造成本，解决了业务遭受域名解析异常的问题，并满足业务精确流量调度的需求。
扩展性强：HttpDNS提供可靠的域名解析服务，业务可将自有调度逻辑与HttpDNS返回结果结合，实现更精细化的流量调度。比如指定版本的客户端连接请求的IP地址，指定网络类型的用户连接指定的IP地址等。
新的问题产生了，用户将首选的域名解析方式切换到了HttpDNS，那么HttpDNS的高可用又是如何保证的呢？另外不同运营商的用户访问到同一个HttpDNS的服务IP，用户的访问延迟如何保证？以最早（2013年）提出httpdns方案的腾讯为例。为了保证高可用及提升用户体验，HttpDNS通过接入了腾讯公网交换平台的BGP Anycast网络，与全国多个主流运营商建立了BGP互联，保证了这些运营商的用户能够快速地访问到HttpDNS服务；另外HttpDNS在多个数据中心进行了部署，任意一个节点发生故障时均能无缝切换到备份节点，保证用户解析正常。
方案
有了成熟方案的借鉴，出于成本控制的考虑，我们采用了简化版的httpdns服务。
目前两端已经在线上全面使用了，后续进一步观察效果和优化。
服务器：
没有过多的网络资源，不需要流量调度，出口仅有一个，下发的ip也只有一个。提供httpdns的服务由原出口服务提供，我们需要保证这个ip上服务的永久可用。客户端
仍然是可用性的保证，目前同样采用了简化版的处理方式，启动时获取ip，如失败使用localDNS解析。
后续会向完整的策略演进。
A、Failed over策略 为了保证在最坏的情况下客户端域名解析依然不受影响。 (1) 第一步发起域名查询请求 (2) 如果查询返回的结果不是一个IP地址（结果为空、结果非IP、连接超时等），则通过本地LocalDNS进行域名解析。超时时间建议为5s。 B、缓存策略 移动互联网用户的网络环境比较复杂，为了尽可能地减少由于域名解析导致的延迟，在本地进行缓存。缓存规则如下： (1) 缓存时间：缓存时间建议采用查询得到域名TTL。在客户端向D+发起域名解析请求时，在请求的参数上带上ttl=1参数，如：http://119.29.29.29/d?dn=www.dnspod.cn&ttl=1则D+在返回结果时会带上TTL（这个TTL是递归服务器缓存的TTL） (2) 缓存更新： 缓存更新应在以下两种情形下进行： i. 用户网络状态发生变化时： 移动互联网的用户的网络状态由3G切Wi-Fi，Wi-Fi切3G的情况下，其接入点的网络归属可能发生变化。所以用户的网络状态发生变化时，需要重新向D+发起域名解析请求，以获得用户当前网络归属下的最优指向。 ii. 缓存过期时： 当域名解析的结果缓存时间到期时，客户端应该向D+重新发起域名解析请求以获取最新的域名对应的IP。为了减少用户在缓存过期后重新进行域名解析时的等待时间，建议在75%TTL时就开始进行域名解析。如本地缓存的TTL为600s，那么在第600*0.75=450s时刻,客户端就应该进行域名解析。 除了以上几点建议外，减少域名解析的次数也能有效的减少网络交互，提升用户访问体验。建议在业务允许的情况下，尽量减少域名的数量。如需区分不同的资源，建议通过url来进行区分。 C. 如果客户端的业务是与host绑定的，比如是绑定了host的http服务或者是cdn的服务，那么在用返回的IP替换掉URL中的域名以后，还需要指定下Http头的Host字段。以curl为例，假设你要访问www.abc.com，通过D+解析出来的IP为192.168.0.111，那么通过这个方式来调用即可： curl -H "Host:www.abc.com" http://192.168.0.111/aaa.txt
