前言
为什么要使用缓存？
1. 可以加快页面打开速度
一个优秀的缓存策略可以缩短网页请求资源的距离（例如从本地缓存获取），降低延迟，从而实现页面打开速度；
2. 减少网络请求或减少冗余的数据传输
被缓存的文件在过期时间内是可以被重复利用的，可以减少对该资源的请求（减小服务器压力）或者只是请求验证该资源是否改变（未改变则没有响应体/减少冗余的数据传输）
浏览器缓存分为本地缓存（强缓存），协商缓存（再验证）两个阶段。
注：缓存机制主要在http响应头中设定，响应头中相关字段为Expires、Cache-Control、Last-Modified、Etag。
注：Cache-Control是通用头部（既可以是响应头也可以是请求头）
本地缓存
本地缓存的实现
HTTP 有两个响应首部用来控制浏览器是否进行本地缓存： Expires 和 Cache-Control。HTTP 允许原始服务器向每个文档附加一个“过期日期”，说明可以在多长时间内将这些内容视为新鲜的。
1. Expires
相对于 Cache-Control，Expires 是一个较老的首部（HTTP/1.0），其接受一个 Date 值指定文件的过期日期。该值是一个绝对日期，浏览器判断文件是否过期时，对比的是用户机器上的时间而不是服务器上的时间。所以使用 Expires 首部可能会出现的一个问题就是，用户本地时间是会影响到原先的缓存意图的。
2.Cache-Control
为了解决Expires 的问题，HTTP/1.1 的Cache-Control应运而生。Cache-Control 接受一个秒数作为文档的生存时间。这个时间是一个相对时间，一个倒计时的秒数，不依赖于机器时间。
启用本地缓存时，选用其中一个首部即可，推荐使用较新的 Cache-Control 。如果同时使用 Expires 和 Cache-Control 首部，那么浏览器将以优先值更高的 Cache-Control为准。
如果文件是通过缓存获得的，network 上该资源的请求会显示200 OK (from disk/memory cache)，此时该请求是不会发送到原始服务器的。
from disk cache：一般非脚本会存在内存当中，如css，html等from memory cache：资源在内存当中，一般脚本、字体、图片会存在内存当
Cache-Control 控制缓存的能力
Cache-Control 有一些可选值，可以用来控制缓存方式。
-
Cache-Control: no-store，标识为 no-store 的响应会禁止缓存对响应进行拷贝。 -
Cache-Contro: no-cache，标识为 no-cache 的响应实际上是可以存储在本地缓存区中的。只是在与原始服务器进行新鲜度再验证之前，缓存不能将其提供给客户端使用。这个首部使用 do-not-serve-from-cache-without-revalidation 这个名字会更恰当一些。 -
Cache-Control: max-age，表示的是从服务器将文档传来之时起，可以认为此文档处于新鲜状态的秒数。 -
Cache-Control：must-revalidate，可配置缓存，这个响应首部告诉缓存，在实现没有跟原始服务器进行再验证的情况下，不能使用这个对象的陈旧副本。服务器通过返回 304 Not Modified 可以让客户端使用缓存陈旧（过期）的文档，以提高性能。当然，服务器也可以随意提供新鲜的副本。如果在缓存进行 must-revalidate 新鲜度检查时，原始服务器不可用，缓存就必须返回一条 504 Gateway Timeout 错误。
本地缓存会有缓存命中和缓存未命中两种情况
协商缓存
协商缓存就是当本地缓存超过缓存期限后，此时用户再次发起该资源的请求的话，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否继续使用该本地缓存的过程；
根据服务器上的该资源是否发生更新，浏览器响应分为两种情况：
- 当服务器的资源
未发生更新时(协商缓存生效)，服务器会返回304 Not Modified响应，不会返回文档的主体，这样一来，网络请求效率就会比普通 GET 请求高一点。
- 当服务器的资源
发生更新时（协商缓存失效），服务器会返回200响应，并在报文体中携带新的文件内容，这种情况下，与普通 GET 请求获取资源效率无异。
协商缓存的实现
协商缓存可以通过设置两种 HTTP Response/Request Header 实现：Last-Modified/If-Modified-Since 和 ETag/If-None-Match 。
Last-Modified/If-Modified-Since
浏览器在第一次访问资源时，服务器返回资源的同时，在
response header中添加一个属性名为 Last-Modified的header，其属性值是这个资源在服务器上的最后修改时间；
浏览器下一次请求这个资源，浏览器检测到有 Last-Modified这个header，于是添加If-Modified-Since这个header，值就是Last-Modified中的值；
服务器再次收到这个资源请求，会根据 If-Modified-Since 中的值与服务器中这个资源的最后修改时间对比，如果没有变化，返回304和空的响应体，直接从缓存读取，如果If-Modified-Since的时间小于服务器中这个资源的最后修改时间，说明文件有更新，于是返回新的资源文件和200
Last-Modified的问题
- 如果本地打开缓存文件，即使没有对文件进行修改，但还是会造成 Last-Modified 被修改，服务端不能命中缓存导致发送相同的资源
- 因为 Last-Modified 只能以秒计时，如果在不可感知的时间内修改完成文件，那么服务端会认为资源还是命中了，不会返回正确的资源
既然根据文件修改时间来决定是否缓存尚有不足，能否可以直接根据文件内容是否修改来决定缓存策略？所以在 HTTP / 1.1 出现了 ETag 和If-None-Match
ETag/If-None-Match
Etag是服务器响应资源请求时，返回当前资源文件的一个唯一标识(由服务器生成)，只要该资源有变化，Etag就会重新生成。
浏览器在第一次访问资源时，服务器返回资源的同时，在
response header中添加一个属性名为ETag的header，其属性值是这个资源在服务器上的最后一次修改时生成的唯一标识；
浏览器在下一次加载资源向服务器发送请求时，会将上一次返回的Etag值放到
request header里的If-None-Match里。
服务器只需要比较客户端传来的
If-None-Match跟自己服务器上该资源的ETag是否一致，就能很好地判断资源相对客户端而言是否被修改过了。如果服务器发现ETag匹配不上，那么直接以常规GET 200回包形式将新的资源（当然也包括了新的ETag）发给客户端；如果ETag是一致的，则直接返回304知会客户端直接使用本地缓存即可。
两种协商缓存之间的对比：
- 首先在精确度上，Etag要优于Last-Modified。
- 第二在性能上，Etag要逊于Last-Modified，毕竟Last-Modified只需要记录时间，而Etag需要服务器通过算法来计算出一个hash值。
- 第三在优先级上，服务器校验优先考虑Etag
缓存流程
强制缓存优先于协商缓存进行，若强制缓存(Expires和Cache-Control)生效则直接使用缓存，若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match)，协商缓存由服务器决定是否使用缓存，若协商缓存失效，那么代表该请求的缓存失效，返回200，重新返回资源和缓存标识，再存入浏览器缓存中；生效则返回304，继续使用缓存。
- 在浏览器第一次发起请求时，本地无缓存，向web服务器发送请求，服务器起端响应请求，浏览器端缓存。过程如下：
- 浏览器后续再次进行请求时：
疑问
Q：如果什么缓存策略都没设置，那么浏览器会怎么处理？
A：对于这种情况，浏览器会采用一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间。
用户行为对浏览器缓存的影响
参考：
http://www.yangzicong.com/article/12
https://www.jianshu.com/p/54cc04190252
https://www.cnblogs.com/slly/p/6732749.html
https://juejin.im/post/5ccfccaff265da03ab233bf5
