面试精选之http缓存

前端面试常问第二大问题是http缓存相关内容。说真的，http缓存相关的细节比较多，而且 http 经常使用协议版本有1.0、1.1，（本文暂不讨论http2.0）。

缓存相关 header

咱们先罗列一下和缓存相关的请求响应头。

• Expires

响应头，表明该资源的过时时间。

• Cache-Control

请求/响应头，缓存控制字段，精确控制缓存策略。

• If-Modified-Since

请求头，资源最近修改时间，由浏览器告诉服务器。

• Last-Modified

响应头，资源最近修改时间，由服务器告诉浏览器。

• Etag

响应头，资源标识，由服务器告诉浏览器。

• If-None-Match

请求头，缓存资源标识，由浏览器告诉服务器。

配对使用的字段：

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

今天着重介绍一下浏览器缓存机制，咱们知道，浏览器缓存通常都是针对静态资源，好比 js、css、图片 等，因此咱们下面的例子围绕一个 javascript 文件 a.js 来阐述。抛开理论式灌输，咱们从实际场景触发，一点点完善缓存机制，这种方式，相信你们会更容易理解。

作一些约定，方便之后比较。

• a.js 大小为 10 KB
• 请求头约定为 1 KB
• 响应头约定为 1 KB

原始模型

• 浏览器请求静态资源 a.js。（请求头：1KB）
• 服务器读取磁盘文件 a.js，返给浏览器。（10KB（a.js）+1KB（响应头） = 11KB）。
• 浏览器再次请求，服务器又从新读取磁盘文件 a.js，返给浏览器。
• 如此循环。。

执行一个往返，流量为 10（a.js）+1（请求头）+1（响应头） = 12KB。

访问 10 次，流量大约为12 * 10 = 120KB。

因此，流量与访问次数有关：

L（流量） = N（访问次数） * 12。

该方式缺点很明显：

• 浪费用户流量。
• 浪费服务器资源，服务器要读磁盘文件，而后发送文件到浏览器。
• 浏览器要等待 a.js 下载而且执行后才能渲染页面，影响用户体验。

js 执行时间相比下载时间要快的多，若是能优化下载时间，用户体验会提高不少。

浏览器增长缓存机制

• 浏览器第一次请求 a.js，缓存 a.js 到本地磁盘。（1+10+1 =12KB）
• 浏览器再次请求 a.js，直接走浏览器缓存（200，from cache），再也不向服务器发起请求。（0KB）
• ...

第一次访问，流量为 1+10+1 = 12KB。 第二次访问，流量为 0。 。。。 第 10000 次访问，流量依然为 0。

因此流量与访问次数无关：

L（流量） = 12KB。

优势：

• 大大减小带宽。
• 因为减小了 a.js 下载时间，相应的提升了用户体验。

缺点：服务器上 a.js 更新时，浏览器感知不到，拿不到最新的 js 资源。

服务器和浏览器约定资源过时时间。

服务器和浏览器约定文件过时时间，用 Expires 字段来控制，时间是 GMT 格式的标准时间，如 Fri, 01 Jan 1990 00:00:00 GMT。

• 浏览器第一次请求一个静态资源 a.js。（1KB）
• 服务器把 a.js 和 a.js 的缓存过时时间(Expires：Mon, 26 Sep 2018 05:00:00 GMT)发给浏览器。（10+1=11KB）

服务器告诉浏览器：你把我发给你的 a.js 文件缓存到你那里，在 2018年9月26日5点以前不要再发请求烦我，直接使用你本身缓存的 a.js 就好了。

• 浏览器接收到 a.js，同时记住了过时时间。
• 在2018年9月26日5点以前，浏览器再次请求 a.js，便再也不请求服务器，直接使用上一次缓存的 a.js 文件。（0KB）
• 在2018年9月26日5点01分，浏览器请求 a.js，发现 a.js 缓存时间过了，因而再也不使用本地缓存，而是请求服务器，服务器又从新读取磁盘文件 a.js，返给浏览器，同时告诉浏览器一个新的过时时间。（1+10+1=12KB）。
• 如此往复。。。

该种方式较以前的方式有了很大的改善：

• 在过时时间之内，为用户省了不少流量。
• 减小了服务器重复读取磁盘文件的压力。
• 缓存过时后，可以获得最新的 a.js 文件。

缺点仍是有：

• 缓存过时之后，服务器无论 a.js有没有变化，都会再次读取 a.js文件，并返给浏览器。

服务器告诉浏览器资源上次修改时间。

为了解决上个方案的问题，服务器和浏览器通过磋商，制定了一种方案，服务器每次返回 a.js 的时候，还要告诉浏览器 a.js 在服务器上的最近修改时间 Last-Modified （GMT标准格式）。

• 浏览器访问 a.js 文件。（1KB）

• 服务器返回 a.js 的时候，告诉浏览器 a.js 文件。（10+1=11KB） 在服务器的上次修改时间 Last-Modified（GMT标准格式）以及缓存过时时间 Expires（GMT标准格式）

• 当 a.js 过时时，浏览器带上 If-Modified-Since（等于上一次请求的Last-Modified） 请求服务器。（1KB）

• 服务器比较请求头里的 Last-Modified 时间和服务器上 a.js的上次修改时间：

  • 若是一致，则告诉浏览器：你能够继续用本地缓存（304）。此时，服务器再也不返回 a.js 文件。（1KB）
  • 若是不一致，服务器读取磁盘上的 a.js 文件返给浏览器，同时告诉浏览器 a.js 的最近的修改时间 Last-Modified 以及过时时间 Expires。（1+10=11KB）
  • 如此往复。

此种方案比上一个方案有了更进一步的优化：

