乐趣区

关于前端:轻松理解HTTP缓存策略

jiezi

上一篇文章我写了 koa-static 的源码解析，其中用到了 HTTP 的缓存策略，给返回的动态文件设置了一些缓存的头，比方 Cache-Control 之类的。于是我就跟敌人探讨了一下 HTTP 的缓存策略：

敌人说：“HTTP外面管制缓存的头 (header) 太多了，啥Cache-Control，ETag，Last-Modified，一大堆，乌七八糟的，而且之间逻辑关系不强，要把握根本靠背！”

我有点诧异：“为什么要去背这个呢？所有的技术都是为了解决问题而存在的，不理解问题而去单纯的学习技术，去，背，去，死记，的确很干燥，而且成果不好。HTTP缓存策略只是为了解决客户端和服务端信息不对称的问题而存在的，客户端为了加快速度会缓存局部资源，然而下次申请时，客户端不晓得这个资源有没有更新，服务端也不晓得客户端缓存的是哪个版本，不晓得该不该再返回资源，其实就是一个信息同步问题，HTTP缓存策略就是来解决这个问题的。如果咱们跳出这种纯正的技术思维，咱们会发现生存中这种信息同步问题也很常见。而咱们解决这些问题的思路很多时候都是司空见惯了，如果从这个角度来说，这个问题就很好了解！”

于是我给他讲了一个我小时候租光碟看奥特曼的故事。

租光碟看奥特曼

事件是这样的，我小时候特地喜爱看动画片，尤其是奥特曼，然而那时候没有电脑啊，也没有网络。我只有一台 DVD 播放机，于是我会常常跑去租光碟的店租奥特曼。

ETag

某天，我看完了《艾斯奥特曼》第 10 集 ，我还想持续看。于是我找到了光碟店的老板：“老板， 第 10 集 我看完了哦，你还有没有新的啊？”老板说：“有有有，刚出了 第 11 集，你拿去吧！”

下面这一个简略的交换过程其实就蕴含了一个 HTTP 的缓存技术，那就是 ETag！类比于网络申请，我其实就是客户端，光碟店就是服务端，我去租光碟就相当于发动一个申请。然而我去租光碟时，老板并不知道我看到哪集了，咱们的信息是不同步的。所以我通知了他一个标记(Tag)，在这里这个标记就是 第 10 集 ，老板拿到这个标记，跟他本人库存的标记比拟一下，发现他最新标记是 第 11 集 ，于是晓得有更新了，将 第 11 集 给了我。

Last-Modified & If-Modified-Since

再来，我《艾斯奥特曼》看完了，我开始看《泰罗奥特曼》了。可是老板这次比拟鸡贼，《泰罗奥特曼》没买正版的，是他本人翻录的，他翻录的时候本人也不晓得是第几集，然而他聪慧的在光盘上写上了翻录日期。于是我正在看的这盘也没啥封面，只赤裸裸的写了一个 2000 年 12 月 1 日。当我这盘看完了，我又去找老板了：“老板，你这个2000 年 12 月 1 日 的我曾经看完了，你还有没有新的啊？”这里的 2000 年 12 月 1 日 其实就是标记了我手上正本的更新日期，这也对应了 HTTP 的一个缓存技术，那就是 Last-Modified 和If-Modified-Since。你能够了解为，老板给日期还取了一个名字，叫Last-Modified，所以光碟上残缺文字是Last-Modified:2000 年 12 月 1 日，而我去问的时候就这么问：“Do you have any updates IF-Modified-Since 2000 年 12 月 1 日？”。

Expires 和 Max-Age

持续，我《泰罗奥特曼》也看完了，开始看《雷欧奥特曼》了。这《雷欧奥特曼》跟后面两个都不一样，我去租的时候老板就说了：“你小子别天天跑来问了！《雷欧奥特曼》我每周去进一次货，你每周一来拿就行！”这句话也对应了一个 HTTP 缓存技术，那就是 Expires 和Max-Age。我晓得了下周一之前，我手上都是最新的，到了下周一就过期 (Expire) 了。所以“我手上的是最新的”这个说法有个生命周期，他的年龄是无限的，他的年龄等于下周一更新工夫减去以后工夫，这就是他的最大年龄(Max-Age)。

Immutable

再来一个，我《雷欧奥特曼》也看完了，开始看《奈克斯特奥特曼》了。这《奈克斯特奥特曼》跟后面几个都不一样，我去租的时候老板说了：“小子，你这次运气好，这《奈克斯特奥特曼》曾经出完了，你全副拿去吧，也不必天天跑来问了！”这句话对应的 HTTP 缓存技术是啥？当然是 Immutable！Immutable就跟字面意思一样，不可变的！就像《奈克斯特奥特曼》一样，曾经出完了，不必再去问更新了。

