阅读 8946

面试精选之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 过期时间只能精确到秒。

精确到秒存在两个问题:

  • 1、如果 a.js 在一秒时间内经常变动,同时服务器给 a.js 设置无缓存,那浏览器每次访问 a.js,都会请求服务器,此时服务器比较发给浏览器的上次修改时间和 a.js 的最近修改时间,发现都是在同一时间(因为精确到秒),因此返回给浏览器继续使用本地缓存的消息(304),但事实上服务器上的 a.js 已经改动了好多次了。所以这种情况,浏览器拿不到最新的 a.js 文件。
  • 2、如果在服务器上 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不缓存,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 对缓存的控制粒度更细,包括缓存代理服务器的缓存控制。

文章介绍到此,如有兴趣,可以动手实践下。

关注下面的标签,发现更多相似文章
评论
说说你的看法