HTTP 缓存的一切 面试常客 聊聊

速度、速度，还是速度，一个网站要想体验好，就必定在第一时期以最快的速度显示出来。mysql查问慢，就加一层 redis做缓存，网站资源加载慢，怎样做，经常使用 HTTP缓存。

HTTP缓存自 HTTP/1.0 就开局有，为的是缩小主机压力，放慢网页照应速度。

缓存操作的目的

HTTP 缓存只能存储 GET 恳求的照应，而对其余类型的恳求无能为力。

缓存开展史

HTTP/1.0 提出缓存概念，即强缓存 Expires 和协商缓存 Last-Modified。后 HTTP/1.1 又有了更好的打算，即强缓存Cache-Control 和协商缓存 ETag。

为什么 Expires 和 Last-Modified 不实用呢?

Expires 即过时时期，但疑问是这个时期点是主机的时期，假设客户端的时期和主机时期有差，就不准确。所以用 Cache-Control来替代，它示意过时时长，这就没歧义了。

Last-Modified即最后修正时期，而它能感知的单位时期是秒，也就是说假设在1秒内扭转屡次，内容文件只管扭转了，但展现还是之前的，存在不准确的场景，所以就有了ETag，经过内容给资源打标识来判别资源能否变化。

以下表格利于对比了解：

版本 强缓存 协商缓存 HTTP/1.0 Expires Last-Modified HTTP/1.1 Cache-Control ETag。

两大缓存类型对比

前文已引见不同版本下的缓存类型。过后提了有一句强缓存和协商缓存，但没详细引见。如今来讲讲这两种缓存类型。

强缓存

Cache-Control

Cache-Control VS Expires

协商缓存

协商缓存须要配合强缓存经常使用，经常使用协商缓存的前提是设置强缓存设置 Cache-Control: no-cache或许 pragma: no-cache或许max-age=0 通知阅读器不走强缓存。

pragma 是 HTTP/1.0 中制止网页缓存的字段，其取值为 no-cache 和 Cache-Control 的 no-cache成果一样。

ETag/If-None-Match

Last-Modified/If-Modified-Since

ETag VS Last-Modified

协商缓存的条件恳求

前文说到协商缓存是在恳求头增加 If-None-Match 或 If-Modified-Since，这些恳求头是什么，增加有什么用?

强缓存是经过详细时期到期或过时时长来控制缓存，这就有个疑问了，假设其中的一些文件修正了，由于强缓存，阅读器展现的还是原来的数据，所以对那种常变化的数据不能经常使用强缓存做缓存战略，于是乎，就有了协商缓存，经过文件变化通知阅读器缓存失效，经常使用前需去主机验证能否是最新版?

这样，阅读器就要延续发送两个恳求来验证：

但这样的两个恳求的网络老本太高，所以 HTTP 协定就定义了一系列 If扫尾的条件恳求字段，专门用来审核验证资源能否过时，把两个恳求兼并在一个恳求中做。而且验证的责任也交给主机。

其中，最经常出现的当属是 If-Modified-Since 和 If-None-Match。它们区分对应Last-Modified 和ETag。须要第一次性的照应报文预先提供 Last-Modified 和 ETag，而后第二次恳求时就可以带上缓存里的原址，验证资源能否是最新的。

假设资源没有变，主机就回应一个 304 Not Modified ，示意缓存依然有效，阅读器就可以更新一个有效期，而后经常使用缓存了。

缓存流程

什么时刻用强缓存，什么时刻用协商缓存?

首先强缓存的权严重于协商缓存，当强缓存存在时，协商缓存只能看着;其次 HTTP/1.1 中的缓存标识符大于 HTTP/1;所以当Cache-Control 存在时，看它的，假设它不存在，则看 Expires，假设将强缓存设置为Cache-Control：no-cache、Cache-Control：max-age=0、pragma:no-cache，即通知阅读器不走强缓存，则进入协商缓存。

判别上次照应中能否有ETag，假设有，则动员恳求，恳求头中带有条件恳求If-None-Match，假设没有，则再判别上次照应中能否有Last-Modified，假设有，则动员恳求头中带If-Modified-Since的条件恳求，假设没有，则说明没有协商缓存，动员 HTTP 恳求即可。无论是带If-None-Match的恳求还是 If-Modified-Since的恳求，都会前往形态(由主机端判读资源能否变化)，假设是304，说明缓存资源未变，经常使用本地缓存;假设是200，则说明资源扭转，动员 HTTP恳求，并记住照应头中的 ETag/Last-Modified。

