浅谈浏览器http的缓存机制-摩杜云开发者社区

前言

我们在访问百度首页的时候，会发现不管怎么刷新页面，静态资源基本都是返回 200（from cache）：

浅谈浏览器http的缓存机制_服务器

随便点开一个静态资源是这样的：

浅谈浏览器http的缓存机制_缓存_02

问题：

有Response响应报头数据，看来服务器也正常返回了etag什么鬼的应有尽有，那状态200不是应该对应的非缓存状态么？要from cache的话不是应该返回304才合理么？【响应状态码304：Not Modified，未修改。表示自从上次请求后，请求的内容未修改过。】

答案：

百度首页的资源在刷新后实际没有发送任何请求，因为 Cache-Control 定义的缓存时间段还没到期。在Chrome中即使没发送请求，但只要从本地的缓存中取，都会在Network面板显示一条状态为200且注明“from cache”的伪请求，其Response内容只是上一次回包留下的数据。

HTTP报文中与缓存相关的首部字段

首先看一下RFC2616规定的47种http报文首部字段中与缓存相关的字段：

1. 通用首部字段（就是请求报文和响应报文都能用上的字段）

浅谈浏览器http的缓存机制_服务器_03

2. 请求首部字段

浅谈浏览器http的缓存机制_缓存_04

3. 响应首部字段

浅谈浏览器http的缓存机制_字段_05

4. 实体首部字段（请求报文实体部分与响应报文实体部分都能用上的字段）

浅谈浏览器http的缓存机制_字段_06

场景模拟

为方便模拟各种缓存效果，我们建个非常简单的场景。

1. 页面文件

我们建个非常简单的html页面，上面只有一个本地样式文件和图片：

<!DOCTYPE html>
<html>
<head>
<title>缓存测试</title>
<link rel="stylesheet" href="css/reset.css">
</head>
<body>
<h1>哥只是一个标题</h1>
<p><img src="img/dog.jpg" /></p>
</body>
</html>

2. 首部字段修改

有时候一些浏览器会自行给请求首部加上一些字段（如chrome使用F5会强制加上“cache-control:max-age=0”）,会覆盖掉一些字段（比如pragma）的功能；另外有时候我们希望服务器能多/少返回一些响应字段。

这种情况我们就希望可以手动来修改请求或响应报文上的内容了。那么如何实现呢？这里我们使用Fiddler工具来完成任务。

在Fiddler中我们可以通过“bpu XXX”指令来拦截指定请求，然后手动修改请求内容再发给服务器、修改响应内容再发给客户端。

以我们的example为例，页面文件走nginx通过 http://localhost/ 可直接访问，所以我们直接执行“bpu localhost”拦截所有地址中带有该字样的请求：

浅谈浏览器http的缓存机制_缓存_07

点击被拦截的请求，可以在右栏直接修改报文内容（上半区域是请求报文，下半区域是响应报文），点击黄色的“Break on Response”按钮可以执行下一步（把请求发给服务器），点击绿色的按钮“Run to Completion”可以直接完成整个请求过程（把响应返回给浏览器）：

浅谈浏览器http的缓存机制_服务器_08

通过这个方法我们可以很轻松地模拟出各种http缓存场景。

3. 浏览器的强制策略

如上述，当下大多数浏览器在点击刷新按钮或按F5时会自行加上“Cache-Control:max-age=0”请求字段，所以我们先约定成俗——后文提及的“刷新”多指的是选中url地址栏并按回车键（这样不会被强行加上Cache-Control）。

HTTP/1.0的缓存方式

在 HTTP/1.0 时代，给客户端设定缓存方式可通过两个字段——“Pragma”和“Expires”来规范。虽然这两个字段早可抛弃，但为了做http协议的向下兼容，你还是可以看到很多网站依旧会带上这两个字段。

1. Pragma【Response Headers中的字段】

当Pragma字段值为“no-cache”的时候（事实上现在RFC中也仅标明该可选值），会知会客户端不要对该资源读缓存，即每次都得向服务器发一次请求才行。

Pragma属于通用首部字段，在客户端上使用时，常规要求我们往html上加上这段meta元标签（而且可能还得做些hack放到body后面去）：

<meta http-equiv="Pragma" content="no-cache">

它告诉浏览器每次请求页面时都不要读缓存，都得往服务器发一次请求才行。

但是!!! 事实上这种禁用缓存的形式用处很有限：