言归正传

扯蛋到这里完结，咱们言归正传！之所以举这么个例子，是为了阐明 HTTP 缓存技术要解决的问题在生活中很常见，从这些常见的场景动手，了解起来更简略。上面咱们正儿八经的来说说 HTTP 缓存技术：

两种机制

从下面的几个小例子能够看出，有时候为了晓得是不是有更新，我必须去问老板，比方第一个例子外面：“老板，第 10 集 我看完了哦，你还有没有新的啊？”。这种为了晓得有没有更新，必须跟服务端沟通过才晓得的，咱们称之为 协商缓存 。还有些场景，我不去问就晓得有没有更新，比方第三个例子，因为晓得是周更的，当周一来之前，我都不会去问了，到了周一再去问，这种不必跟服务器协商间接用本地正本的叫做 强制缓存 。换成技术的话说就是， 强制缓存 不必发申请间接用本地缓存，协商缓存 要发申请去问服务器有没有更新。上面咱们具体来讲下这两种缓存：

协商缓存

后面第一个例子和第二个例子每次都须要向服务器端询问，所以是 协商缓存。

ETag 和 If-None-Match

ETag是 URL 的 Entity Tag，就是一个 URL 资源的标识符，相似于文件的md5，计算形式也相似，当服务器返回时，能够依据返回内容计算一个hash 值或者就是一个数字版本号，相似于咱们的 第 10 集 ，具体返回什么值要看服务器的计算策略。而后将它 加到 response 的header外面，可能长这样：

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"

客户端拿到后会将这个 ETag 和返回值一起存下来，等下次申请时，应用配套的 If-None-Match，将这个 放到 request 的header外面，可能长这样：

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"

而后服务端拿到申请外面的 If-None-Match 跟以后版本的 ETag 比拟下：

  1. 如果是一样的话，间接返回304，语义为Not Modified，不返回内容(body)，只返回header，通知浏览器间接用缓存。
  2. 如果不一样的话，返回 200 和最新的内容

与 ETag 配套的还有一个不太罕用的 request header —-If-Match，这个和后面If-None-Match 的语义是相同的。后面 If-None-Match 的语义是 如果不匹配就下载 。而If-Match 通常用于 post 或者 put 申请中，语义为 如果匹配才提交 ，比方你在编辑一个商品，其他人也可能同时在编辑。当你提交编辑时，其他人可能曾经先于你提交了，这时候服务端的ETag 就曾经变了，If-Match就不成立了，这时候服务端会给你返回 412 谬误，也就是 Precondition Failed，前提条件失败。如果If-Match 成立，就失常返回200。

Last-Modified & If-Modified-Since

Last-Modified和 If-Modified-Since 也是配套应用的，相似于 ETag 和If-None-Match的关系。只不过 ETag 放的是一个版本号或者 hash 值，Last-Modified放的是资源的最初批改工夫。Last-Modified是放到 response 的header外面的，可能长这样：

Last-Modified: Wed, 21 Oct 2000 07:28:00 GMT

而客户端浏览器在应用时，应该将配套的 If-Modified-Since 放到 request 的header外面，长这样：

If-Modified-Since: Wed, 21 Oct 2000 07:28:00 GMT

服务端拿到这个头后，会跟以后版本的批改工夫进行比拟：

  1. 以后版本的批改工夫比这个晚，也就是这个工夫后又改过了，返回 200 和新的内容
  2. 以后版本的批改工夫和这个一样，也就是没有更新，返回304，不返回内容，只返回头，客户端间接应用缓存

与 If-Modified-Since 对应的还有 If-Unmodified-Since，If-Modified-Since 能够了解为 有更新才下载 ，那If-Unmodified-Since 就是 没有更新才下载。如果客户端传了If-Unmodified-Since，像这样：

If-Unmodified-Since: Wed, 21 Oct 2000 07:28:00 GMT

服务端拿到这个头后，也会跟以后版本的批改工夫进行比拟：

  1. 如果这个工夫后没有更新，服务器返回200，并返回内容。
  2. 如果这个工夫后有更新，其实就是这个 if 不成立，会返回错误代码412，语义为Precondition Failed

ETag 和 Last-Modified 优先级