• 缓存过时后，服务器检测若是文件没变化，再也不把a.js发给浏览器，省去了 10KB 的流量。
• 缓存过时后，服务器检测文件有变化，则把最新的 a.js 发给浏览器，浏览器可以获得最新的 a.js。

缺点：

• Expires 过时控制不稳定，由于浏览器端能够随意修改时间，致使缓存使用不精准。
• Last-Modified 过时时间只能精确到秒。

精确到秒存在两个问题：

• 一、若是 a.js 在一秒时间内常常变更，同时服务器给 a.js 设置无缓存，那浏览器每次访问 a.js，都会请求服务器，此时服务器比较发给浏览器的上次修改时间和 a.js 的最近修改时间，发现都是在同一时间（由于精确到秒），所以返回给浏览器继续使用本地缓存的消息（304），但事实上服务器上的 a.js 已经改动了好屡次了。因此这种状况，浏览器拿不到最新的 a.js 文件。
• 二、若是在服务器上 a.js 被修改了，但其实际内容根本没发生改变，会由于 Last-Modified 时间匹配不上而从新返回 a.js 给浏览器。

继续改进，增长相对时间的控制，引入 Cache-Contorl

为了兼容已经实现了上述方案的浏览器，同时加入新的缓存方案，服务器除了告诉浏览器 Expires ，同时告诉浏览器一个相对时间 Cache-Control：max-age=10秒。意思是在10秒之内，使用缓存到浏览器的 a.js 资源。

浏览器先检查 Cache-Control，若是有，则以 Cache-Control 为准，忽略 Expires。若是没有 Cache-Control，则以 Expires 为准。

继续改进，增长文件内容对比，引入Etag

为了解决文件修改时间只能精确到秒带来的问题，咱们给服务器引入 Etag 响应头，a.js 内容变了，Etag 才变。内容不变，Etag 不变，能够理解为 Etag 是文件内容的惟一 ID。 同时引入对应的请求头 If-None-Match，每次浏览器请求服务器的时候，都带上If-None-Match字段，该字段的值就是上次请求 a.js 时，服务器返回给浏览器的 Etag。

• 浏览器请求 a.js。
• 服务器返回 a.js，同时告诉浏览器过时绝对时间（Expires）以及相对时间（Cache-Control：max-age=10），以及a.js上次修改时间Last-Modified，以及 a.js 的Etag。
• 10秒内浏览器再次请求 a.js，再也不请求服务器，直接使用本地缓存。
• 11秒时，浏览器再次请求 a.js，请求服务器，带上上次修改时间 If-Modified-Since 和上次的 Etag 值 If-None-Match。
• 服务器收到浏览器的If-Modified-Since和Etag，发现有If-None-Match，则比较 If-None-Match 和 a.js 的 Etag 值，忽略If-Modified-Since的比较。
• a.js 文件内容没变化，则Etag和If-None-Match 一致，服务器告诉浏览器继续使用本地缓存（304）。
• 如此往复。

结束了吗？

到此就结束了吗？ 是的，http的缓存机制就是如此了，可是仍然存在一个问题：

浏览器没法主动得知服务器上的 a.js 资源变化了。

无论用 Expires 仍是 Cache-Control，他们都只可以控制缓存是否过时，可是在缓存过时以前，浏览器是没法得知服务器上的资源是否变化的。只有当缓存过时后，浏览器才会发请求询问服务器。

最终方案

你们能够想象咱们使用 a.js 的场景，咱们通常都是输入网址，访问一个 html 文件，html文件中会引入 js、css 、图片等资源。

因此呢，咱们在html上作些手脚。

咱们不让 html 文件缓存，每次访问 html 都去请求服务器。因此浏览器每次都能拿到最新的html资源。

a.js 内容更新的时候，咱们修改一下 html 中 a.js 的版本号。

• 第一次访问 html

<script src="http://test.com/a.js?version=0.0.1"></script>
复制代码

• 浏览器下载0.0.1版本的a.js文件。

• 浏览器再次访问 html，发现仍是0.0.1版本的a.js文件，则使用本地缓存。

• 某一天a.js变了，咱们的html文件也相应变化以下：

<script src="http://test.com/a.js?version=0.0.2"></script>
复制代码

• 浏览器再次访问html，发现【test.com/a.js?versio… a.js。
• 如此往复。

因此，经过设置html不缓存，html引用资源内容变化则改变资源路径的方式，就解决了没法及时得知资源更新的问题。

固然除了以版本号来区分，也能够以 MD5hash 值来区分。 如

<script src="http://test.com/a.【hash值】.js"></script>
复制代码

使用webpack打包的话，借助插件能够很方便的处理。

除此之外的东东

Cache-Control 除了能够设置 max-age 相对过时时间之外，还能够设置成以下几种值：

• public，资源容许被中间服务器缓存。

浏览器请求服务器时，若是缓存时间没到，中间服务器直接返回给浏览器内容，而没必要请求源服务器。

• private，资源不容许被中间代理服务器缓存。

浏览器请求服务器时，中间服务器都要把浏览器的请求透传给服务器。

• no-cache，浏览器不作缓存检查。

每次访问资源，浏览器都要向服务器询问，若是文件没变化，服务器只告诉浏览器继续使用缓存（304）。

• no-store，浏览器和中间代理服务器都不能缓存资源。

每次访问资源，浏览器都必须请求服务器，而且，服务器不去检查文件是否变化，而是直接返回完整的资源。

• must-revalidate，能够缓存，可是使用以前必须先向源服务器确认。
• proxy-revalidate，要求缓存服务器针对缓存资源向源服务器进行确认。
• s-maxage：缓存服务器对资源缓存的最大时间。

Cache-Control 对缓存的控制粒度更细，包括缓存代理服务器的缓存控制。

文章介绍到此，若有兴趣，能够动手实践下。