对一次网络请求过程的了解程度，一是展现你的专业知识；二是深刻的理解，让你在大型网站架构中做出更适合、可靠的架构。而DNS是这一切的出发点，本文结合一张常用架构图，来描述一下这个过程。
部署架构
大型的web服务，我们的部署架构一般如下图。先上图再解释。
这里来解释下，为什么要这样架构。
首先客户端的请求会通过 DNS 获取到对应的服务器IP（实际上是LB的ip地址），这一层会有 DNS的负载均衡，并且如果是静态站资源会进入到CDN，这里DNS与CDN如何完成接棒的过程，后面会详细解释。
当请求到达LB层的时候（应用层协议是HTTP协议），这一层又会做一次负载均衡（可能用LVS或者Nginx做）。这里我们有两种不同的处理方式，一条路径会进入到代理集群，一条路径直接进入到应用集群。这是为什么？
LB到代理集群
通过最顶层的LB负责均衡后到达代理机器，这里不直接进入到应用集群，还要搞一层代理的目的主要是方便我们在代理集群进行各种高级（骚）操作。
比如：请求日志收集，自定义缓存，自定义的负载均衡，自定义的路由规则制定（跨机房，路由分组）
LB到应用集群
上面到代理层有那么多好处，为什么还有绕过代理层这条路径存在呢？这主要是针对大流量服务。因为代理层因为有很多额外的操作，导致响应会变长，路径增加，到下一个集群多了一次网络传输往返。
所以，一般针对大流量服务，为了防止代理被打满，响应更快，会直接在外网LB上进行负载到应用集群。
通过上面的分割后，最终都会到达应用集群，每一台机器上我们会部署一台 Nginx 来按照域名转到对应服务，当然这里完全也可以不是 Nginx ，比如微服务，这里可能是一个 SideCard 代理。这里主要是为了便于说明我们后面全部都是当成Nginx。服务调用 DB Cache 等，都是通过域名，这是为了负载均衡，请求时，会通过内网DNS服务，完成域名解析，然后拿到内网的 LB 的IP。然后再这里进行内网的负载均衡，会根据域名的端口来检查你是写操作、还是读操作返回IP。常规一点会保证是单点写入，多点读取。来完成数据一致性的保障。
整个大体过程如此，接下来我们详细说一下 DNS 与 CDN 相关的工作原理。
DNS如何实现IP查找
为了后面说清楚CDN，这里先介绍DNS的解析过程。当然此类文章网络上已经极多。但是我还是想按照我的理解来说一下DNS是如何工作的。
在整个DNS过程中有四个重要概念，下面解释下。
DNS Resolver - 递归解析器，主要是接收客户端发出的域名解析请求，并发送 DNS query 查询请求。对于客户端来说它不需要任何操劳，等待 DNS Resolver 告诉自己域名转IP的结果就好。
Root Server - 这是转换IP执行的第一步查询，根服务器并不会保存具体的域名IP映射信息。它就像一个索引服务器，会告诉你下一步该去那台 TLD Server 查询。
TLD Server - 这是顶级域名服务器，是执行IP查询的第二步，这里会告诉 DNS Resolver 权威域名服务器的地址。
Authoriative Server - 权威域名服务器就是包含了完整的机器名的域名，例如：www.mi.com ，在这台机器上保存了这个具体域名对应的IP地址。
下面根据图中的十个步骤说一下每一步都在干嘛。
- 一个用户在浏览器输入了：mi.com，这时会产生一个 DNS 查询，从而进入到 DNS Resolver中；
- Resolver 会进入到 root server 进行查询；
- root server 返回了 TLD server 的地址，查询请求转向顶级域名服务，这里是 .com 服务器。
- 递归解析器向 .com 服务器发送一个请求；
- TLD server 收到请求后会返回 mi.com 权威服务器的地址；
- 递归解析器又发了一个向权威服务器查询的请求，至此权威服务器查询自己的映射表拿到IP；
- 返回查询到的IP给了 DNS Resolver；
- DNS Resolver返回IP给浏览器，浏览器将会用这个IP来建立连接，发起请求;
- 客户端通过这个IP地址，发起一个 HTTP 请求；
- 服务器解析请求，并返回数据到浏览器。
这里需要补充一点是，上面每一步其实都有DNS缓存的设计。比如：
- 浏览器会缓存DNS的结果，（chrome://net-internals/#dns）
- 操作系统的DNS模块会缓存
- 后面的每一层级也都有缓存
所以很多时候，我们的解析过程并不是要顺序执行完这8个步骤。这就跟我们自己开发的应用服务一样，层层缓存，有缓存就读取缓存结果，缓存实现就执行完整流程。
DNS的解析分类
DNS有多种解析记录可以设置，我这里介绍三个很常用的设计。
A记录 - 被称为IP指向，用户设置自域名指到对应的IP主机上。如果想要利用A记录实现 负载均衡 需要主机商的支持。
CNAME记录 - 它相当于为一个主机名设置一个别名，而且该记录不能直接使用IP，只能是另一个主机的别名。CDN主要就是利用该记录来完成的。如果有A记录与CNAME记录同时存在，A记录会被优先使用，换句话说CNAME记录不会生效。
NS记录 - 用来设置一个域名的权威服务器路径，该记录只会对子域名生效。这个地方可以设置IP也可以设置另外一个权威服务器的域名。需要重点指出的是它的优先级高于A记录，并且它在DNS解析过程中，会跳过2，3，4，5步。
了解完了DNS的步骤，接下来就进入到CDN部分的分析。
CDN访问加速度
什么是CDN呢？中文翻译过来就是内容分发网络。看张图。
没有CDN的时候，不管哪里的用户访问我们的站点，都需要到我们数据中心来获取数据(单纯的DNS过程)。而有了CDN之后，用户根据自己的地理位置会选择距离自己最近的缓存数据中心来获取数据。不会每次都到源站（应用服务器）来获取数据。为了理解这个过程，我们是如果在完整的DNS过程中，实现CDN的呢？
接下来我们需要回答两个问题。
- CDN带来了什么好处。
- 如何解析到CDN。
CDN带来的好处
了解一个东西之前最好知道它能干什么，带来的好处是什么。然后我们再去看它的运行原理。对于CDN有以下几个方面的好处。
提高页面加载速度
这是最显而易见的一个优势，通过上面的图，大家也可以直观感受下，用户访问距离自己最近的机器，速度肯定是最快的。并且网站的加载速度越快那么用户体验越优秀，你的网站更会受到对应用户的喜爱。至于如何实现就近访问的，后面原理部分介绍。
增加内容的冗余
CDN是一个典型的分布式架构，它通过增加数据的冗余，一方面保障在大流量面前有多台服务器能够提供相同的数据；另一方面当部分机器出现故障时，可以进行自动转移。
节省带宽
如果大家自己买过云服务就知道，带宽每增加一点价格就飙升。使用CDN后，由于流量被分流了，那么原机器带宽要求自然就降低了。当然带宽费用降低了，你还需要为CDN付费。
保障服务安全
CDN可防止的攻击：DDOS攻击，该攻击就是通过巨大流量打满你的带宽，让你丧失服务能力。那么由于CDN的存在，它将巨大的流量进行了分流。那么源站压力自然小了。这其实也是高并发需要考虑的。
CDN目前不仅仅是只能缓存静态的HTML、CSS、JS、VIDEO，现在还有能够缓存动态接口内容的CDN，这为我们在架构高并发的服务时，提供了更多的手段进行选择。
CDN工作原理
在介绍DNS的时候，介绍了客户端是如何获取到IP地址的。那么有了CDN之后，这个过程该怎么处理呢？
CDN其实更像是放在应用服务器与用户之间的一层缓存。所以如果DNS的时候，返回给客户端的是CDN机器的IP而不是应用的IP，那么自然就走到了CDN机器上。
为了实现上述目的，我们会为该域名配置一个 CNAME（大家注意上面提到的CNAME与A记录的优先级），那么这个CNAME是最终如何解析到对应的CDN机器呢？其实流程与DNS解析是一样的。当发现一个域名设置了CNAME时，DNS解析器会继续解析这个CNAME别名（其实就是另一个域名）。对这个CNAME解析的时候会用到全局负载DNS解析，它会根据访问者的地理位置信息返回对应的IP（CDN机器的IP）。因此客户端实际上得到的是距离它最近的CDN机器的IP地址。
如果说用户访问CDN，但是CDN上没有对应内容会怎么办？此时CDN机器其实会根据自身专用的DNS解析服务，根据域名得到源站的IP，然后向源站发送请求获取数据，并把这些数据缓存到本地，方便后续使用；同时返回本次结果，完成本次请求的访问。
需要说一下的是，CDN其实也是分层的。距离用户最近的称之为边缘节点。而CDN的中心服务器集群被称为二级缓存。在上面就是应用部署的源站。一般边缘节点没数据就去找二级缓存，二级缓存没数据就去找源站（被称为回源）。
小结
关于 DNS 的过程，文中是以流程介绍为主，至于更细节的依赖协议、传输过程都忽略了。 关于CDN也是我们经常用到的性能提升手段，后续要写的秒杀相关文章，就会用到它来提升性能。特别是CDN的分布式设计、解析过程在我们平常设计应用架构时非常有参考意义。
