httpdns技术具体是做什么用的？
- 内容介绍
- 文章标签
- 相关推荐
本文共计989个文字，预计阅读时间需要4分钟。
DNS解析现况问题1：暴力的DNS攻击+为什么要出现HTTPDNS（先不用管思维，后面解释），那么，现在的DNS解析，是不是有什么问题？DNS可能有问题吗？就比如输入一个域名xx。
dns解析现状问题1：暴利的dns劫持要说为啥会出现xw.qq.com/cmsid/20211203A014PC00)
dns解析现状问题2：调度不准前面有篇文章，讲gslb的，提到过如下事情：
依赖运营商帮我们做dns解析，不一定很靠谱，比如我们把xxx.com要解析到我们在深圳和北京的两个机房，一般来说，是期望可以根据用户所在的地区来返回就近的地址，如广东用户就返回xxx.com在深圳机房的地址，北京用户就给北京机房的地址。或者是dns运营商那边，也支持按用户的运营商路线来解析，
但是呢，总归来说，这个解析是掌握在别人手里，他要是靠谱，那就没问题；他那边要是解析不靠谱，那就问题较大，比如广东用户给你个北京机房地址，你说用户是不是得卡死在你的网站上，体验就完全不行。
203.107.1.33/xx/d，其中，203.107.1.33是一个公网ip，是这个203.107.1.33/100000/d?host=www.xxx.com在该云厂商的网站上，也介绍了响应体的格式：
{
"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；另外，我看到云厂商也支持你自己写一段代码，让你自定义策略。
只适合有客户端的场景，可以看到，这个方案是需要先去查询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而已，广告费都没有，对吧。
本文共计989个文字，预计阅读时间需要4分钟。
DNS解析现况问题1：暴力的DNS攻击+为什么要出现HTTPDNS（先不用管思维，后面解释），那么，现在的DNS解析，是不是有什么问题？DNS可能有问题吗？就比如输入一个域名xx。
dns解析现状问题1：暴利的dns劫持要说为啥会出现xw.qq.com/cmsid/20211203A014PC00)
dns解析现状问题2：调度不准前面有篇文章，讲gslb的，提到过如下事情：
依赖运营商帮我们做dns解析，不一定很靠谱，比如我们把xxx.com要解析到我们在深圳和北京的两个机房，一般来说，是期望可以根据用户所在的地区来返回就近的地址，如广东用户就返回xxx.com在深圳机房的地址，北京用户就给北京机房的地址。或者是dns运营商那边，也支持按用户的运营商路线来解析，
但是呢，总归来说，这个解析是掌握在别人手里，他要是靠谱，那就没问题；他那边要是解析不靠谱，那就问题较大，比如广东用户给你个北京机房地址，你说用户是不是得卡死在你的网站上，体验就完全不行。
203.107.1.33/xx/d，其中，203.107.1.33是一个公网ip，是这个203.107.1.33/100000/d?host=www.xxx.com在该云厂商的网站上，也介绍了响应体的格式：
{
"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；另外，我看到云厂商也支持你自己写一段代码，让你自定义策略。
只适合有客户端的场景，可以看到，这个方案是需要先去查询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而已，广告费都没有，对吧。