dns embedded 缓存 dns缓存文件在哪

1.用户层

1. DNS

浏览器DNS查找顺序：浏览器DNS缓存->本地系统DNS缓存->本地计算机HOSTS文件->ISP DNS缓存->递归搜索

1. 浏览器DNS缓存

浏览器会按照一定频率缓存DNS记录，（浏览器维护一张域名与 IP 地址的对应表）。

 

注：可以通过 chrome://net-internals/#dns 查找目前Chrome中的DNS缓存。

 

1. 本地DNS缓存

如果浏览器缓存中找不到需要的DNS记录，那就去操作系统找。

注：可以在终端通过ipconfig/displaydns  查找目前系统中的 DNS 缓存。

可以通过ipconfig/flushdns清除本地dns缓存

 

1. 操作系统DNS缓存

本地HOSTS文件: Windows系统中位于C:\Windows\System32\drivers\etc

1. ISP的DNS服务器

 ISP(互联网服务提供商、联通电信移动)，ISP有专门的DNS服务器应 对DNS查询请求

 

1. 根服务器

ISP的DNS服务器还找不到的话，它就会向根服务器发出请求，进行递归查询

1.1.5.1  DNS服务器查询方式：

（1）递归查询

递归查询是一种DNS 服务器的查询模式，在该模式下DNS 服务器接收到客户机请求，

必须使用一个准确的查询结果回复客户机。

如果DNS 服务器本地没有存储查询DNS 信息，那么该服务器会询问其他服务器，并将返回的查询结果提交给客户机。

客户机和服务器之间的查询是递归查询

是递归查询告诉客户机IP

（2）迭代查询

DNS 服务器另外一种查询方式为迭代查询，DNS 服务器会向客户机提供其他能够解析查询请求的DNS 服务器地址，

当客户机发送查询请求时，DNS 服务器并不直接回复查询结果，而是告诉客户机另一台DNS 服务器地址，

客户机再向这台DNS 服务器提交请求，依次循环直到返回查询的结果为止。

 

拿juejin.im举例如何进行递归查询：

1.LDNS向 Root Name Server（根域名服务器，如com、net、im 等的顶级域名服务器的地址）发起请求，此处，Root Name Server 返回 im 域的顶级域名服务器的地址；

2.LDNS 向 im 域的顶级域名服务器发起请求，返回 juejin.im 域名服务器地址；

3.LDNS 向 juejin.im 域名服务器发起请求，得到 juejin.im 的 IP 地址；

1. 浏览器

浏览器缓存机制：

可以认为，浏览器里有一个专门存放缓存规则的一个数据库，也可以说是一个映射表，把缓存资源信息，同电脑磁盘中的实际文件的地址，对应起来

浏览器第一次请求资源时图解：

注意：缓存规则从响应头里边获取

用户行为对缓存的影响：

 

谷歌浏览器查看缓存文件：

谷歌浏览器URL中输入chrome://version按下回车键，chrome浏览器中会显示个人资料路径，复制该路径，缓存存储在Cache和Code Cache目录下。

 

图解一：

 

图解二：

1.  H5新特性：DNS Prefetch（预获取）

即 DNS 预获取，是前端优化的一部分。一般来说，在前端优化中与 DNS 有关的有两点：

1. 减少 DNS 的请求次数
2. 进行 DNS 预获取

典型的一次 DNS 解析需要耗费 20-120 毫秒，减少DNS解析时间和次数是个很好的优化方式。DNS Prefetching 是让具有此属性的域名不需要用户点击链接就在后台解析，而一些浏览器域名解析和内容载入是并行发生（而不是串行）。正因如此，某些高延迟的域名的解析过程才不会卡住资源的加载，减少用户的等待时间，提升用户体验。

这样可以极大的加速（尤其是移动网络环境下）页面的加载。在某些图片较多的页面中，在发起图片加载请求之前预先把域名解析好将会有至少 5% 的图片加载速度提升。

DNS Prefetch如何使用：

1.<meta>信息告诉浏览器，当前页面要做DNS预解析；

<meta http-equiv="x-dns-prefetch-control" content="on" />

