DNS无法解析IP_计算机网络-DNS

DNS

DNS，英文全称Domain Name System，也就是域名系统。它的作用是：用于解析用户访问域名的对应IP地址

DNS解析

当我们输入一个URL，我们的计算机首当其冲就会施展第一道魔法：DNS解析。

做这一步的目的是：为了找到我们输入的域名的对应IP地址，如https://www.baidu.com是域名，他对应的ip地址可能是36.152.44.95。

注意：我们在互联网上的资源最终都是以ip地址的形式来进行定位的，我们日常输入的域名只是为了方便大家记忆。毕竟相比于36.152.44.95这一串数字的ip地址，我们更容易记得www.baidu.com这种域名形式。

那么，我们的DNS是如何查找到我们输入域名的对应IP呢？我们还是以我们在浏览器输入www.baidu.com为例，它的流程是这样的：

加速DNS解析：CDN

通过上面的DNS解析过程我们可以看到，DNS解析是一个复杂的过程，用户想要请求到域名对应的IP地址需要经过一层又一层的环节，所以这个过程是很漫长的。还有一个问题是：我们的一个域名www.baidu.com一般都会存在多个ip对应，一个ip对应一台服务器，那么用户请求的时候应该分散到各个服务器上（应该根据服务器的远近和服务器的状况进行请求，而不是大家都只请求同一台服务器）。

为了解决这些问题，一个名为CDN（Content Delivery Network：内容分发网络）的解决方案出现了，简单来讲CDN就是一种加速DNS寻址过程的一种手段，CDN的主要由CDN节点调度和CDN节点更新两部分组成。

CDN节点调度

我们之前说到，一个理想的方式是：可以让用户访问到最合适自己的服务器（服务器距离近且健康）。CDN的节点调度系统就可以帮我们分配节点完成这样的需求：CDN调度系统会把最合适的CDN节点分配给我们，分配的方式主要靠以下两种手段：

dns调度：根据ldns（本地dns）的位置进行节点就近分配

优点：只需一次请求，无需转发二次请求
缺点：准确性无法保障，用户的ldns位置可能与实际位置不符（比如：北京联通用户使用深圳电信的LDNS）
适用场景：小文件传输（寻址开销小）

http调度：分析用户ip，然后通过302转发到就近的CDN节点

优点：准确性相比于dns要高
缺点：由于通过302转发，所以会请求两次
适用场景：大文件传输（寻址开销大，但是可以找到更高效的节点）

通过这些CDN调度优化，我们就可以寻找到最适合自己的CDN节点，优化页面的传输过程

CDN节点更新

之前我们有说：CDN调度系统是把最合适的CDN节点分配给我们，那么CDN节点里面的内容是从何而来呢？当新内容更新的时候CDN节点里的内容如何更新？这就要说到我们的第二个点：CDN节点更新

CDN节点更新的方式主要有两种：

服务端主动推送：服务端主动下发内容
1. 问题：服务端推送不及时可能存在404情况

客户端被动查询：客户端请求时检查节点，如果节点无内容/内容已过期，则请求新的资源内容并存在对应的CDN节点上

优化手段

除了CDN这种优化手段，我们在每个网页上面也有对应的DNS优化手段，由于DNS本身是一个比较漫长的过程，所以我们的主要优化目标是减少DNS的请求数量和提前进行DNS的查询和链接。

减少DNS的请求数量

由于每个域名都需要进行DNS解析的过程，所以减少域名的请求，那就可以减少DNS解析的次数，这样就可以完成对应的DNS优化了。

聪明的小朋友可能会疑惑，这么说的话我们只需要把所有资源都放在同一域名下不是最优方案了吗？那为什么我看好多网站的资源还要分好多域名呢？

其实这是因为我们的域名并发请求是有数量限制的，比如说：如果浏览器在同一域名下请求资源，一次最多请求5个资源。那么如果我们要总共请求15个资源，就只能分三批先请求5个，再请求5个，最后再请求5个。关于浏览器具体一次能请求多少并发资源，经测试：Chrome浏览器的最大并发数为6个。想要了解其他浏览器的并发数，可以看这里。

提前进行DNS解析

提前进行DNS解析有两种手段：

dns提前加载
1. 提前进行dns解析：<link rel="dns-prefetch" href="//atanx.alicdn.com">
2. 禁用（防止dns解析滥用）：<meta http-equiv="x-dns-prefetch-control" content="off">

链接提前建立
<link rel="preconnect" href="//example.com">
<link rel="preconnect" href="//cdn.example.com" crossorigin>

我们也可以通过prefetch和prerender提前加载将要跳转的页面资源