1. 仅有IE才能识别这段meta标签含义，其它主流浏览器仅能识别“Cache-Control: no-store”的meta标签（见出处）。
2. 在IE中识别到该meta标签含义，并不一定会在请求字段加上Pragma，但的确会让当前页面每次都发新请求（仅限页面，页面上的资源则不受影响）。

不过如果是在响应报文上加上该字段就不一样了：

浅谈浏览器http的缓存机制_服务器_09

如上图红框部分是再次刷新页面时生成的请求，这说明禁用缓存生效，预计浏览器在收到服务器的Pragma字段后会对资源进行标记，禁用其缓存行为，进而后续每次刷新页面均能重新发出请求而不走缓存。

2. Expires【Response Headers中的字段】

有了Pragma来禁用缓存，自然也需要有个东西来启用缓存和定义缓存时间，对HTTP/1.0而言，Expires就是做这件事的首部字段。

Expires的值对应一个GMT（格林尼治时间），比如“Mon, 22 Jul 2002 11:12:01 GMT”来告诉浏览器资源缓存过期时间，如果还没过该时间点则不发请求。

在客户端我们同样可以使用meta标签来知会IE（也仅有IE能识别）页面（同样也只对页面有效，对页面上的资源无效）缓存时间：

<meta http-equiv="expires" content="mon, 18 apr 2016 14:30:00 GMT">

如果希望在IE下页面不走缓存，希望每次刷新页面都能发新请求，那么可以把“content”里的值写为“-1”或“0”。

注意的是该方式仅仅作为知会IE缓存时间的标记，你并不能在请求或响应报文中找到Expires字段。

如果是在服务端报头返回Expires字段，则在任何浏览器中都能正确设置资源缓存的时间：

在上图里，缓存时间设置为一个已过期的时间点（见红框），则刷新页面将重新发送请求（见蓝框）。【响应状态码为304：代表已经向服务器重新发起请求，但是服务器发现自上次请求后，请求的资源未发生变化，所以返回一个304状态码】

那么如果Pragma和Expires一起上阵的话，听谁的？我们试一试就知道了：

浅谈浏览器http的缓存机制_服务器_11

我们通过Pragma禁用缓存，又给Expires定义一个还未到期的时间（红框），刷新页面时发现均发起了新请求（蓝框），这意味着Pragma字段的优先级会更高。

但是，响应报文中Expires所定义的缓存时间是相对服务器上的时间而言的，如果客户端上的时间跟服务器上的时间不一致（特别是用户修改了自己电脑的系统时间），那缓存时间可能就没啥意义了。

Cache-Control

针对上述的“Expires时间是相对服务器而言，无法保证和客户端时间统一”的问题，http/1.1新增了 Cache-Control 来定义缓存过期时间，若报文中同时出现了 Pragma、Expires 和 Cache-Control，会以 Cache-Control 为准。

Cache-Control也是一个通用首部字段，这意味着它能分别在请求报文和响应报文中使用。在RFC中规范了 Cache-Control 的格式为：

"Cache-Control" ":" cache-directive

作为请求首部时，cache-directive 的可选值有：【即请求头中"Cache-Control"字段的值可以为：】

浅谈浏览器http的缓存机制_缓存_12

作为响应首部时，cache-directive 的可选值有：【即响应头中"Cache-Control"字段的值可以为：】

浅谈浏览器http的缓存机制_字段_13

我们依旧可以在HTML页面加上meta标签来给请求报头加上 Cache-Control 字段：

另外 Cache-Control 允许自由组合可选值，例如：

Cache-Control: max-age=3600, must-revalidate

它意味着该资源是从原服务器上取得的，且其缓存（新鲜度）的有效时间为一小时，在后续一小时内，用户重新访问该资源则无须发送请求。

当然这种组合的方式也会有些限制，比如 no-cache 就不能和 max-age、min-fresh、max-stale 一起搭配使用。

组合的形式还能做一些浏览器行为不一致的兼容处理。例如在IE我们可以使用 no-cache 来防止点击“后退”按钮时页面资源从缓存加载，但在 Firefox 中，需要使用 no-store 才能防止历史回退时浏览器不从缓存中去读取数据，故我们在响应报头加上如下组合值即可做兼容处理：

Cache-Control: no-cache, no-store

缓存校验字段

上述的首部字段均能让客户端决定是否向服务器发送请求，比如设置的缓存时间未过期，那么自然直接从本地缓存取数据即可（在chrome下表现为200 from cache）【此时没有重新请求服务器】，若缓存时间过期了或资源不该直接走缓存，则会发请求到服务器去。【此时请求服务器，若服务器认为此时访问的资源与上次无变化，则会返回一个304的状态码即告知客户端使用缓存】