2.</head>使用<link>标签来强制对DNS预解析；

<link rel="dns-prefetch" href="http://baidu.com" />

DNS Prefetch使用注意事项：

dns-prefetch需慎用，多页面重复DNS预解析会增加重复DNS查询次数；

你可以通过 chrome://net-internals/#dns 查找目前系统中的 DNS 缓存和 Chrome 中使用的情况。

1.  强缓存

到底什么是强缓存？强在哪？其实强是强制的意思。当浏览器去请求某个文件的时候，服务端就在respone header里面对改文件做了缓存配置。缓存的时间、缓存类型都由服务端控制，具体表现为：
respone header 的cache-control，常见的设置是max-age public private no-cache no-store等

如下图,
设置了cahe-control:max-age=315360000,public,immutable

注：

Memory Cache：内存中的缓存，主要包含的是当前中页面中已经抓取到的资源,例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快,内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。

计算机中的内存一定比硬盘容量小得多，操作系统需要精打细算内存的使用，所以能让我们使用的内存必然不多。

当我们访问过页面以后，再次刷新页面，可以发现很多数据都来自于内存缓存

内存缓存在缓存资源时并不关心返回资源的HTTP缓存头Cache-Control是什么值，同时资源的匹配也并非仅仅是对URL做匹配，还可能会对Content-Type，CORS等其他特征做校验。

 

Disk Cache：存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量。

在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。

 

 

max-age表示缓存的时间是315360000秒（10年），public表示可以被浏览器和代理服务器缓存，代理服务器一般可用nginx来做。immutable表示该资源永远不变，但是实际上该资源并不是永远不变，它这么设置的意思是为了让用户在刷新页面的时候不要去请求服务器！啥意思？就是说，如果你只设置了cahe-control:max-age=315360000,public 这属于强缓存，每次用户正常打开这个页面，浏览器会判断缓存是否过期，没有过期就从缓存中读取数据；但是有一些 "聪明" 的用户会点击浏览器左上角的刷新按钮去刷新页面，这时候就算资源没有过期（10年没这么快过），浏览器也会直接去请求服务器，这就是额外的请求消耗了，这时候就相当于是走协商缓存的流程了（下面会讲到）。如果cahe-control:max-age=315360000,public再加个immutable的话，就算用户刷新页面，浏览器也不会发起请求去服务，浏览器会直接从本地磁盘或者内存中读取缓存并返回200状态，看上图的红色框（from memory cache）。这是2015年facebook团队向制定 HTTP 标准的 IETF 工作组提到的建议：他们希望 HTTP 协议能给 Cache-Control 响应头增加一个属性字段表明该资源永不过期，浏览器就没必要再为这些资源发送条件请求了。

强缓存流程：

 

所以强缓存步骤已经很清晰了：

1. 第一次请求 a.js ，缓存表中没该信息，直接请求后端服务器。
2. 后端服务器返回了 a.js ，且 http response header 中 cache-control 为 max-age=xxxx，所以是强缓存规则，存入缓存表中。
3. 第二次请求 a.js ，缓存表中是 max-age， 那么命中强缓存，然后判断是否过期，如果没过期，直接读缓存的a.js，如果过期了，则执行协商缓存的步骤了。

强缓存总结

1.cache-control: max-age=xxxx，public
客户端和代理服务器都可以缓存该资源；
客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存,statu code:200 ，如果用户做了刷新操作，就向服务器发起http请求

2.cache-control: max-age=xxxx，private
只让客户端可以缓存该资源；代理服务器不缓存
客户端在xxx秒内直接读取缓存,statu code:200

3.cache-control: max-age=xxxx，immutable
客户端在xxx秒的有效期内，如果有请求该资源的需求的话就直接读取缓存,statu code:200 ，即使用户做了刷新操作，也不向服务器发起http请求

4.cache-control: no-cache
跳过设置强缓存，但是不妨碍设置协商缓存；一般如果你做了强缓存，只有在强缓存失效了才走协商缓存的，设置了no-cache就不会走强缓存了，每次请求都回询问服务端。

