第 191 题：有关 HTTP 缓存的首部字段说一下？

Question

HTTP 缓存策略分为两种： 强缓存 和 协商缓存 ，这两种缓存策略都是服务端设置 HTTP Header 来实现的

强缓存

强缓存的意思很简单，直接从浏览器缓存过的本地进行读取，不会去请求服务器。例如请求一个图片，当缓存后，第二次访问，直接从本地去拿，不会再去请求这个资源，可以节省服务器资源。可以通过三种方式来设置强缓存

Expires：服务端在响应头中设置一个 GMT 格式的到期时间。客户端的本地时间小于响应头的 Expires 时间，那么会从本地进行读取，不会去请求服务器。如果超过了，那么就去请求服务器去获取最新资源。但是就是因为根据本地时间进行判断，本地时间可以随便修改，所以这种缓存机制有漏洞，会与服务端时间有偏差，为了解决这个问题，就出现了下面的 Cache-contorl

Cache-control：他和Expires不一样，Expires是直接设置一个时间戳就行了，而Cache-control可以设置下面这几种属性：

• max-age：这个用于设置一个滑动时间，例如设置 max-age=30 表示客户端时间向后滑动30秒，在这30秒内都是强缓存，不会去请求服务器
• s-maxage：这个和上面的一样，只不过这个设置的是代理服务器的缓存时间
• privte：这个表示缓存只能被客户端的浏览器缓存，不能被代理服务器缓存
• public：这个表示缓存既可以被浏览器缓存，也可以被代理服务器缓存
• no-store：这个属性表示不缓存，在任何情况下，都是与服务器进行最新的交互
• no-cache：这个并非不缓存的意思，这个表示强制进行协商缓存，会在下面描述

协商缓存

协商缓存表示在使用本地的缓存之前，会先向服务器发一个请求，与服务器协商当前浏览器的缓存是否已经过期了，如果没过期，那么就使用本地的资源，如果过期了就去请求最新资源。协商缓存主要是解决强缓存资源不能及时更新的问题，协商缓存服务端可以通过2种设置来实现：

第一种：last-modified 配合 If-Modified-Since

例如，客户端请求一个 03.jpg，服务端接收到这个请求后，会读取这个文件的最后修改时间，然后设置到响应头中，设置的参数就是 last-modified，参数值是文件最后修改的时间戳。客户端第二次请求 03.jpg 这个文件的时候，会带上一个 If-Modified-Since 参数，服务端能拿到这个参数与 last-modified 进行比对，如果一致，那么就返回 304 状态，否则就去请求最新的文件，使用 nodejs 实现这个代码：（注意协商缓存需要设置Cache-Control为no-cache，表示设置成协商缓存）

// 判断客户端请求的是03这个图片
if(pathname === '/img/03.jpg') {
// 读取 03 图片的最后修改时间
const { mtime } = fs.statSync("./img/03.jpg")
// 判断客户端发送过来的if-modified-since是否与mtime一致，如果一致就直接返回304
if(req.headers['if-modified-since'] === mtime.toUTCString()) {
res.statusCode = 304
res.end()
} else {
// 如果不一致，那么就请求最新的资源返回给客户端
const data = fs.readFileSync("./img/03.jpg")
// 这2句代码是设置协商缓存
res.setHeader("last-modified", mtime.toUTCString())
res.setHeader("Cache-Control", "no-cache")
res.end(data)
}
}

上面的 last-modified 配合 If-Modified-Since 在使用时有些弊端，例如将 03.jpg 修改成 04.jpg，再改回 03.jpg。此时这个文件其实是没有变化的，但是最后修改时间更改了，因此客户端就需要重新请求，因此就出现了下面的第二种使用Etag的方式

第二种：Etag 配合 If-None-Match

Etag实现的方式服务端是为文件生成一个指纹，类似于MD5字符串。接着响应头中塞进 Etag 参数，参数的值就是计算出的字符串，客户端接收到后，第二次请求会带上一个 If-None-Match 的参数，接着服务端和上面第一种方式一样进行比对，nodejs的实现代码如下：

// 引入 etag 模块
const etag = reqiure("etag")
if(pathname === '/img/03.jpg') {
const data = fs.readFileSync("./img/03.jpg")
// 获取生成的etag字符串
const etag = etag(data)
// 判断客户端发送的 If-None-Match 与服务端是否一致
if(req.headers['if-none-match'] === etag) {
res.statusCode = 304
res.end()
} else {
// 如果不一致，那么就请求最新的资源返回给客户端
const data = fs.readFileSync("./img/03.jpg")
// 这2句代码是设置协商缓存
res.setHeader("etag", etag)
res.setHeader("Cache-Control", "no-cache")
res.end(data)
}
}

Answer 1

http1.1才加了缓存机制吧

Answer 2

常见的HTTP 缓存首部字段有：

• Expires：响应头，代表该资源的过期时间

• Cache-Control：请求/响应头，缓存控制字段，精确控制缓存策略

• If-Modified-Since：请求头，资源最近修改时间，由浏览器告诉服务器

• Last-Modified：响应头，资源最近修改时间，由服务器告诉浏览器

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

• If-None-Match：请求头，缓存资源标识，由浏览器告诉服务器

其中， 强缓存 ：

• Expires（HTTP/1.0）
• Cache-Control（HTTP/1.1）

协商缓存：

• Last-Modified 和 If-Modified-Since（HTTP/1.0）
• ETag 和 If-None-Match（HTTP/1.1）

缓存过程分析