我们现在要说的问题是，如果客户端向服务器发了请求，那么是否意味着一定要读取回该资源的整个实体内容呢？

我们试着这么想——客户端上某个资源保存的缓存时间过期了，但这时候其实服务器并没有更新过这个资源，如果这个资源数据量很大，客户端要求服务器再把这个东西重新发一遍过来，是否非常浪费带宽和时间呢？

答案是肯定的，那么是否有办法让服务器知道客户端现在存有的缓存文件，其实跟自己所有的文件是一致的，然后直接告诉客户端说“这东西你直接用缓存里的就可以了，我这边没更新过呢，就不再传一次过去了。

为了让客户端与服务器之间能实现缓存文件是否更新的验证、提升缓存的复用率，Http1.1新增了几个首部字段来做这件事情：

【第一个首部字段】

1. Last-Modified

服务器将资源传递给客户端时，会将资源最后更改的时间以 Last-Modified: GMT 的形式加在实体首部上一起返回给客户端。【一般来说，Last-Modified字段由服务器返回，告诉客户端目标资源的最近一次修改时间】，

当客户端第一次请求时，客户端会为资源标记上该信息；下次再次请求时，会把该信息附带在请求报文中一并带给服务器去做检查，若传递的时间值与服务器上该资源最终修改时间是一致的，则说明该资源没有被修改过，直接返回304状态码即可。

客户端请求头中表示资源最终修改时间的请求报文首部字段有两个：

⑴ If-Modified-Since: Last-Modified-value

示例为  If-Modified-Since: Thu, 31 Mar 2016 07:07:52 GMT

该请求首部告诉服务器如果客户端传来的最后修改时间与服务器上的一致，则直接回送304 和响应报头即可。

当前各浏览器均是使用的该请求首部来向服务器传递保存的 Last-Modified 值。

⑵ If-Unmodified-Since: Last-Modified-value

告诉服务器，若Last-Modified即目标资源的最后修改时间没有匹配上（资源在服务端的最后更新时间改变了），则应当返回412(Precondition Failed) 状态码给客户端。【412 Precondition Failed客户端错误响应代码：表示对目标资源的访问已被服务器拒绝】

当遇到下面情况时，If-Unmodified-Since 字段会被忽略：

1. Last-Modified值对上了（资源在服务端没有新的修改）；
2. 服务端需返回2XX和412之外的状态码；
3. 传来的指定日期不合法

响应首部字段"Last-Modified"的缺点：

Last-Modified 说好却也不是特别好，因为如果在服务器上，一个资源被修改了，但其实际内容根本没发生改变，会因为Last-Modified时间匹配不上而返回了整个实体给客户端（即使客户端缓存里有个一模一样的资源）。

【第二个首部字段】

2. ETag

为了解决上述Last-Modified可能存在的不准确的问题，Http1.1还推出了 ETag 实体首部字段。

服务器会通过某种算法，给资源计算得出一个唯一标志符（比如md5标志），服务端在把资源响应给客户端的时候，会在响应实体首部加上“ETag: 唯一标识符”一起返回给客户端。

客户端第一次请求目标资源并得到服务端的响应，会保留该 ETag 字段【此时服务端的响应头中含有"ETag字段"，用来表示目标资源的唯一标识符】；并在下一次请求时将其一并带过去给服务器。服务器只需要比较客户端传来的ETag值跟自己服务器上该资源的ETag值是否一致【若一致，则有服务端返回304响应状态码；若不一致则返回客户端请求的目标资源】。

如果服务器发现ETag值匹配不上，那么直接以常规GET 200回包形式将新的资源（当然也包括了新的ETag）发给客户端；如果ETag是一致的，则直接返回304知会客户端直接使用本地缓存即可。

那么客户端是如何把标记在资源上的 ETag 传去给服务器的呢？

请求报文中有两个首部字段标识ETag 值：

⑴ If-None-Match: ETag-value

示例为  If-None-Match: "56fcccc8-1699"

告诉服务端如果 ETag值没匹配上需要重发资源数据【此时返回的是新的响应报头，当然也包括新的ETag值】，如果匹配上直接回送304 和响应报头【此时返回的响应报头中ETag值不变】即可。

当前各浏览器均是使用的 该If-None-Match请求首部来向服务器传递保存的 ETag 值。

⑵ If-Match: ETag-value

告诉服务器如果没有匹配到ETag，或者收到了“*”值而当前并没有该资源实体，则应当返回412(Precondition Failed) 状态码给客户端。否则服务器直接忽略该字段。