5.cache-control: no-store
不缓存，这个会让客户端、服务器都不缓存，也就没有所谓的强缓存、协商缓存了。

1.  协商缓存

上面说到的强缓存就是给资源设置个过期时间，客户端每次请求资源时都会看是否过期；只有在过期才会去询问服务器。所以当某天，客户端请求该资源时发现其过期了，这是就会去请求服务器了，而这时候去请求服务器的这过程就可以设置协商缓存。

触发条件：

1. Cache-Control 的值为 no-cache （不强缓存）
2. 或者 max-age 过期了 （强缓存，但总有过期的时候）

也就是说，不管怎样，都可能最后要进行协商缓存（no-store除外）

虽然强缓存命中，但是也有 ETag 和 Last-Modified ，这两个就是协商缓存的相关规则。

ETag（被请求变量的实体值）：每个文件有一个，改动文件了就变了，可以看似md5

Last-Modified：文件的修改时间

注意：为什么要有etag？
你可能会觉得使用last-modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要etag呢？HTTP1.1中etag的出现（也就是说，etag是新增的，为了解决之前只有If-Modified的缺点）主要是为了解决几个last-modified比较难解决的问题：

1.一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新get；

2.某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，if-modified-since能检查到的粒度是秒级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；

3.某些服务器不能精确的得到文件的最后修改时间。

 

 

每次http返回来 response header 中的 ETag和 Last-Modified，在下次请求时在 request header 就把这两个带上（但是名字变了ETag-->If-None-Match，Last-Modified-->If-Modified-Since ），服务端把你带过来的标识，资源目前的标识，进行对比，然后判断资源是否更改了。

这个过程是循环往复的，即缓存表在每次请求成功后都会更新规则。

1. 第n次请求成功时：

2. 缓存表中更新该资源的 ETag 值

3. 第n+1次请求：

从缓存表中取该资源最新的ETag，然后加在 request header 中, 注意变名字了，由 ETag -- > If-None-Match

协商缓存流程：

协商缓存步骤总结：

请求资源时，把用户本地该资源的 ETag 同时带到服务端，服务端和最新资源做对比。

如果资源没更改，返回304，浏览器读取本地缓存。

如果资源有更改，返回200，返回最新的资源。

注意：协商缓存无论如何，都要向服务端发请求的，只不过，资源未更改时，返回的只是header信息，所以size很小；而资源有更改时，还要返回body数据，所以size会大。

2.代理层   

cdn缓存就是在浏览器和服务器间增加的一层缓存，缓存一些html、图片、css、xml等静态资源。

无cdn：

   用户在浏览网站的时候，浏览器能够在本地缓存网站中的图片或者其他文件的副本，这样用户再次访问该网站的时候，浏览器就不用再下载全部的文件，减少了下载量意味着提高了页面加载的速度。

有cdn：

如果中间加上一层CDN，那么用户浏览器与服务器的交互如下：

客户端浏览器先检查是否有本地缓存是否过期，如果过期，则向CDN边缘节点发起请求，CDN边缘节点会检测用户请求数据的缓存是否过期，如果没有过期，则直接响应用户请求，此时一个完成http请求结束;如果数据已经过期，那么CDN还需要向源站发出回源请求(back to the source request),来拉取最新的数据。

2.1 CDN加速原理：

通过动态域名解析，网友的请求被分配到离自己最快的服务器。CDN服务器直接返回缓存文件或通过专线代理原站的内容。

网络加速+内容缓存，有效提供访问速度

2.2 CDN缓存什么内容：

缓存html、图片、css、xml等静态资源，不缓存含有？的动态地址、jsp、php，js文件也不缓存【除非特殊设置】

缓存原站返回HTTP状态为20*或304，不缓存其他状态(例如404，500，503)

2.3 CDN缓存的缺点：

CDN的分流作用不仅减少了用户的访问延时，也减少的源站的负载。但其缺点也很明显：当网站更新时，如果CDN节点上数据没有及时更新，即便用户再浏览器使用Ctrl +F5的方式使浏览器端的缓存失效，也会因为CDN边缘节点没有同步最新数据而导致用户访问异常。

 

 

 

 

 

扩展：