浏览器中的缓存机制

先贴两篇文章 MDN-HTTP 缓存、Google Developer-HTTP 缓存

关于缓存机制，这里只讨论两个关键字，一个是 cache-control，一个是 Etag。

其实有关缓存机制，总来的说只分两种情况，就是使用缓存前是否经过服务器确认。

cache-control

cache-control 是整个缓存机制的核心，它确定服务器如何指示浏览器进行缓存（注意仅仅是指示，关于浏览器如何进行缓存，情况是不确定的）。

一般来说，cache-control 只分两类指示，一种是指示缓存方式，另一种是指示是否私有。

关键字：

• max-age：指示资源能被缓存的最大时间。
• no-cache：强制确认，必须经过服务器确认。
• no-store：指示浏览器即中间服务器不得缓存。

而 public 和 private 则指示中间服务器是否能进行缓存。

通常来说，一旦指定 max-age，如果浏览器正确缓存资源的情况下，则该资源直到过期之前都不会到服务器确认。

一旦 max-age 过期，则轮到 Etag 出场。

Etag

Etag 是 HTTP 表头传递验证令牌，是一个资源的一个指纹，当客户端请求资源时，如果 Etag 已存在，则必带上该 Etag，发送到服务器。

服务器收到 Etag 是，则会验证该指纹与资源指纹是否一致，如果资源未发生变化，则会返回 304，指示客户端可以继续使用缓存。

Revving

web 开发者发明了一种被 Steve Souders 称之为 revving 的技术。不频繁更新的文件会使用特定的命名方式：在 URL 后面（通常是文件名后面）会加上版本号。加上版本号后的资源就被视作一个完全新的独立的资源，同时拥有一年甚至更长的缓存过期时长。但是这么做也存在一个弊端，所有引用这个资源的地方都需要更新链接。web 开发者们通常会采用自动化构建工具在实际工作中完成这些琐碎的工作。当低频更新的资源（js/css）变动了，只用在高频变动的资源文件（html）里做入口的改动。

这种方法还有一个好处：同时更新两个缓存资源不会造成部分缓存先更新而引起新旧文件内容不一致。对于互相有依赖关系的 css 和 js 文件，避免这种不一致性是非常重要的。

缓存机制到这里为止。