浏览器与服务器通信的方式为应答模式，即浏览器发起 HTTP 请求，服务器响应请求。在浏览器第一次发起请求时，会根据响应报文中 HTTP 头的缓存标识，决定是否缓存结果，如果是则将请求结果和缓存标识存入浏览器缓存中，简单的过程如下图：

由上图我们可以知道：

• 浏览器每次发起请求，都会先在浏览器缓存中查找该请求的结果以及缓存标识
• 浏览器每次从服务器端拿到返回的请求结果，都会将该结果和缓存标识存入浏览器缓存中

以上两点结论就是浏览器缓存机制的关键，它确保了每个请求的缓存存入与读取，只要我们再理解浏览器缓存的使用规则，那么所有的问题就迎刃而解了

本文也将围绕着这点进行详细分析。为了方便大家理解，这里我们根据是否需要向服务器重新发起HTTP请求将缓存过程分为两个部分，分别是：

• 强缓存： 向浏览器缓存查找该请求结果，并根据该结果的缓存规则来决定是否使用该缓存结果的过程
• 协商缓存： 强缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程

强缓存（缓存控制）

强缓存表示在缓存期间是否使用缓存（缓存是否有效），需不需要重新发送HTTP请求

控制强缓存的字段分别是 Expires 和 Cache-Control ，其中 Cache-Control 优先级比 Expires 高

Expires（HTTP/1.0）

值为服务器返回该请求结果缓存的到期时间:

Expires: Wed, 22 Oct 2018 08:41:00 GMT

表示资源会在 Wed, 22 Oct 2018 08:41:00 GMT 后过期，需要再次请求。

并且 Expires 受限于客户端时间，如果修改了客户端时间，可能会造成缓存失效。

所以现在 HTTP/1.1中新增了 Cache-Control

Cache-Control（HTTP/1.1）

Cache-control: max-age=30

该属性值表示资源会在 30 秒后过期，需要再次请求。也就是说在 30 秒内如果再次发起该请求，则会直接使用缓存，强缓存生效。

它与 Expires 相比：

• HTTP响应报文中 Expires 的时间值，是一个绝对值
• HTTP响应报文中 Cache-Control为max-age=600 ，是相对值（解决 Expires 受限于客户端时间）

除了 max-age ，它还有以下取值：

注意下面的 no-cache ，资源依然会被缓存，并且这个缓存要服务器验证后才可以使用

max-age=0 和 no-cache 等价吗？

从规范的字面意思来说，max-age 到期是 应该(SHOULD) 重新验证，而 no-cache 是 必须(MUST) 重新验证。但实际情况以浏览器实现为准，大部分情况他们俩的行为还是一致的。（如果是 max-age=0, must-revalidate 就和 no-cache 等价了）

总结

自从 HTTP/1.1 开始，Expires 逐渐被 Cache-Control 取代。Cache-Control 是一个相对时间，即使客户端时间发生改变，相对时间也不会随之改变，这样可以保持服务器和客户端的时间一致性。而且 Cache-Control 的可配置性比较强大。

Cache-Control 的优先级高于 Expires，为了兼容 HTTP/1.0 和 HTTP/1.1，实际项目中两个字段我们都会设置。

协商缓存（缓存校验）

如果缓存过期了:

• 没有 Cache-Control 和 Expires
• Cache-Control 和 Expires 过期
• 设置了 no-cache

需要发起请求验证服务器资源是否有更新：

• 有更新，返回200，更新缓存
• 无更新，返回304，更新浏览器缓存有效期

Last-Modified 和 If-Modified-Since（HTTP/1.0）

• Last-Modified（响应头）
• If-Modified-Since（请求头）

Last-Modified 表示本地文件最后修改日期，If-Modified-Since 会将 Last-Modified 的值发送给服务器，询问服务器在该日期后资源是否有更新，有更新的话就会将新的资源发送回来，否则返回 304 状态码。

但是这种方式存在着一些缺点，例如：

• 负载均衡的服务器，各个服务器生成的 Last-Modified 可能有所不同
• GMT 格式有最小单位，例如，如果在一秒内有更改将不能被识别

ETag 和 If-None-Match（HTTP/1.1）

为了解决上面的那个问题， HTTP/1.1 加了这组标记

• ETag（响应头）
• If-None-Match（请求头）

ETag 类似于文件指纹，是文件的一个唯一标识序列，当资源有变化时，Etag就会重新生成，If-None-Match 会将当前 ETag 发送给服务器，询问该资源 ETag 是否变动，有变动的话就将新的资源发送回来。并且 ETag 优先级比 Last-Modified 高

使用 ETag 就可以精确地识别资源的变动情况，就算是秒内的更新，也会让浏览器感知，能够更有效地利用缓存

ETag 强弱之分

ETag 机制同时支持强校验和弱校验。它们通过ETag标识符的开头是否存在“W/”来区分，如：

"123456789"   -- 一个强ETag验证符
W/"123456789"  -- 一个弱ETag验证符

强 ETag 要求资源在字节级别必须完全相符，弱 ETag 在值前有个“W/”标记，只要求资源在语义上没有变化，但内部可能会有部分发生了改变（例如 HTML 里的标签顺序调整，或者多了几个空格）

Vary 响应

服务器通过指定 Vary: Accept-Encoding ，告知代理服务器，对于这个资源，需要缓存两个版本：

• 压缩

• 未压缩

这样老式浏览器和新的浏览器, 通过代理, 就分别拿到了未压缩和压缩版本的资源，避免了都拿同一个资源的尴尬。

Vary: Accept-Encoding, User-Agent

如上设置，代理服务器将针对是否压缩和浏览器类型两个维度去缓存资源。如此一来，同一个url，就能针对 PC 和 Mobile 返回不同的缓存内容。

原文