这个专栏的计算机网络协议，我是在极客时间上学习 已经有三万多人购买的刘超老师的趣谈网络协议专栏，讲的特别好，像看小说一样学习到了平时很枯燥的知识点，计算机网络的书籍太枯燥，感兴趣的同学可以去付费购买，绝对物超所值，本文就是对自己学习专栏的总结,评论区可以留下你的问题，咱们一起讨论！
上面介绍了应用层的协议，包含了看新闻、支付、直播、下载等场景；每个人平时常用的网站有二三十个吧，全部用IP地址访问肯定记不住啊，那就需要一个地址簿，根据名称来查看具体的地址。本文将分为两个部分来进行介绍：
DNS服务器就是充当地址簿的角色，根据域名查看对应的ip地址；
DNS服务器要设置成高可用、高并发和分布式的才能应对每天全球各地的人的访问；
DNS服务器的树状层次结构如下：
为了提高DNS的解析性能，很多网络都会就近部署DNS缓存服务器，解析流程如下：
过程图如下所示，步骤序号相对应：
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解析这个域名；
两层的原因是因为分运营商和地域，不同运营商的客户不可以访问相同运营商机房中的资源，这样不跨运营商访问，有利于提高吞吐量，减少时延。
总结
网络世界中的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。
HTTPDNS的缓存设计
HTTPDNS缓存设计策略，分为客户端、缓存、数据源三层。
SDK中的缓存会严格按照缓存过期时间，如果缓存没有命中，或者已经过期，而且客户端不允许使用过期的记录，则会发起一次解析，保障记录是更新的；
同步解析：
HTTPDNS的调度设计
客户端
客户端中嵌入了SDK，，HTTPDNS服务端可以根据手机是哪个国家、哪个运营商、哪个省，甚至哪个市，选择最佳的服务节点返回；
多个节点还需要考虑虑错误率、请求时间、服务器压力、网络状况等，并非只有地理位置；
服务端
应用可以通过调用HTTPDNS的管理接口，配置不同服务质量的优先级、权重。
总结
