都9012了，据说你还不了解缓存？

前言：

前端er须要关注的点：缓存

这真是一个令开发者又爱又恨的东西
现代手机随时随地会缓存你的资源，可是要想清缓存，不能像PC使用强制刷新，你须要手动清理浏览器缓存，甚至有时候还要重启...
因此理解缓存机制并可以掌控它就显的相当重要（比较牛逼了）

下面咱们将先通读理论而后结合实践真正理解缓存机制

下文会涉及到

• DNS缓存
• CDN缓存
• 浏览器缓存(HTTP缓存)

DNS缓存

什么是DNS？

全称 Domain Name System 域名解析系统
它的做用很是简单，就是根据域名查出IP地址

DNS解析

简单的说，经过域名最终解析到该域名对应的IP地址

www.dnscache.com (域名)  - DNS解析 -> 11.222.33.444 (IP地址)
复制代码

DNS缓存

有DNS的地方,就有缓存! 浏览器、操做系统、Local DNS、根域名服务器，它们都会对DNS结果作必定程度的缓存

DNS查询过程

1. 首先搜索浏览器自身的DNS缓存,若是存在，则域名解析到此完成。
2. 若是浏览器自身的缓存里面没有找到对应的条目，那么会尝试读取操做系统的hosts文件看是否存在对应的映射关系,若是存在，则域名解析到此完成。
3. 若是本地hosts文件不存在映射关系，则查找本地DNS服务器(ISP服务器,或者本身手动设置的DNS服务器),若是存在,域名到此解析完成。
4. 若是本地DNS服务器还没找到的话,它就会向根服务器发出请求,进行递归查询。

CDN缓存

什么是CDN？

全称 Content Delivery Network,即内容分发网络。 相似于火车站代售点，乘客不用再去售票大厅去排队买票 减轻了售票大厅的压力（起到分流做用,减轻服务器负载压力）

用户在浏览网站的时候，CDN会选择一个离用户最近的CDN边缘节点来响应用户的请求，这样海南移动用户的请求就不会千里迢迢跑到北京电信机房的服务器（假设源站部署在北京电信机房）上了

CDN缓存

当浏览器本地缓存失效,浏览器会向CDN边缘节点发起请求。相似浏览器缓存,CDN边缘节点也存在着一套缓存机制

CDN边缘节点缓存策略因服务商不一样而不一样，但通常都会遵循http标准协议，经过http响应头中的 Cache-control: max-age的字段来设置CDN边缘节点数据缓存时间。

CDN边缘节点数据缓存机制

• 当浏览器向CDN节点请求数据时，CDN节点会判断缓存数据是否过时，
• 未过时：直接将缓存数据返回给客户端；
• 过时：CDN节点向服务器发出回源请求，拉取最新数据同时更新本地缓存，并将最新数据返回给客户端。

CDN服务商通常会提供基于文件后缀、目录多个维度来指定CDN缓存时间，为用户提供更精细化的缓存管理。

CDN 优点

1. CDN节点解决了跨运营商和跨地域访问的问题，访问延时大大下降。
2. 大部分请求在CDN边缘节点完成，CDN起到了分流做用，减轻了源服务器的负载。

浏览器缓存（HTTP缓存）

盯着这张图

什么是浏览器缓存？

浏览器缓存其实就是浏览器保存经过HTTP获取的全部资源,是浏览器将网络资源存储在本地的一种行为。

缓存的资源去哪里了?

你可能会有疑问,浏览器存储了资源,那它把资源存储在哪里呢？

• memory cache

MemoryCache顾名思义，就是将资源缓存到内存中，等待下次访问时不须要从新下载资源，而直接从内存中获取。Webkit早已支持memoryCache。
目前Webkit资源分红两类，一类是主资源，好比HTML页面，或者下载项，一类是派生资源，好比HTML页面中内嵌的图片或者脚本连接，分别对应代码中两个类：MainResourceLoader和SubresourceLoader。虽然Webkit支持memoryCache，可是也只是针对派生资源，它对应的类为CachedResource，用于保存原始数据（好比CSS，JS等），以及解码过的图片数据。
复制代码

• disk cache

DiskCache顾名思义，就是将资源缓存到磁盘中，等待下次访问时不须要从新下载资源，而直接从磁盘中获取，它的直接操做对象为CurlCacheManager。
复制代码

访问缓存优先级

1. 先在内存中查找,若是有,直接加载。
2. 若是内存中不存在,则在硬盘中查找,若是有直接加载。
3. 若是硬盘中也没有,那么就进行网络请求。
4. 请求获取的资源缓存到硬盘和内存。

浏览器缓存的分类

• 强缓存
• 协商缓存

须要说明的是 浏览器会先判断是否命中强缓存

浏览器缓存的优势

1. 减小了冗余的数据传输 节省了网费
2. 减小了服务器的负担，大大提高了网站的性能
3. 加快了客户端加载网页的速度

浏览器在第一次请求发生后，再次请求时：

1. 验证是否命中强缓存，若是命中，就直接使用缓存了。
2. 若是没有命中强缓存，就发请求到服务器检查是否命中协商缓存。
3. 若是命中协商缓存，服务器会返回 304 告诉浏览器使用本地缓存。
4. 不然，返回最新的资源。

