浏览器的缓存机制即是HTTP的缓存机制，因为其完全是由HTTP来控制的。
概述
浏览器的缓存机制也就是我们说的HTTP缓存机制，其机制是根据HTTP报文的缓存标识进行的，所以在分析浏览器缓存机制之前，我们先使用图文简单介绍一下HTTP报文，HTTP报文分为两种：
HTTP请求(Request)报文，报文格式为：请求行 – HTTP头(通用信息头，请求头，实体头) – 请求报文主体(只有POST才有报文主体)，如下图
HTTP响应(Response)报文，报文格式为：状态行 – HTTP头(通用信息头，响应头，实体头) – 响应报文主体，如下图
注：
通用信息头指的是请求和响应报文都支持的头域，分别为Cache-Control、Connection、Date、Pragma、Transfer-Encoding、Upgrade、Via；
实体头则是实体信息的实体头域，分别为Allow、Content-Base、Content-Encoding、Content-Language、Content-Length、Content-Location、Content-MD5、Content-Range、Content-Type、Etag、Expires、Last-Modified、extension-header。
这里只是为了方便理解，将通用信息头，响应头/请求头，实体头都归为了HTTP头。
为什么需要浏览器缓存
我们知道通过HTTP协议，在客户端和浏览器建立连接时需要消耗时间，而大的响应需要在客户端和服务器之间进行多次往返通信才能获得完整的响应，这拖延了浏览器可以使用和处理内容的时间。这就增加了访问服务器的数据和资源的成本，因此利用浏览器的缓存机制重用以前获取的数据就变成了性能优化时需要考虑的事情。
缓存的位置
service worker:单独的一个线程，用来实现缓存功能；
memory cache:内存中的缓存；容量小，存储时间短；
disk cache:硬盘上的缓存，容量大，时效性长；（绝大部分的缓存都来自 Disk Cache，与HTTP的缓存策略有很大的关联）
缓存过程分析
浏览器与服务器通信的方式为应答模式，即是：浏览器发起HTTP请求 – 服务器响应该请求。那么浏览器第一次向服务器发起该请求后拿到请求结果，会根据响应报文中HTTP头的缓存标识，决定是否缓存结果，是则将请求结果和缓存标识存入浏览器缓存中，简单的过程如下图：
由上图我们可以知道：
- 浏览器每次发起请求，都会
先在浏览器缓存中查找该请求的结果以及缓存标识 - 浏览器每次拿到返回的请求结果都会
将该结果和缓存标识存入浏览器缓存中
以上两点结论就是浏览器缓存机制的关键，他确保了每个请求的缓存存入与读取，只要我们再理解浏览器缓存的使用规则，那么所有的问题就迎刃而解了。为了方便理解，这里根据是否需要向服务器重新发起HTTP请求将缓存过程分为两个部分，分别是强制缓存和协商缓存。
强制缓存
定义
当发起HTTP请求时，不会向服务器进行请求，只要当前时间在缓存有效期内，则直接从客户端缓存中获得，当缓存过期之后，才会真正想服务器发起请求重新获得资源。
特征
打开开发者工具，从Network中可查看到，HTTP请求返回的状态码为200并且后面跟着from memory cache 或 from disk cache。
强缓存
强制缓存就是向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程。
强制缓存的情况主要有三种(暂不分析协商缓存过程)，如下：
- 不存在该缓存结果和缓存标识，强制缓存失效，则直接向服务器发起请求（跟第一次发起请求一致），如下图：
- 存在该缓存结果和缓存标识，但该结果已失效，强制缓存失效，则使用协商缓存(暂不分析)，如下图
- 存在该缓存结果和缓存标识，且该结果尚未失效，强制缓存生效，直接返回该结果，如下图
那么强制缓存的缓存规则是什么？
当浏览器向服务器发起请求时，服务器会将缓存规则放入HTTP响应报文的HTTP头中和请求结果一起返回给浏览器，控制强制缓存的字段分别是Expires和Cache-Control，其中Cache-Control优先级比Expires高。
Expires
Expires是HTTP/1.0控制网页缓存的字段，其值为服务器返回该请求结果缓存的到期时间，即再次发起该请求时，如果客户端的时间小于Expires的值时，直接使用缓存结果。
Expires是HTTP/1.0的字段，但是现在浏览器默认使用的是HTTP/1.1，那么在HTTP/1.1中网页缓存还是否由Expires控制？
到了HTTP/1.1，Expire已经被Cache-Control替代，原因在于Expires控制缓存的原理是使用客户端的时间与服务端返回的时间做对比，那么如果客户端与服务端的时间因为某些原因（例如时区不同；客户端和服务端有一方的时间不准确）发生误差，那么强制缓存则会直接失效，这样的话强制缓存的存在则毫无意义，那么Cache-Control又是如何控制的呢？
Cache-Control
在HTTP/1.1中，Cache-Control是最重要的规则，主要用于控制网页缓存，主要取值为：
- public：所有内容都将被缓存（客户端和代理服务器都可缓存）
- private：所有内容只有客户端可以缓存，Cache-Control的默认取值
- no-cache：客户端缓存内容，但是是否使用缓存则需要经过协商缓存来验证决定
- no-store：所有内容都不会被缓存，即不使用强制缓存，也不使用协商缓存
- max-age=xxx (xxx is numeric)：缓存内容将在xxx秒后失效
接下来，我们直接看一个例子，如下：
由上面的例子我们可以知道：
- HTTP响应报文中expires的时间值，是一个绝对值
- HTTP响应报文中Cache-Control为max-age=600，是相对值
由于Cache-Control的优先级比expires，那么直接根据Cache-Control的值进行缓存，意思就是说在600秒内再次发起该请求，则会直接使用缓存结果，强制缓存生效。
Expires和Cache-Control两者对比
Expires 是http1.0的产物，Cache-Control是http1.1的产物。Expires其实是过时的产物，现阶段它的存在只是一种兼容性的写法。两者同时存在的话，Cache-Control优先级高于Expires；
由于HTTP版本的升级，在HTTP1之前,指定资源到期的时间是Expires，注意：到期时间是指在响应请求返回的服务器的时间，当客户端再次发起请求时，会拿本地时间与缓存过期时间比较，如果在有效期内，则直接从客户端本地读取缓存数据，这也就意味着：你可以通过更改本地系统时间，强制控制缓存失效。
在请求头或响应头中设置Cache-Control，Cache-Control是HTTP/1.1新增的字段，主要用于控制网页缓存。Cache-Control的作用是指定请求或响应的缓存机制，它具有单向性，也就是说，如果你在请求中头设置了该属性，它却不一定会在响应头中存在。它的设置方式有两种，一种是通过客户端设置，一种是在服务端接收到请求后在服务端设置，两种设置方法的可选值不同，根据 MDN 解释，具体情况如下：
可选值中含义具体可参考MDN： https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control
强缓存有什么作用
1）对于页面上耗费带宽且不常更改的资源，一旦下载，可直接将其缓存在浏览器，用户再次使用，可大大降低加载等待时间，提升用户体验；
2）针对弱网或网络不稳定的用户，强缓存可预留出足够的带宽，让给主资源请求，防止因主资源请求超时导致页面无法正常显示。
弊端
强缓存的优点就是，只要客户端存在有效期内的资源，就不再从服务端获取资源，而他的优点也正是他的弊端，如果服务器资源更新了，或者修正了一个bug,而强制缓存时间太长，就会造成客户端信息更新落后的问题，怎么办呢？能不能有一个这样的解决方法：每次请求资源，先问问服务器：我需要重新拿资源吗？服务器通过标识对比，缓存数据没有更改，缓存时间也没过期，然后告诉客户端，继续用存储的数据吧，我这没啥变更。这样既解决了缓存问题，也解决了更新问题。虽然依然是每次都发送请求，请求数量没减少，但是却可以降低数据量传输。有这样的方案吗？有。叫什么？协商缓存。
小结
强缓存下，无论是从客户端获取的资源还是从服务器端获取的更新资源，在获取成功时，返回的状态码都是200，唯一能区分的，是跟在状态码后面有没有from memory cache 或 from disk cache.在有效期内，只有第一次会真正向服 务器发送请求获取数据
了解强制缓存的过程后，我们拓展性的思考一下：
浏览器的缓存存放在哪里，如何在浏览器中判断强制缓存是否生效？
这里我们以博客的请求为例，状态码为灰色的请求则代表使用了强制缓存，请求对应的Size值则代表该缓存存放的位置，分别为from memory cache 和 from disk cache。
那么from memory cache 和 from disk cache又分别代表的是什么呢？什么时候会使用from disk cache，什么时候会使用from memory cache呢？
from memory cache代表使用内存中的缓存，from disk cache则代表使用的是硬盘中的缓存，浏览器读取缓存的顺序为memory –> disk。
from disk cache和from memory cache 可能同时存在着？
对于这个问题，我们需要了解内存缓存(from memory cache)和硬盘缓存(from disk cache)，如下:
-
内存缓存(from memory cache)：内存缓存具有两个特点，分别是快速读取和时效性：- 快速读取：内存缓存会将编译解析后的文件，直接存入该进程的内存中，占据该进程一定的内存资源，以方便下次运行使用时的快速读取。
- 时效性：一旦该进程关闭，则该进程的内存则会清空。
-
硬盘缓存(from disk cache)：硬盘缓存则是直接将缓存写入硬盘文件中，读取缓存需要对该缓存存放的硬盘文件进行I/O操作，然后重新解析该缓存内容，读取复杂，速度比内存缓存慢。
在浏览器中，浏览器会在js和图片等文件解析执行后直接存入内存缓存中，那么当刷新页面时只需直接从内存缓存中读取(from memory cache)；而css文件则会存入硬盘文件中，所以每次渲染页面都需要从硬盘读取缓存(from disk cache)。
协商缓存
协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程，主要有以下两种情况：
协商缓存生效，返回304，如下
304
协商缓存失效，返回200和请求结果结果，如下
200
同样，协商缓存的标识也是在响应报文的HTTP头中和请求结果一起返回给浏览器的，控制协商缓存的字段分别有：Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高。
Last-Modified / If-Modified-Since
Last-Modified是服务器响应请求时，返回该资源文件在服务器最后被修改的时间，如下。
last-modify
If-Modified-Since则是客户端再次发起该请求时，携带上次请求返回的Last-Modified值，通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。服务器收到该请求，发现请求头含有If-Modified-Since字段，则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比，若服务器的资源最后被修改时间大于If-Modified-Since的字段值，则重新返回资源，状态码为200；否则则返回304，代表资源无更新，可继续使用缓存文件，如下。
If-Modified-Since
Etag / If-None-Match
Etag是服务器响应请求时，返回当前资源文件的一个唯一标识(由服务器生成)，如下。
Etag的工作原理
如上图，服务器在第一次返回响应的时候设置了缓存的时间120s，假设浏览器在这120s经过之后再次请求服务器相同的资源，首先，浏览器会检查本地缓存并找到之前的响应，不幸的是，这个响应现在已经’过期’，无法在使用。此时，浏览器也可以直接发出新请求，获取新的完整响应，但是这样做效率较低，因为如果资源未被更改过，我们就没有理由再去下载与缓存中已有的完全相同的字节。
于是就到了Etag发挥作用的时候了，通常服务器生成并返回在Etag中的验证码，常常是文件内容的哈希值或者某个其他指纹码。客户端不必了解指纹码是如何生成的，只需要在下一个请求中将其发送给服务器(浏览器默认会添加)：如果指纹码仍然一致，说明资源未被修改，服务器会返回304 Not Modified，这样我们就可以跳过下载，利用已经缓存了的资源，并且该资源会继续缓存120s。
If-None-Match是客户端再次发起该请求时，携带上次请求返回的唯一标识Etag值，通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后，发现该请求头中含有If-None-Match，则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比，一致则返回304，代表资源无更新，继续使用缓存文件；不一致则重新返回资源文件，状态码为200，如下。
Etag-match
注：Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since，同时存在则只有Etag / If-None-Match生效。
如何设置为协商缓存
response header里面的设置
etag: '5c20abbd-e2e8'
last-modified: Mon, 24 Dec 2018 09:49:49 GMT
etag：每个文件有唯一一个，资源变更则etag变更。是一个文件hash,加上的目的就是为了对比客户端和服务端是否一致，判断是有更新，不一致则认为是更新了，一致则认为未更改。 last-modified：文件的修改时间，精确到秒。
也就是说，每次请求返回来 response header 中的 etag和 last-modified，在下次请求时在 request header 就把这两个带上，服务端把你带过来的标识进行对比，然后判断资源是否更改了，如果更改就直接返回新的资源，和更新对应的response header的标识etag、last-modified。如果资源没有变，那就不变etag、last-modified，这时候对客户端来说，每次请求都是要进行协商缓存了，即：
发请求-->看资源是否过期-->过期-->请求服务器-->服务器对比资源是否真的过期-->没过期-->返回304状态码-->客户端用缓存的老资源。
这就是一条完整的协商缓存的过程。
当服务端发现资源真的过期的时候，会走如下流程：
发请求-->看资源是否过期-->过期-->请求服务器-->服务器对比资源是否真的过期-->过期-->返回200状态码-->客户端如第一次接收该资源一样，记下它的cache-control中的max-age、etag、last-modified等。
所以协商缓存步骤总结：
请求资源时，把用户本地该资源的 etag 同时带到服务端，服务端和最新资源做对比。 如果资源没更改，返回304，浏览器读取本地缓存。 如果资源有更改，返回200，返回最新的资源。
为什么要有etag
你可能会觉得使用last-modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要etag呢？HTTP1.1中etag的出现（也就是说，etag是新增的，为了解决之前只有If-Modified的缺点）主要是为了解决几个last-modified比较难解决的问题：
1）一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新get；
2）某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，if-modified-since能检查到的粒度是秒级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
3）某些服务器不能精确的得到文件的最后修改时间。
小结
协商缓存首次请求成功会返回状态码200，在接下来，如果文件未更改，则会返回状态码为304，因此可以通过判断状态码值来确定资源是重新更新的还是来自缓存。另外，由于标识资源是否有效的last-modify和etag都是由服务端确定，因此，协商缓存不会受制于本地系统时间的更改。
总结
浏览器缓存分为强制缓存和协商缓存，强制缓存优先于协商缓存进行。
- 若强制缓存(Expires和Cache-Control,Cache-Control优先级高于Expires)生效则直接使用缓存
- 若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match，其中Etag / If-None-Match的优先级比Last-Modified / If-Modified-Since高)，协商缓存由服务器决定是否使用缓存
- 若协商缓存失效，那么代表该请求的缓存失效，重新获取请求结果，再存入浏览器缓存中；生效则返回304，继续使用缓存
主要过程如下：
