缓存策略：强缓存&协商缓存

最新推荐文章于 2024-09-02 19:01:02 发布

他夏了夏天lll

最新推荐文章于 2024-09-02 19:01:02 发布

阅读量369

点赞数 1

文章标签： javascript 缓存

原文链接：https://zhuanlan.zhihu.com/p/111190645

版权

本文是对浏览器的缓存机制做了一个较为系统的探讨。如果已经了解了缓存，可以只看第一部分，结合配图一起看。如果对缓存机制不了解，可以根据后面的一些详细介绍做一个系统理解

浏览器缓存主要分为强缓存（本地缓存）和协商缓存（弱缓存）

在这里插入图片描述
如上图，在浏览器第一次发送请求后，需要再次发送请求时，浏览器会首先获取该资源缓存的header信息，然后根据Cache-Control和expires来判断是否过期。若没过期则直接从缓存中获取资源信息，包括缓存的header的信息，所以此次请求不会与服务器进行通信。如果缓存过期，浏览器会向服务器发送请求，本次请求会带着第一次请求返回的有关缓存的header字段信息，比如以下两种情况：

1、Etag

客户端会通过If-None-Match头将先前服务器端返回的Etag发送给服务器，服务器会对比这个客户端发过来的Etag是否与服务器的相同，若相同，就将If-None-Match的值设为false，返回状态304，客户端继续使用本地缓存，不解析服务器端发回来的数据。若不相同就将If-None-Match的值设为true，返回状态为200，客户端重新机械服务器端返回的数据；

2、If-Modified-Since

客户端还会通过If-Modified-Since头将先前服务器端发过来的最后修改时间戳发送给服务器，服务器端通过这个时间戳判断客户端的页面是否是最新的，如果不是最新的，则返回最新的内容，如果是最新的，则返回304，客户端继续使用本地缓存。

————————————————————————————————

强缓存：

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

1、Expires：是http1.0的规范，它的值是一个绝对时间的GMT格式的时间字符串。比如网页的Expires值是：

expires:Mar, 06 Apr 2020 10:47:02 GMT

这个时间代表这这个资源的失效时间，只要发送请求时间是在Expires之前，那么本地缓存始终有效，则在缓存中读取数据。所以这种方式有一个明显的缺点，由于失效的时间是一个绝对时间，所以当服务器与客户端时间偏差较大时，就会导致缓存混乱。

2、Cache-Control: 是http1.1中出现的，一般利用该字段的max-age来判断，这个值是一个相对时间。例如：

Cache-Control:max-age=3600 // 代表着资源的有效期是3600秒

除了该字段还有其他的几个常用的值：

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

Cache-Control与Expires的优先级

Cache-Control与Expires可以在服务端配置同时启用，同时启用的时候Cache-Control优先级高。比如：

cache-control:max-age=691200
expires:Fri, 06 Mar 2020 10:47:02 GMT

那么表示资源可以被缓存的最长时间为691200秒，会优先考虑max-age。

—————————————————————————————

协商缓存：

协商缓存是由服务器确定缓存资源是否可用。主要涉及到两组header字段：

		Etag  和 If-None-Match
		
		Last-Modified 和 If-Modified-Since

Last-Modify/If-Modify-Since

浏览器第一次请求一个资源的时候，服务器返回的header中会加上Last-Modify，Last-modify是一个时间标识该资源的最后修改时间，例如:

Last-Modify: Thu,31 Dec 2037 23:59:59 GMT

当浏览器再次请求该资源时，request的请求头中会包含If-Modify-Since，该值为缓存之前返回的Last-Modify。服务器收到If-Modify-Since后，根据资源的最后修改时间判断是否命中缓存。如果命中缓存，则返回304，并且不会返回资源内容，并且不会返回Last-Modify。

Etag/If-None-Match

从上面看可能会觉得使用Last-Modified已经足以让浏览器知道本地的缓存副本是否足够新，为什么还需要Etag呢？

首先，Etag/If-None-Match 是实体标签（Entity Tag）的缩写，是资源的一个唯一标识，资源变化都会导致ETag变化。服务器根据浏览器上送的If-None-Match值来判断是否命中缓存。

因此，Etag的出现主要是为了解决几个Last-Modified比较难解决的问题：

一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新GET；
某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，If-Modified-Since能检查到的粒度是s级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)；
某些服务器不能精确的得到文件的最后修改时间。

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