强缓存

强缓存是利用http的返回头中的Expires或者Cache-Control两个字段来控制的，用来表示资源的缓存时间。

Expires： 该字段是http1.0时的规范，它的值为一个绝对时间的GMT格式的时间字符串，好比Expires:Mon,18 Oct 2066 23:59:59 GMT。这个时间表明着这个资源的失效时间，在此时间以前即命中缓存

缺点：

1. 因为失效时间是一个绝对时间，因此当服务器与客户端时间误差较大时，就会致使缓存混乱

Cache-Control： Cache-Control是http1.1时出现的header信息，主要是利用该字段的max-age值来进行判断，它是一个相对时间，例如Cache-Control:max-age=3600，表明着资源的有效期是3600秒。cache-control除了该字段外，还有下面几个比较经常使用的设置值：

• no-cache：不使用本地缓存。须要使用缓存协商，先与服务器确认返回的响应是否被更改，若是以前的响应中存在ETag，那么请求的时候会与服务端验证，若是资源未被更改，则能够避免从新下载。
• no-store：直接禁止游览器缓存数据，每次用户请求该资源，都会向服务器发送一个请求，每次都会下载完整的资源。
• public：能够被全部的用户缓存，包括终端用户和CDN等中间代理服务器。
• private：只能被终端用户的浏览器缓存，不容许CDN等中继缓存服务器对其缓存。

Cache-Control与Expires能够在服务端配置同时启用，同时启用优先级 Cache-Control > Expires

协商缓存

当强缓存没有命中的时候，浏览器会发送一个请求到服务器，服务器根据 header 中的部分信息来判断是否命中缓存。若是命中，则返回304 ，告诉浏览器资源未更新，可以使用本地的缓存。

header： `Last-Modify/If-Modify-Since `和 `ETag/If-None-Match`
复制代码

Last-Modify/If-Modify-Since：浏览器第一次请求一个资源的时候，服务器返回的 header 中会加上 Last-Modify，Last-modify 是一个时间标识该资源的最后修改时间。 当浏览器再次请求该资源时，request 的请求头中会包含 If-Modify-Since，该值为缓存以前返回的 Last-Modify。服务器收到 If-Modify-Since 后，根据资源的最后修改时间判断是否命中缓存。 若是命中缓存，则返回 304，而且不会返回资源内容，而且不会返回 Last-Modify。

缺点:

1. 短期内资源发生了改变,Last-Modified并不会发生变化。
2. 周期性变化,若是这个资源在一个周期内修改回原来的样子了，咱们认为是可使用缓存的，可是 Last-Modified 可不这样认为,所以便有了 ETag

ETag/If-None-Match 与 Last-Modify/If-Modify-Since 不一样的是，Etag/If-None-Match返回的是一个校验码。ETag 能够保证每个资源是惟一的，资源变化都会致使 ETag变化。服务器根据浏览器上送的 If-None-Match 值来判断是否命中缓存。 与 Last-Modified 不同的是，当服务器返回 304 Not Modified的响应时，因为 ETag从新生成过，response header中还会把这个 ETag 返回，即便这个 ETag 跟以前的没有变化。

Last-Modified 与 ETag 是能够一块儿使用的，服务器会优先验证 ETag，一致的状况下，才会继续比对 Last-Modified，最后才决定是否返回 304。

实践检验

我讨厌文字记忆，因此坚决果断选了理工科～～ talk is cheap , show me your code

⚠️ 实践过程控制台不要禁用缓存

利用koa启动server服务 port：8000

引入静态资源 加载前端模版 去内蒙的航拍 哈哈哈 有我

如图可见 初次访问 正常加载模版页面 cache与图片资源 1.jpeg

实现强缓存

1. 服务端设置响应头Cache-Control 资源有效期为300秒

app.use(async (ctx, next) => {
  ctx.set({
    'Cache-Control': 'max-age=300'  
  });
  await next();
});
复制代码

2. 刷新页面

响应头的 Cache-Control变成了 max-age=300

验证访问缓存的优先级: 第一次的网络请求,浏览器把图片资源缓存到了磁盘和内存里，根据约定 应该会先从内存中找资源

3. 再次刷新页面

确实是从内存获取的

4.关掉页面再从新打开 （内存是存在进程中的,因此关闭该页面,内存中的资源也被释放掉了,磁盘中的资源是永久性的,因此还存在）

from disk cache 从磁盘中获取资源

5.接下来 有效期 300秒 后.

缓存失效 从新向服务器载入资源

实现协商缓存 协商缓存本地测试直接拦截url给定code

Cache-Control 取默认值 no-cache

app.use( async(ctx, next) => {
// 协商缓存测试
if(ctx.url === '/imgs/1.jpeg'){
  ctx.status = 304;
  return;
}
await next();
});
复制代码

服务器返回304 同时size变小了不少 由于只返回了必要信息

也可利用现成的插件帮咱们计算文件的ETag

npm install koa-tag -D
npm install koa-conditional-get -D
复制代码

具体细节不演示了

经测试发现当加载资源发生变化时（好比换了张图片），ETag改变了进而协商缓存策略失效了

动手试一下 理解并掌握它！

写在最后的话

day day up ！