共计 3277 个字符，预计需要花费 9 分钟才能阅读完成。
dns 解析现状问题 1：暴利的 dns 劫持
要说为啥会呈现 httpdns（先不必管意思，前面解释），那么，首先要说一下，当初的 dns 解析，是不是有啥问题？
dns 能有啥问题呢，就是输出一个域名 xxx.com，dns 服务器递归获取 xxx.com 背地的 ip，看起来，人畜有害的技术。
然而，如果我就是负责保护某运营商的 dns 服务器的技术人员，手里很缺钱，我可能会想，是不是能够“科技向善”，搞点钱来画画？
比方，假如 xxx.com 网站很火，每天很多人拜访，那我能够这样，xxx.com 进行 dns 查问，原本应该返回的 ip 是 1.1.1.1，我呢，我给返回另一个我手里的服务器的 ip（2.2.2.2），那么，用户后续再拜访 xxx.com，就是拜访我手里的 2.2.2.2 了。我的 2.2.2.2 服务器，做个反向代理，把用户申请转发到 1.1.1.1，再把 1.1.1.1 的响应转回给用户，用户也不晓得它的流量曾经被劫持了，全得从我的 2.2.2.2 上过一道手，看起来还神不知鬼不觉。
我这时候想赚钱的话，齐全能够去找广告商谈单干了，谁给钱多，我就：转发 1.1.1.1 的响应给用户时，加点广告，用户只有关上 xxx.com，就会被强制弹广告，我呢，等着广告商给我送钱即可。
以上就是最简略的 dns 劫持的例子，大家看了后也不要感觉如同我能够，首先，你得进到运营商公司，把握相干服务器；其次，当初好多流量都是 https 域名了，https 防中间人篡改的性能还是很强的，所以，根本还是说，你劫持归劫持，你劫持了也不能改我流量，那你也很难加广告，所以还是能够防这种弹广告的。
我在百度搜了下 dns 劫持，发现这个行业还是真的很刑很赚钱，适宜各位喜提毕业礼包的程序员们再待业(https://xw.qq.com/cmsid/20211…)
dns 解析现状问题 2：调度不准
后面有篇文章，讲 gslb 的，提到过如下事件：
依赖运营商帮咱们做 dns 解析，不肯定很靠谱，比方咱们把 xxx.com 要解析到咱们在深圳和北京的两个机房，一般来说，是冀望能够依据用户所在的地区来返回就近的地址，如广东用户就返回 xxx.com 在深圳机房的地址，北京用户就给北京机房的地址。或者是 dns 运营商那边，也反对按用户的运营商路线来解析，
然而呢，总归来说，这个解析是把握在他人手里，他要是靠谱，那就没问题；他那边要是解析不靠谱，那就问题较大，比方广东用户给你个北京机房地址，你说用户是不是得卡死在你的网站上，体验就齐全不行。
httpdns 的定义
定义
dns 劫持，产生在 dns 解析过程中，一般来说走的是 udp 协定；dns 解析，无非就是要拿到 xxx.com 背地的 ip，那我是不是能够本人开发一个服务，对外提供 http 接口，接口的性能就是：接管一个参数，即待查问的域名，如 xxx.com；返回呢，就是 xxx.com 对应的 ip 或者 ip 列表或者 ip 列表再加点各个 ip 的负载状况（如有这个数据）。
api 申请参数
按理说咱们是要本人去开发这么一个 http 服务的，然而，当初的各大云厂商也做了这个性能，我就间接贴点他们的材料：
比方下面这个云厂商，对外提供的接口，就是 http://203.107.1.33/xx/d，其中，203.107.1.33 是一个公网 ip，是这个 httpdns 服务的对外 ip，参数呢，次要就是两个：host 和 ip，host 就是你要查的域名，ip 是客户端的 ip（如有，如果本身取不到本人的对外进口 ip，服务也会默认取 socket 中的 client ip，即客户端 ip），所以，这个接口就模仿了 dns 服务器的 dns 查问性能。
这边也有两个申请示例：
- 示例 1（默认起源 IP）：http://203.107.1.33/100000/d?…
- 示例 2（指定起源 IP）：http://203.107.1.33/100000/d?…
api 响应参数
在该云厂商的网站上，也介绍了响应体的格局：
{
"host":"www.xxx.com",
"ips":["140.205.140.234"],
"ipsv6":["2400:3200:1300:0:0:0:0:3e"],
"ttl":57,
"origin_ttl":120
}能够看到，ips 也是反对返回多个的。假如是咱们本人实现这个 api 呢，也和下面这个 api 差不多，ips 这边，可能能够多点想法，比方把每个 ip 的以后状态也返回给客户端，客户端就能够依照一些策略来，比方选一个负载最低的；
我看云厂商这边呢，都是只返回 ip，毕竟它不可能晓得咱们每个 ip 的更多信息；云厂商的做法，大略就是：
- 依据你的参数中的要查的域名，xxx.com，去 dns 零碎查问背地的实在 ip 地址，如查到 1.1.1.1（深圳）、2.2.2.2（北京）
- 依据客户端的 ip（申请参数中的 ip，如没传就从 socket 里取对端 ip）来判断该返回 xxx.com 在北京的 ip，还是深圳的 ip；另外，我看到云厂商也反对你本人写一段代码，让你自定义策略。
答疑解惑
重大缺点
只适宜有客户端的场景，能够看到，这个计划是须要先去查问 httpdns 服务，能力拿到实在的 ip；这就须要在客户端（安卓、ios、pc 端均可）编码实现。
B/ S 这种场景是没方法了，浏览器不反对先去 httpdns 查实在 ip，再发动拜访。
为啥 httpdns 服务对外间接裸露 ip
因为 httpdns 就是要解决 dns 劫持问题，总不能自己再套一层 dns 吧；另外，这个 ip 是有要求的，须要全国各地的用户拜访这个 ip 都要足够快，所以，这个 ip 所在服务器个别是要放在 BGP 机房，BGP 机房简略了解就是各大支流运营商，如挪动、电信、铁通、网通等等，都和这个机房直连，因而，各大运营商的用户拜访这个机房的服务器都很快。
具体我也不是很懂，能够这么了解，市面上很多 IDC 公司提供数据中心租用、服务器托管等服务，它手里的机房呢，也是有差别的，有的可能次要接了电信运营商，适宜北方用户拜访，南方用户拜访就很慢；有的就是适宜南方用户拜访；还有一些呢，就是同时接入了很多家运营商，各大运营商拜访这个机房都比拟快，即所谓 BGP 机房。
httpdns 服务如何保障高可用
httpdns 服务，像后面咱们看的那个云厂商，只有一个 ip？其实不是的，是在该云厂商的很多机房有部署，有多个 ip 的。
思考到服务 IP 防攻打之类的平安危险，为保障服务可用性，HTTPDNS 同时提供多个服务 IP，当某个服务 IP 在异常情况下不可用时，能够应用其它服务 IP 进行重试。上述文档中应用的
203.107.1.33是其中一个服务 IP。HTTPDNS 提供 Android SDK 和 iOS SDK，两个平台的 SDK 中曾经做了多 IP 轮转和出错重试的策略，通常状况下，倡议开发者间接集成 SDK 即可，不须要本人手动调用 HTTP API 接口。
httpdns 应用 http 协定明文传输，不平安？
那就应用 https，云厂商也是反对这么玩的，
HTTPS 服务 URL：
https://203.107.1.33/{account_id}/d
客户端最佳实际
客户端最好不要依赖这个机制，万一 httpdns 服务出问题了呢，那咱们的 app 不就齐全不能用了吗，此时能够降级为应用传统的 dns 计划，劫持就劫持吧，其实概率也没那么大（毕竟太刑了）；要是传统的 dns 计划还是有问题，客户端还能够预埋一些 ip，到时候就从预埋的 ip 里选一个去拜访，保障高可用。
云厂商提供了 sdk 的计划，也具体解说了一些细节问题，比方，通过 httpdns 拿到了某个 ip，为 1.1.1.1，此时，就向 1.1.1.1 发动了 https 业务申请（假如咱们的后端服务器都是应用 https），此时就会遇到个问题：https 个别是只反对域名拜访（因为 https 服务器会返回证书给客户的，证书都是颁发给某个域名的，没据说颁发给某个 ip 的），此时用 ip 去拜访 https 服务器，就会有一点问题。
云厂商毕竟是要赚钱的，这些问题的解决方案，在他们文档里倒是都有写。
我感觉我都成了采购的了，其实我就是讲下这个 httpdns 而已，广告费都没有，对吧。
本文由 mdnice 多平台公布