ETag和 Last-Modified 都是协商缓存，都须要服务器进行计算和比拟，那如果这两个都存在，用哪个呢？答案是 ETag，ETag 的优先级比 Last-Modified 高。因为 Last-Modified 在设计上有个问题，那就是 Last-Modified 的精度只能到秒，如果一个资源频繁批改，在同一秒进行屡次批改，你从 Last-Modified 上是看不出来区别的。然而 ETag 每次批改都会生成新的，所以他比 Last-Modified 精度高，更精确。然而 ETag 也不是齐全没问题的，你的 ETag 如果设计为一个 hash 值，每次申请都要计算这个值，须要额定消耗服务器资源。具体应用哪一个，须要依据本人的我的项目状况来进行取舍。

强制缓存

下面扯蛋那里的第三个例子和第四个例子就是强制缓存，就是我晓得在某个时间段齐全不必去问服务端，间接去用缓存就行。这两个例子外面提到的 Expires 是一个独自的 header，max-age 和immutable同属于 Cache-Control 这个header。

Expires

Expires比较简单，就是服务器 response 的header带上这个字段：

Expires: Wed, 21 Oct 2000 07:28:00 GMT

而后在这个工夫前，客户端浏览器都不会再发动申请，而是间接用缓存资源。

Cache-Control

Cache-Control绝对比较复杂，可设置属性也比拟多，max-age只是其中一个属性，长这样：

Cache-Control: max-age=20000

这示意以后资源在 20000 秒 内都不必再申请了，间接应用缓存。

下面提到的 immutable 也是 Cache-Control 的一个属性，然而是个试验性质的，各个浏览器兼容并不好。设置了 Cache-control: immutable 示意这辈子都用缓存了，再申请是不可能的了。

其余罕用属性还有：

no-cache：应用缓存前，强制要求把申请提交给服务器进行验证(协商缓存验证)。

no-store：不存储无关客户端申请或服务器响应的任何内容，即不应用任何缓存。

另外 Cache-Control 还有很多属性，大家能够参考 MDN 的文档。

Expires 和 Cache-Control 的优先级

就一句话：如果在 Cache-Control 响应头设置了 max-age 或者 s-maxage 指令，那么 Expires 头会被疏忽。

协商缓存和强制缓存优先级

这个其实很好了解，协商缓存须要发申请跟服务器协商，强制缓存如果失效，基本就不会发申请。所以这个优先级就是：先判断强制缓存，如果强制缓存失效，间接应用缓存；如果强制缓存生效，再发申请跟服务器协商，看要不要应用缓存。

总结

本文从生存中常见的场景动手，论述了 HTTP 缓存机制其实是进步访问速度和解决信息不同步的一种机制。这种信息不同步在生活中很常见，很多解决思路咱们曾经司空见惯，带着这种思维，咱们能够很好的了解 HTTP 缓存机制。HTTP缓存机制要点如下：

  1. HTTP缓存机制分为 强制缓存 和协商缓存 两类。
  2. 强制缓存 的意思就是不要问了(不发动申请)，间接用缓存吧。
  3. 强制缓存 常见技术有 Expires 和Cache-Control。
  4. Expires的值是一个工夫，示意这个工夫前缓存都无效，都不须要发动申请。
  5. Cache-Control有很多属性值，罕用属性 max-age 设置了缓存无效的工夫长度，单位为 秒，这个工夫没到，都不必发动申请。
  6. immutable也是 Cache-Control 的一个属性，示意这个资源这辈子都不必再申请了，然而他兼容性不好，Cache-Control其余属性能够参考 MDN 的文档。
  7. Cache-Control的 max-age 优先级比 Expires 高。
  8. 协商缓存 常见技术有 ETag 和Last-Modified。
  9. ETag其实就是给资源算一个 hash 值或者版本号，对应的罕用 request header 为If-None-Match。
  10. Last-Modified其实就是加上资源批改的工夫，对应的罕用 request header 为If-Modified-Since，精度为 秒。
  11. ETag每次批改都会扭转，而 Last-Modified 的精度只到 秒，所以 ETag 更精确，优先级更高，然而须要计算，所以服务端开销更大。
  12. 强制缓存 和协商缓存 都存在的状况下，先判断 强制缓存 是否失效，如果失效，不必发动申请，间接用缓存。如果 强制缓存 不失效再发动申请判断 协商缓存。

参考资料：

ETag MDN文档：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/ETag

Last-Modified MDN文档：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Last-Modified

Expires MDN文档：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Expires

Cache-Control MDN文档：https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers/Cache-Control

文章的最初，感激你破费贵重的工夫浏览本文，如果本文给了你一点点帮忙或者启发，请不要悭吝你的赞和 GitHub 小星星，你的反对是作者继续创作的能源。

作者博文 GitHub 我的项目地址：https://github.com/dennis-jiang/Front-End-Knowledges

我也搞了个公众号[进击的大前端]，能够第一工夫获取高质量原创，欢送关注~

退出移动版