计算机网络协议(五)——DNS、HTTPDNS
底层网络知识详解：DNS、HTTPDNS
- 概述
- 一、DNS协议：网络世界的地址簿
- 1.1 DNS解析流程
- 1.2 负载均衡
- 二、HTTPDNS
概述
这个专栏的计算机网络协议，我是在极客时间上学习 已经有三万多人购买的刘超老师的趣谈网络协议专栏，讲的特别好，像看小说一样学习到了平时很枯燥的知识点，计算机网络的书籍太枯燥，感兴趣的同学可以去付费购买，绝对物超所值，本文就是对自己学习专栏的总结,评论区可以留下你的问题，咱们一起讨论！
上面介绍了应用层的协议，包含了看新闻、支付、直播、下载等场景；每个人平时常用的网站有二三十个吧，全部用IP地址访问肯定记不住啊，那就需要一个地址簿，根据名称来查看具体的地址。本文将分为两个部分来进行介绍：
- DNS协议；
- HTTPDNS协议；
一、DNS协议：网络世界的地址簿
DNS服务器就是充当地址簿的角色，根据域名查看对应的ip地址；
DNS服务器要设置成高可用、高并发和分布式的才能应对每天全球各地的人的访问；
DNS服务器的树状层次结构如下：
- 根DNS服务器 ：返回顶级域DNS服务器的IP地址；
- 顶级域DNS服务器：返回权威DNS服务器的IP地址；
- 权威DNS服务器 ：返回相应主机的IP地址；
1.1 DNS解析流程
为了提高DNS的解析性能，很多网络都会就近部署DNS缓存服务器，解析流程如下：
- 客户端向本地域名服务器发送DNS请求，www.taobao.com的IP是啥；如果本地DNS是通过DHCP配置，那么本地DNS就由你的网络服务商(ISP)，电信、移动等自动分配；
- 本地DNS收到来自客户端的请求，如果在其缓存的地址簿里找到了www.taobao的ip地址，直接返回即可；没找到，本地DNS会去找他的老大，根域名服务器；根域名服务器全球有13套，是最高层次的；
- 根域名服务器收到请求后，发现后缀是.com,就让你去找.com的顶级域名服务器去查找；
- 本地DNS转到顶级域名服务器说，二哥好，大哥让我来找你的！顶级域名服务器
就是大名鼎鼎的比如 .com、.net、 .org这些一级域名，它负责管理二级域名； - 顶级域名服务器说：：“我给你负责 www.taobao.com 区域的权威DNS服务器的地址，你去问它应该能问到。”
- 本地DNS转到权威DNS服务器，请问对应的ip地址是多少；
- 权限DNS服务器查询后将对应的IP地址X.X.X.X告诉本地DNS，
- 本地DNS再将IP地址返回客户端，客户端和目标建立连接。
过程图如下所示，步骤序号相对应：
1.2 负载均衡
DNS在递归查询的过程中，除了可以通过名称映射为IP地址，还可以进行负载均衡；
以吃肯德基为例，肯德基在全国各地都有门店，如果你想吃肯德基了，不用都跑到一家去，直接就近找一家店吃，这就是负载均衡；
DNS首先需要进行内部负载均衡
举例：如果一个应用访问数据库，那应用里面配置数据库的IP地址还是对应的域名呢？
显然是配置域名，因为数据库如果因为某种原因，转换到别的服务器上，那么所有连接应用中配置的IP地址都要改变，极大的增大了运维的压力；
所以当多个应用之间相互进行访问的时候，只要配置为域名，就可以在域名解析的时候根据配置策略，返回对应的IP地址，实现内部负载均衡；
DNS还可以做全局负载均衡
为了保证应用高可用，往往会部署在多个机房，每个地方都会有自己的IP地址。当用户访问某个域名的时候，这个IP地址可以轮询访问多个数据中心。如果一个数据中心因为某种原因挂了，只要在DNS服务器里面，将这个数据中心对应的IP地址删除，就可以实现一定的高可用。
当然，希望的是上海的用户只访问上海的数据中心，北京的用户只访问北京的数据中心；
举例：DNS访问数据中心中对象存储上的静态资源
全国有多个数据中心托管在运营商下，每个数据中心三个可用区（Available Zone）。对象存储通过跨可用区部署，实现高可用性。在每个数据中心中，都至少部署两个内部负载均衡器，内部负载均衡器后面对接多个对象存储的前置服务器（Proxy-server）。
如下图所示：
简单的应用通过步骤1-7就是上面说到的DNS递归查询的过程；
对于复杂的应用，尤其是跨地域跨运营商的大型应用，则需要更加复杂的全局负载均衡机制上图中配置了两层全局负载均衡器（GSLB，Global Server Load Balance）
给object.yourcompany.com起一个别名，例如 object.vip.yourcomany.com，然后告诉本地DNS服务器，让它请求GSLB解析这个域名；
两层的原因是因为分运营商和地域，不同运营商的客户不可以访问相同运营商机房中的资源，这样不跨运营商访问，有利于提高吞吐量，减少时延。
- 第一层GSLB：通过查看请求它的本地DNS服务器所在的运营商，假设是移动，采取CNAME的方式，通过另一个别名 object.yd.yourcompany.com，告诉本地DNS服务器去请求第二层的GSLB；
- 第二层GSLB：通过查看请求它的本地DNS服务器所在的地址，就知道用户所在的地理位置，然后将距离用户位置比较近的Region里面，**六个内部负载均衡（SLB，Server Load Balancer）**的地址，返回给本地DNS服务器；
- 本地DNS服务器将结果返回给本地DNS解析器，本地DNS解析器将结果缓存，返回给客户端；
- 客户端访问属于同一个运营商下距离较近的Region1中的对象存储，客户端得到了六个IP地址，通过负载均衡、随机或者轮询选择一个可用的区进行访问，对象存储一般会有三个备份，从而可以实现对存储读写的负载均衡。
总结
- DNS是网络世界的地址簿，通过域名寻址，域名服务器是按照树状结构组织的，因而域名查找是使用递归的方法，并通过缓存的方式增强性能；
- 在域名和IP的映射过程中，给了应用基于域名做负载均衡的机会，可以是简单的负载均衡，也可以根据地址和运营商做全局的负载均衡；
二、HTTPDNS
网络世界中的DNS地址簿也会出错，本来附近就有肯德基，但是把你推荐几公里开外的肯德基店；
传统DNS中的问题：
1、域名缓存问题
每个请求访问权威服务器，访问过一次就会在本地缓存，当其他人来问的时候，直接返回缓存的数据；
就像是你之前去吃过肯德基，假如这家店已经关了，别人问你哪里有肯德基，你凭借着记忆告诉他了地址，结果别人白跑一趟啥都没找到；
此外，运营商会把一些静态页面，缓存到本运营商的服务器内，这样用户请求的时候，就不用跨运营商进行访问，这样既加快了速度，也减少了运营商之间流量计算的成本。
这种情况大部分是正常的，但是页面更新之后，用户访问到的就是老的页面；就像是肯德基新推出了一个口味的汉堡，你想去吃，但是你的朋友告诉你在这吃也一样，对于想吃新口味的你就会很失望；
本地的缓存，往往使得全局负载均衡失败，因为上次进行缓存的时候，缓存中的地址不一定是这次访问离客户最近的地方，如果把这个地址返回给客户，那肯定就会绕远路。
2、域名转发问题
如果你是A运营商的用户，访问A运营商的DNS服务器，权威服务器根据是A运营商的返回部署在A运营商中的网址，但是如果A运营商将请求转到B运营商，跨运营商访问，速度会很慢；
3、出口NAT问题
网络地址的转换，权威的DNS服务器，就没办法通过这个地址，来判断客户到底是来自哪个运营商，而且极有可能因为转换过后的地址，误判运营商，导致跨运营商的访问。
4、域名更新问题
本地DNS服务器是由不同地区、不同运营商独立部署的。对域名解析缓存的处理上，实现策略也有区别，有的会偷懒，忽略域名解析结果的TTL时间限制，在权威DNS服务器解析变更的时候，解析结果在全网生效的周期非常漫长。
5、解析延迟问题
DNS的查询过程需要递归遍历多个DNS服务器，才能获得最终的解析结果，这会带来一定的时延，甚至会解析超时。
HTTPDNS的工作模式
HTTPNDS其实就是，不走传统的DNS解析，而是自己搭建基于HTTP协议的DNS服务器集群，分布在多个地点和多个运营商。当客户端需要DNS解析的时候，直接通过HTTP协议进行请求这个服务器集群，得到就近的地址。
使用HTTPDNS的，往往是手机应用，需要在手机端嵌入支持HTTPDNS的客户端SDK。
- 客户端的SDK里动态请求服务端，获取HTTPDNS服务器的IP列表，缓存到本地。随着不断地解析域名，SDK也会在本地缓存DNS域名解析的结果。
- 当手机应用要访问一个地址的时候，首先看是否有本地的缓存，如果有就直接返回。缓存属于手机应用，并非整个运营商来统一。如何更新、何时更新，手机应用的客户端可以和服务器协调来做这件事情；
- 如果本地没有，就需要请求HTTPDNS的服务器，在本地HTTPDNS服务器的IP列表中，选择一个发出HTTP的请求，会返回一个要访问的网站的IP列表；
HTTPDNS的缓存设计
HTTPDNS缓存设计策略，分为客户端、缓存、数据源三层。
- 对于应用架构来讲，就是应用、缓存、数据库。常见的是Tomcat 、Redis、MySQL。
- 对于HTTPDNS来讲，就是手机客户端、DNS缓存、HTTPDNS服务器
只要是缓存模式，就需要解决缓存的过期、更新、不一致的问题；
SDK中的缓存会严格按照缓存过期时间，如果缓存没有命中，或者已经过期，而且客户端不允许使用过期的记录，则会发起一次解析，保障记录是更新的；
同步解析：
- 直接调用HTTPDNS的接口，返回最新的记录，更新缓存；
- 优点：实时性好，缺点：如果有多个请求都发现过期的时候，同时会请求HTTPDNS多次；
- 更新方式：Cache-Aside机制，先读缓存，不命中读数据库，同时写入缓存；
异步解析： - 添加一个解析任务到后台，由后台任务调用HTTPDNS的接口；
- 优点：可以将多个请求都发现过期的情况，合并为一个对于HTTPDNS的请求任务，只执行一次，减少HTTPDNS的压力。同时创建一个任务进行预加载，防止过期之后刷新；**缺点：**当前请求拿到过期数据的时候，如果客户端允许使用过期数据，需要冒一次风险。如果过期的数据还能请求，就没问题；如果不能请求，则失败一次，等下次缓存更新后，再请求方能成功；
- 更新方式：Refresh-Ahead机制，业务仅仅访问缓存，当过期的时候定期刷新；
HTTPDNS的调度设计
客户端
客户端中嵌入了SDK，，HTTPDNS服务端可以根据手机是哪个国家、哪个运营商、哪个省，甚至哪个市，选择最佳的服务节点返回；
多个节点还需要考虑虑错误率、请求时间、服务器压力、网络状况等，并非只有地理位置；
服务端
应用可以通过调用HTTPDNS的管理接口，配置不同服务质量的优先级、权重。
- HTTPDNS会根据这些策略综合地理位置和线路状况算出一个排序，优先访问当前那些优质的、时延低的IP地址。
- HTTPDNS通过智能调度之后返回的结果，也会缓存在客户端。为了不让缓存使得调度失真，客户端可以根据不同的移动网络运营商WIFI的SSID来分维度缓存。不同的运营商或者WIFI解析出来的结果会不同。
总结
- 传统的DNS：解析慢、更新不及时。因为缓存、转发、NAT问题导致客户端误会自
己所在的位置和运营商，从而影响流量的调度。 - HTTPDNS通过客户端SDK和服务端，通过HTTP直接调用解析DNS的方式，绕过了传统DNS的这些缺点，实现了智能的调度。