If-Match 的一个应用场景是，客户端走PUT方法向服务端请求上传/更替资源，这时候可以通过 If-Match 传递资源的ETag。【上传资源时If-Match首部字段的ETag-Value值与通过服务器上面的资源通过算法得到的ETag首部字段值比较，若相同则不需要重新上传一份相同的资源】

需要注意的是，如果资源是走分布式服务器（比如CDN）存储的情况，需要这些服务器上计算ETag唯一值的算法保持一致，才不会导致明明同一个文件，在服务器A和服务器B上生成的ETag却不一样。

当Last-Modified 和 ETag 同时被使用，则要求它们的验证都必须通过【即请求首部字段Last-Modified的值与响应首部字段值ETag的值相同】才会返回304；若其中某个验证没通过，则服务器会按常规返回资源实体及200状态码。

在较新的 nginx 上默认是同时开启了这两个功能的：

浅谈浏览器http的缓存机制_字段_14

上图的前三条请求是原始请求，接着的三条请求是刷新页面后的新请求，在发新请求之前我们修改了 reset.css 文件，所以它的 Last-Modified 和 ETag 均发生了改变，服务器因此返回了新的文件给客户端（状态值为200）。

而 dog.jpg 我们没有做修改，其Last-Modified 和 ETag在服务端是保持不变的，故服务器直接返回了304状态码让客户端直接使用缓存的 dog.jpg 即可，没有把实体内容返回给客户端（因为没必要）。

其它相关的首部字段

事实上较常用和重要的缓存相关字段我们都介绍完了，这里顺带讲讲几个跟缓存有关系，但没那么主要的响应首部字段。

1. Vary

“vary”本身是“变化”的意思，而在http报文中更趋于是“vary from”（与。。。不同）的含义，它表示服务端会以什么基准字段来区分、筛选缓存版本。

我们先考虑这么一个问题——在服务端有着这么一个地址，如果是IE用户则返回针对IE开发的内容，否则返回另一个主流浏览器版本的内容。这很简单，服务端获取到请求的 User-Agent 字段做处理即可。但是用户请求的是代理服务器而非原服务器，且代理服务器如果直接把缓存的IE版本资源发给了非IE的客户端，这就出问题了。

因此 Vary 便是着手处理该问题的首部字段，我们可以在响应报文加上：

Vary: User-Agent

便能知会代理服务器需要以 User-Agent 这个请求首部字段来区别缓存版本，防止传递给客户端的缓存不正确。

Vary 也接受条件组合的形式：

Vary: User-Agent, Accept-Encoding

这意味着服务器应以 User-Agent 和 Accept-Encoding 两个请求首部字段来区分缓存版本。

2. Date 和 Age

HTTP并没有提供某种方法来帮用户区分其收到的资源是否命中了代理服务器的缓存，但在客户端我们可以通过计算响应报文中的 Date 和 Age 字段来得到答案。

Date 理所当然是原服务器发送该资源响应报文的时间（GMT格式）【但是如果你发现 Date 的时间与“当前时间”差别较大，或者连续F5刷新发现 Date 的值都没变化，则说明你当前请求是命中了代理服务器的缓存。】

上述的“当前时间”自然是相对于原服务器而言的时间，那么如何获悉原服务器的当前时间呢？

常规从页面地址请求的响应报文中可获得，以博客园首页为例：

浅谈浏览器http的缓存机制_字段_15

每次你刷新页面，浏览器都会重新发出这条url的请求，你会发现其 Date 值是不断变化的，这说明该链接没有命中缓存，都是从原服务器返回过来的数据。

因此我们可以拿页面上其它静态资源请求回包中的 Date 与其进行对比，若静态资源的 Date 早于原服务端时间，则说明命中了代理服务器缓存。

通常还满足这么个条件：

静态资源Age + 静态资源Date = 原服务端Date

这里的 Age 也是响应报文中的首部字段，它表示该文件在代理服务器中存在的时间（秒），如文件被修改或替换，Age会重新由0开始累计。

我们在上面那张博客园首页报文截图的同个场景下，看看某个文件（jQuery.js）命中代理服务器缓存的回包数据：

浅谈浏览器http的缓存机制_缓存_16

会发现它满足我们上述的规则：

//return true
new Date('Mon, 04 Apr 2016 07:03:17 GMT')/1000 == new Date('Sat, 19 Dec 2015 01:29:14 GMT')/1000 + 9264843

不过这条规则也不一定准确，特别是当原服务器经常修改系统时间的情况下。

去期待陌生，去拥抱惊喜。