浏览器缓存

缓存的优点：

• 减少了不必要的数据传输，节省带宽
• 减少服务器的负担，提升网站性能
• 加快了客户端加载网页的速度
• 用户体验友好

缺点：

• 资源如果有更改但是客户端不及时更新会造成用户获取信息滞后，如果老版本有bug的话，情况会更加糟糕。

浏览器的三级缓存原理：

1. 先找内存；2.再找硬盘；3.进行网络请求

强缓存

expires：

expires是http1.0的产物，cache-control是http1.1的产物，cache-control的优先级高于expires，现阶段的存在只是一种兼容 的写法。expires设置的是具体的服务器的时间，如果客户端和服务器相差时间过大，缓存命中与否就不是开发者所希望的，而cache-control设置的是一个时间段，控制比较容易。

cache-control：

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

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

cache-control: max-age=xxxx，private
**只让客户端可以缓存该资源；**代理服务器不缓存
客户端在xxx秒内直接读取缓存,statsu code:200，如果用户做了刷新操作，就向服务器发起http请求

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

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

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

协商缓存

而当某天，客户端请求该资源时发现强缓存过期了，这时就会去请求服务器了，这时去请求服务器的过程就可以设置协商缓存。这时候，协商缓存就是需要客户端和服务器两端进行交互的。

response header里面的设置

etag: '5c20abbd-e2e8'
last-modified: Mon, 24 Dec 2018 09:49:49 GMT

etag：

每个文件有一个，改动文件就变了，就是个文件hash，每个文件唯一，就像用webpack打包的时候，每个资源都会有这个东西，如： app.js打包后变为 app.c20abbde.js，加个唯一hash，也是为了解决缓存问题。

last-modified：

文件的修改时间，精确到秒。
也就是说，每次请求返回来 response header 中的 etag和 last-modified，在下次请求时在 request header 就把这两个带上，服务端把你带过来的标识进行对比，然后判断资源是否更改了。

1. 如果更改就直接返回新的资源，和更新对应的response header的标识etag、last-modified，返回200状态码。
2. 如果资源没有变，那就返回304状态码，客户端使用缓存中的资源

补充：response header中的etag、last-modified在客户端重新向服务端发起请求时，会在request header中换个key名：

// response header
etag: '5c20abbd-e2e8'
last-modified: Mon, 24 Dec 2018 09:49:49 GMT

// request header 变为
if-none-matched: '5c20abbd-e2e8'
if-modified-since: Mon, 24 Dec 2018 09:49:49 GMT

为什么要有etag？
HTTP1.1中etag的出现主要是为了解决几个last-modified比较难解决的问题：

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

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

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