ThinkChat2.0新版上线,更智能更精彩,支持会话、画图、阅读、搜索等,送10W Token,即刻开启你的AI之旅 广告
[TOC] ## 强制缓存控制字段: 控制强制缓存的字段分别是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秒后失效 接下来,我们直接看一个例子,如下: ![](https://img.kancloud.cn/0f/70/0f70b5d7eafda3f0f972ce5621fd4ca1_640x291.png) 由上面的例子我们可以知道: * HTTP响应报文中expires的时间值,是一个绝对值 * HTTP响应报文中Cache-Control为max-age=600,是相对值 由于Cache-Control的优先级比expires,那么直接根据Cache-Control的值进行缓存,意思就是说在600秒内再次发起该请求,则会直接使用缓存结果,强制缓存生效。 注:在无法确定客户端的时间是否与服务端的时间同步的情况下,Cache-Control相比于expires是更好的选择,所以同时存在时,只有Cache-Control生效。 了解强制缓存的过程后,我们拓展性的思考一下: > 浏览器的缓存存放在哪里,如何在浏览器中判断强制缓存是否生效? ![](https://img.kancloud.cn/88/25/8825618d53779e30d30ca055657e4c97_1007x442.png) 这里我们以博客的请求为例,状态码为灰色的请求则代表使用了强制缓存,请求对应的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。 虽然我已经直接把结论说出来了,但是相信有不少人对此不能理解,那么接下来我们一起详细分析一下缓存读取问题,这里仍让以我的博客为例进行分析: 访问https://heyingye.github.io/ –> 200 –> 关闭博客的标签页 –> 重新打开https://heyingye.github.io/ –> 200(from disk cache) –> 刷新 –> 200(from memory cache) 过程如下: * 访问https://heyingye.github.io/ ![](https://img.kancloud.cn/f0/a5/f0a5cd7b26b623f3893a3046dfdcf5e5_1003x433.png) * 关闭博客的标签页 * 重新打开https://heyingye.github.io/ ![](https://img.kancloud.cn/2a/9b/2a9bd836eb438dfd8b1bb4ecdbfcaa63_1001x435.png) * 刷新 ![](https://img.kancloud.cn/f9/13/f9136d7665d133b61ed7972a38beda72_1005x434.png) from disk memory > 看到这里可能有人小伙伴问了,最后一个步骤刷新的时候,不是同时存在着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)。 ## 协商缓存控制字段: 协商缓存的标识也是在响应报文的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是服务器响应请求时,返回该资源文件在服务器最后被修改的时间,如下。 ![](https://img.kancloud.cn/38/d2/38d2ce64df20ec4d60d5b415656e599c_596x271.png) last-modify If-Modified-Since则是客户端再次发起该请求时,携带上次请求返回的Last-Modified值,通过此字段值告诉服务器该资源上次请求返回的最后被修改时间。服务器收到该请求,发现请求头含有If-Modified-Since字段,则会根据If-Modified-Since的字段值与该资源在服务器的最后被修改时间做对比,若服务器的资源最后被修改时间大于If-Modified-Since的字段值,则重新返回资源,状态码为200;否则则返回304,代表资源无更新,可继续使用缓存文件,如下。 ![](https://img.kancloud.cn/5c/ba/5cbad4eb760e4c14b411062fbea99e30_667x347.png) If-Modified-Since ##### Etag / If-None-Match Etag是服务器响应请求时,返回当前资源文件的一个唯一标识(由服务器生成),如下。 ![](https://img.kancloud.cn/34/ad/34ad6e43252488cd4a7af264b39446ec_666x351.jpg) Etag If-None-Match是客户端再次发起该请求时,携带上次请求返回的唯一标识Etag值,通过此字段值告诉服务器该资源上次请求返回的唯一标识值。服务器收到该请求后,发现该请求头中含有If-None-Match,则会根据If-None-Match的字段值与该资源在服务器的Etag值做对比,一致则返回304,代表资源无更新,继续使用缓存文件;不一致则重新返回资源文件,状态码为200,如下。 ![](https://img.kancloud.cn/f7/ca/f7cadcd0ddfec0d82a1a59d3c9e6182f_659x400.png) Etag-match 注:Etag / If-None-Match优先级高于Last-Modified / If-Modified-Since,同时存在则只有Etag / If-None-Match生效。 ## 总结 强制缓存优先于协商缓存进行,若强制缓存(Expires和Cache-Control)生效则直接使用缓存,若不生效则进行协商缓存(Last-Modified / If-Modified-Since和Etag / If-None-Match),协商缓存由服务器决定是否使用缓存,若协商缓存失效,那么代表该请求的缓存失效,重新获取请求结果,再存入浏览器缓存中;生效则返回304,继续使用缓存,主要过程如下: ![](https://img.kancloud.cn/02/c1/02c1ccc1fe0f72f880e3beeea864614d_946x640.png)