在上篇文章中([计算机网络] DNS 协议),介绍了 DNS 协议,它主要做两个功能:根据名称查到具体的地址;针对多个地址做负载均衡,而且可以在多个地址中选择一个距离我最近的地方,让我访问.
看起来这种方式无懈可击,但其实也有些问题.
传统 DNS 存在的问题
1 ,域名缓存问题:
客户端想要访问一个网址的时候,其实它首先是去看本地的缓存里面有没有这个地址,如果有就直接访问,如果没有才会去询问上级领导.
但是这个时候就会有个问题:比如在你上高中的时候,你知道学校旁边有个超好吃的店,后来你再想吃的时候,想都没想,直接去了那家店,结果发现人家关门了,你会不会非常失望?本地缓存也会出现这个问题,有的时候那个地址已经换掉了,但是因为本地缓存中有原来的地址,所以不会向上一级询问,将你导向原来的地址,结果就是访问不到界面,由此带来的用户体验不是很好.
还有个问题:假设我在北京海淀区,淘宝的应用因为某种原因没有在海淀区设置数据中心,然后我访问的时候,一直都是将我的访问请求发送到朝阳区.后来呢,淘宝在海淀区增加了数据中心,但是当我访问的时候,本地缓存依旧会将我的请求,导向到朝阳区那边,这样造成的结果就是: 1 ,对于客户来说,让他绕远路了.明明一个区域就可以解决的事情,偏偏要跨区域.就像明明在这里可以买到东西,偏偏让你跑到另外的地方去买,你开心嘛? 2 ,对于商家来说,也就是淘宝,我设置了新的数据中心,结果呢,客户的请求没能到这里,那我还费钱费力的去做这件事干嘛?又没有提高用户的体验,对不对.
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 服务器能够准确知道这些信息,所以可以做到精准的全局负载均衡.
写到这里,这篇文章想要表达的是两点:
1 ,传统的 DNS 有很多问题:比如域名缓存问题,出口 NAT 问题,解析延迟问题
2 ,为了解决上述问题, HTTPDNS 通过客户端 SDK 和服务端,通过 HTTP 的形式,直接调用解析 DNS 的方式,绕过了传统的 DNS 的这些缺点,从而实现了智能的调度.
以上是学的极客时间上<趣谈网络协议>这门课程,我已经感觉自己的脑袋有些大了…还有一些内容,我先自己慢慢消化一下…
感谢您的阅读~