大抵流程图如下所示：

缓存判别流程图

那么哪些资源要驳回强缓存，哪些资源驳回协商缓存呢?

像静态资源这类咱们常年不会去变化的资源应该用强缓存，不难了解;而像咱们常修正的文件应该驳回协商缓存，假设资源没变，那么当用户第二次出来还是用该资源，假设资源修正，用户进入动员HTTP 恳求失掉最新资源。

咱们在访问网站时，假设留心都能在 F12 中观察到一二。如图所示，我的五年前端三年面试放在 github 主机上，F12进入Network中，能看到前往头中的信息。Cache-Control、Expires、ETag、Last-Modified都存在。

五年前端三年面试

缓存位置

上文中常提到无论经常使用强缓存还是协商缓存，都会从阅读器本地中失掉，那么阅读器的本地存储是存在哪里，他们又有什么分类呢?

依照缓存位置分类，分为到处，Memory Cache(内存缓存)、Disk Cache(硬盘缓存)、Service Worker、PushCache。

Memory Cache

由于内存有限，并不是一切的资源文件都会放在内存里缓存，它关键用来缓存有 preloader 相关指令的资源，比如。preloader 可以一边解析 js/css 文件，一边网络恳求下一个资源。

磁盘上的缓存。在一切阅读器缓存中，disk cache 笼罩面最大，它会依据 HTTP Header中的字段判别哪些资源须要缓存，哪些资源曾经过时须要从新从主机端恳求。

Service Worker

独立线程，自创了 Web Worker 的思绪。即让 JS运转在主线程之外，由于它脱离阅读器窗口，由于无法间接访问DOM，然而它还是能做很多事情，如

即推送缓存，阅读器中的最后一道防线，HTTP2中的内容。

优先级： Service Worker-->Memory Cache-->Disk Cache-->Push Cache。

通常

说了这么多通经常识，等实战的时刻却一头雾水，怎样破?

以上皆为口舌之辩，唯有通常出真章(以上皆为面试之辩，唯有通常出身手)。

目前前端名目都是以 webpack 或类 webpack 工具库打包，在 webpack 中性能哈希，前端方面的缓存上班就成功了。

咱们要成功的成果是：

webpack 中的哈希有三种：hash、chunkHash、contentHash。

这边须要把 CSS 用 contentHash 解决，其余资源用 chunkHash 做解决。

非前端工程化名目

即传统的前端页面，普通放在静态主机中，那么就要对修正的文件做版本控制，例如在入口文件 index.js上加版本号(index-v2.min.js)或许加时期戳(time=1626226)，以此做缓存战略。

后端缓存通常

真正起到缓存作用的是在后端，后端来设置缓存战略，通知阅读器能否做缓存。这里咱们对强缓存和协商缓存做个demo来试验下。

强缓存打算

代码如下：

  = ();  = ();  = {: , // 禁用协商缓存: , // 禁用协商缓存: (, , ) => {(, ); // 强缓存超时时期为秒},};((( + ), ));();

强缓存成果

协商缓存打算

代码如下：

  = ();  = ();  = {: , // 开启协商缓存: , // 开启协商缓存: (, , ) => {({: , // 阅读器不走强缓存: , // 阅读器不走强缓存});},};((( + ), ));();

成果如下：

协商缓存成果

总结

HTTP 为什么要缓存，为了分担主机压力，也为了让页面加载更快。

有什么手腕?HTTP 的强缓存和协商缓存，强缓存作用于那些不怎样变化的资源(如引入的库，js，css等)，协商缓存实用常更新的文件(例如html)。

强缓存是什么?在 HTTP/1.0 中以 Expires 为依据，但它不准确，HTTP 协定更新成1.1后，用新标识符 Cache-Control来替代，但两者可以同时存在，Cache-Control 的权重更大一些。

协商缓存是什么?在 HTTP/1.0 中以 Last-Modified 为依据，即最后过时修正时期，它也不准确，HTTP更新成1.1后，用新标识符ETag 来替代，两者可同时存在，后者的权重更大。

无论是 Expires ，还是 Last-Modified，都是以时期点来依据，通常上是不出疑问，但却出疑问了，所以就有了新的打算。

其中强缓存存在时，阅读器会驳回强缓存标识符来缓存，当将强缓存设置为失效时，阅读器则会驳回协商缓存来做缓存战略。

以上，即使笔者所了解的 HTTP 缓存。