关于http:HTTP-缓存技术

HTTP 缓存技术

缓存技术呈现在 HTTP1.1 当中，目标是尽可能的缩小对于服务器进行申请。为了实现缓存技术，HTTP 设计者在头部字段减少针对缓存的头部字段。HTTP 缓存有两种形式，强制缓存 和协商缓存。

意识缓存

介绍具体的缓存技术之前，咱们先来认识一下 HTTP 中的缓存特点。

留神 缓存只对获取文件无效，从服务器上拿到文件而后放入本地缓存，下次再获取则从本地缓存区获取文件，这样能够加重服务器压力。

缓存技术在 HTTP 中的体现是通过几个申请字段的配合，依照肯定的判断流程管制。HTTP1.1 次要通过上面三个申请头部信息断定缓存有效性：

• Cache-Control：服务器能够返回此字段指定浏览器和两头缓存应该存活多久。
• ETag：浏览器缓存过期的时候，通过 Etag 令牌查看文件是否呈现扭转。Etag 是非凡算法计算的惟一哈希值。
• Last-Modified：和 Etag 用处雷同，然而它是基于工夫的策略查看是否更改。

这三个字段根本囊括大部分 HTTP 缓存技术的利用场景。

缓存地位

缓存地位通常存在上面几种：

• Service Work
• Memory Cache
• Disk Cache（罕用）
• Push Cache

Service Work

通常运行在浏览器的后盾，次要性能是实现缓存，应用此组件须要申请协定为 HTTPS，因为 Service Work 自身会拦挡申请，须要 HTTPS 保障平安能力应用。

Memory Cache

内存中的缓存，次要是以后页面曾经捕捉的资源。比方图片，脚本等，这种形式要比 Disk Cache 要快上十分多，然而留神这个缓存寿命十分短，一旦敞开 Tab，内存缓存会随着页面的敞开立马开释。

内存缓存中有一块重要的缓存资源是 preloader 相干指令，也是页面优化的伎俩之一，能够做到解析脚本和 CSS 文件的同时申请下一个资源。

Disk Cache

Disk Cache 存在于磁盘的缓存，读取尽管慢一点，然而能够实现长久化存储，并且容量比内存缓存要宽泛很多。

Disk Cache 的覆盖面在浏览器中占用比重很大，通常联合 HTTP 头部字段进行判断，如果跨站点下载文件，曾经下载过的文件不会再次申请，而是间接从Disk Cache 获取。

如何判断缓存进内存还是进磁盘？
通常有两个根据：

1. 如果是大文件，通常会进入磁盘当中进行缓存。
2. 如果是频繁拜访的文件，也会放入磁盘。

Push Cache

推送缓存是 HTTP/2 新退出的内容，下面三种状况都没有命中的时候才会尝试应用。它是会话级别缓存，一旦会话完结，也会立刻开释缓存，生命周期只比内存缓存长一点点。

缓存过程

缓存的大抵流程如下：

1. 客户端发动 HTTP 申请拜访浏览器缓存，浏览器不存在缓存，告知客户端让它从新发申请。
2. 客户端再次发动 HTTP 申请到原始服务器，原始服务器返回后果和缓存规定。
3. 客户端再次发动申请，从浏览器的缓存中获取申请后果。

留神第一步是隐式解决的，所以缓存过程次要有两个要点：

• 每次申请都会查看浏览器是否存在缓存标识，以及申请的缓存后果。
• 如果没有非凡字段禁用缓存，缓存将会把申请后果缓存存在浏览器缓存当中。

缓存断定次要依赖两项技术：强制缓存 和协商缓 存，也是 HTTP 缓存技术的要点。将在下文进行进行介绍。

Pragma 头部

Pragma 于 HTTP1.0 中定义，单词含意叫做“编译指令”，简直能够蕴含任何内容，目标是给浏览器发送申请中进行一些指令操作，然而次要的利用场景是缓存操控。

Pragma 次要作用是放弃 HTTP1.0 向后兼容，因为 缓存技术是在 HTTP1.1 中才呈现 的。

比方让一些 HTTP1.0 的源服务辨认客户端了解”无缓存“的申请头部，这时候 Prama 就能够派上用场。

Pragma 如果被发送，将会利用于所有的应用程序和客户端。如果存在 HTTP1.1 缓存技术的相干申请头部字段，在 服务器能够辨认的前提下，会优先解析 HTTP1.1 的申请头部，从而疏忽 Pragma 头部。

然而这里介绍的所有内容都是 HTTP1.0 约定俗成的货色。HTTP1.0 自身不能算作规范，只能算作“草稿”，所以 Pragma 既没有明确标准，也没有可靠性，当初的网络环境这个字段根本不再应用。仅仅是有可能的向后兼容场景中用到。

介绍这些内容，只是让大家晓得点历史。

Pargma 头部应用形式

根本语法 Pragma: 1# pragma-directive
举例 Pragma: no-cache（实际上也是惟一取值）

强制缓存

强制缓存指的是只有浏览器没有过期，就应用缓存进行返回，主动性在浏览器方。

比方上面的申请当中，应用了缓存进行返回，强缓存利用两个响应头部实现，绝对工夫“Cache-Control” 以及 “Expire” 相对工夫 两个字段。

在讲述 Cache-Control 之前咱们先停一下，先来理解前面这个过期的货色Expires。

Expires 有什么用？ 这个字段的作用是设置一个非凡的工夫，一旦超过这个工夫，就会过期。简而言之就是所谓的 相对工夫，比方咱们设置工夫为 Expires：Sat，13 May 2022 07:00:00 GMT，意味着一旦超过这个工夫就会生效。

然而这个工夫是存在问题的，尽管原始服务器的工夫无奈更改，然而 客户端工夫是能够自在改变的，这样就会导致客户端工夫和服务器工夫不统一，呈现缓存一致性问题，你也能够把这种乱改工夫的形式叫做the world（砸瓦鲁多）。

此外 Expires 日期工夫必须是格林威治工夫（GMT），而不能是本地工夫，也不能随便指定日期格局，局限性比拟大。

如果设置的 Expires 过期工夫是固定工夫，然而返回之前没有没有更新下一次过期工夫，那么每一次客户端的申请都会进入到服务端，会加大服务端压力，缓存的意义也就生效了。

于是 Cache-Control 针对 Expires 的局限性进行改良而在 HTTP1.1 中退场。

如果同时有 Cache-Control 和 Expires 字段，Cache-Control 的优先级高于 Expires。所以通常状况下不倡议应用 Expires，如果非要应用，倡议用在动态资源上给资源设置相对过期工夫，或者作为双保险兼容所有 HTTP 代理服务应用。

此外 Cache-Control 和Expires这两个字段的区别是 Cache-Control 字段的选项要多一些，Cache-Control 是 HTTP1.1 标准协议中呈现并举荐应用的，Expires 是 HTTP1.0 的规定，然而 HTTP1.0 并不是明确规范，不具备任何约束力。

HTTP 1.0 尽管明面上属于草稿纸协定，Expires 看似也不举荐应用，然而后续的协定并没有废除它，所以还是有肯定的存在意义的（前后兼容问题）。

首部字段 Expires 会将资源生效的日期告知客户端。如果不心愿资源被缓存，则倡议把首部字段 Expires 和首部字段 Date 设置雷同的工夫。

强制缓存的应用策略

• 第一次拜访服务器资源，服务器会在返回资源的同时返回这两个字段，同时为这两个字段设置过期工夫。
• 浏览器第二次乃至更屡次拜访，首先比对 Cache-Control的工夫是否过期，如果有就应用缓存，没有就 从新申请。
• 再次申请会更新 Cache-Control，之后以此重复。

Cache-Control例子

例子网址：https://web.dev/i18n/en/http-cache/#examples

Cache-Control 字段选项

• max-age：此参数为高优先级，代表缓存的最大存活工夫，单位为秒，其实工夫为客户端承受响应的那一刻计算。
• no-cache：浏览器在每次应用缓存之前都必须应用服务器从新验证。留神这个字段并不是禁用缓存的真正含意，这里临时卖个关子，下文持续解释。
• no-store：缓存不应该缓存任何客户端和服务端的内容，实际上的 不应用缓存。和 no-cache 的区别是这个设置齐全才是实在的不应用缓存。
• public：示意资源能够由任何代理进行缓存。
• private：示意指定资源专属于特定用户，尽管仍然能够缓存，但 只能在客户端缓存，比方公有的网页响应由桌面浏览器缓存，不能给 CDN 进行减速。

留神在 Cache-Control 指定 max-age 的属性时候，比起首部字段 Expires，会优先解决 max-age。

在 《HTTP 权威指南》 能够看到更多字段解释，下面仅仅列举一些常用字段。

重点关注 no-cache，很容易误会含意的一个属性。

s-maxage

有时候咱们会看到上面的申请属性：s-maxage

它所示意的含意是笼罩 max-age 或者 Expires 头，然而仅实用于共享缓存 (比方各个代理)，公有缓存会疏忽它（private）。

Cache-Control 案例

通过上面的案例能够看到，内容是从 disk cache 本地返回的，没有申请服务器。

强制缓存除了 from disk cache 之外，还有可能遇到应用 from memory cache 进行返回，示意同样不会拜访服务器，然而返回的内容是从内存中来的，并且因为是内存所以如果敞开以后页面会被立马开释。

更多无关 Cache-Control 的内容能够看看上面的材料网站。

Cache-Control – HTTP | MDN (mozilla.org)

Expires 和 Cache-Control 两者比照

这个比拟容易被问到，所以这里再啰嗦一遍。其实实质上区别并不是很大，只不过 Expires 是 HTTP1.0 呈现的，要比 Cache-Control（HTTP1.1）出得早而已，并且 Cache-Control 自身就是为了替换 Expires 而存在的。

尽管目前大部分网站都是反对 HTTP1.1 的，然而如果真的碰到只能辨认 HTTP1.0 的服务器，此字段仍然有存在价值，所以这种做法只是一种保障前后兼容的稳固而已。

Cache-Control 流程图

图来自老外的博客：# Prevent unnecessary network requests with the HTTP Cache

须要留神最初一步的 Etag，是协商缓存中的重要判断根据，这部分内容会在下文解释。

no-cache VS no-store

“no store”申请指令批示缓存不能存储此申请或对其的任何响应的任何局部。

The “no-store” request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches.

no-store 比拟好了解，它是真正意义上的不应用缓存，含意是禁用两头代理（浏览器，CDN，缓存服务器、代理）缓存响应内容，行为相似非代理缓存服务，一旦碰到缓存就会删除。

“no cache”申请指令示意，如果未在源服务器上胜利验证，缓存不得应用存储的响应来满足申请。

The “no-cache” response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server.

下面是 RFC 协定的原话，这个定义非常容易误会，暗藏的含意是：实际上no cache 是会进行缓存的。

什么时候缓存呢？在与原始服务器进行新鲜度再验证之前，缓存不能将其提供给客户端应用。而如果再度验证服务器没有对于内容进行更改，那么还是应用缓存数据进行解决。

简而言之就是一句话：如果服务器没有更新内容，那么就会缓存数据，否则须要从新申请和服务器进行验证比对。

大多数人会了解错这一层含意，会误认为是“不承受服务器的缓存响应”，实际上它是会承受的。《HTTP 权威指南》解释说这个首部更适宜用 do-not-serve-from-cache-without-revalidation（不须要申请服务，间接用缓存，除非服务器从新验证） 这个名字会更失当一些，咱们同样能够依照作者的倡议进行了解。

然而这里必定又会问，你都 no-cache 了我怎么晓得什么时候响应新内容呢？

先别急，这里有一套略微简单的判断机制：协商缓存，学货色一点一点来，咱们接着看其余几个强制缓存的问题。

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

这个问题比拟偏门，然而作为面试题角度比拟刁钻。

两者的区别是 max-age=0 通常是通知浏览器 倡议 刷新缓存，max-age=0是 非强制性（Should） 的，no-cache要求强制和服务器进行验证才容许应用缓存，所以no-cache 具备强制（MUST）性。

然而怎么解决还得看浏览器的设计，所以不思考浏览器设计的因素下，能够认为行为比拟统一，或者间接自信点：它们差不多。

什么样的申请办法会被缓存？

• GET 申请通常具备缓存生效。
• HEAD 办法跟 GET 办法雷同，只不过服务器响应时不会返回音讯体，所以 HEAD 申请会被缓存。（比拟容易被疏忽）
• PUT 无奈被缓存。
• POST 缓存在指定明确的过期请柬申请字段的时候能够应用，然而根本没有被施行。

HEAD 很容易被疏忽，实际上它具备肯定的作用：

• 查看连贯是否沉闷（active）。
• 查看网页是否存在改变。
• 多用于获取 RSS，网站标记等信息的场景应用。

缓存优先级判断

采纳上面的程序：

1. 如果是共享缓存并且存在s-maxage，则为最高优先级。
2. 查看是否存在 max-age。
3. 查看是否存在 Expires，须要应用此工夫减去响应字段的 Date 字段值，算进去的数值就是有效期。

须要揭示这些工夫是不会和时区产生影响的，因为返回的都是 原始服务器的工夫。

然而在这里咱们发现一个问题，如果下面条件都不满足，如果 不存在到期工夫 咋办？

因为原始服务器的工夫并不是总是牢靠的，如果申请当中没有任何“新鲜度“（max-age、Expires 等过期工夫）设置，申请头部也没指定任何禁用缓存和任何限度，那么这时候须要用 heuristic expiration time 这个值。

heuristic expiration time（中文说法：启发式缓存工夫），在《HTTP 权威指南》叫做试探性过期工夫，其实是利用其余字段的算出一个“正当”的估计值（也就是 Last-Modified）。

对于计算的办法，在 RFC 标准柄中没有强制如何设计，而是在协定中给出上面这句话：

If the response has a Last-Modified header field (Section 2.2 of [RFC7232]), caches are encouraged to use a heuristic expiration value that is no more than some fraction of the interval since that time. A typical setting of this fraction might be 10%.

如果响应具备 Last-Modified header 的标头字段（RFC7232 的第 2.2 节），则激励缓存应用启发式缓存工夫值 ，该值会计算一个不超过自该工夫起距离 * 某个比例（的工夫）。 比例的经典设置可能为 10%。

这是嘛意思？没看懂呀，其实这里要分割 RFC 原文的前后文了，这里就不贴英文了。大抵意思是在优先级判断中的第三点判断，有效期计算被定义为Expires-Date 字段。

如果服务端返回Last-Modified header，则计算形式为 Date 字段 – Last-Modified 字段值。

然而如果间接这样计算有可能会太长了，RFC 给出 10 % 的倡议值。这个倡议值有这两点思考：

• 很久之前寄存的文档个别不会更改，所以留在缓存很平安，10% 估计值的比率尚且能够承受（？）。
• 频繁更新的内容通常缓存收益很小，应用估计值 10% 能够尽可能减少缓存工夫，尽可能的返回最新内容。

更新频率不同长短的资源都能收益，这样看起来这解决形式是不是很不错呀？然而
想法是好的，事实是这样做会带来更多麻烦，这点放到上面探讨。

总而言之，不满足缓存优先级判断，浏览器通常会用 Last-Modified 字段值 计算一个适合的参考值作为缓存过期工夫存在，最终的计算公式为：

Last-Modified Time - Date * 0.1 (10%)`

当存储的响应中存在显式过期工夫时，缓存不得应用启发式缓存工夫来确定新鲜度。不能应用此算法。官网这话是在暗示你要尽量给资源设置缓存过期工夫，因为我倡议的这货色不是特地靠谱。

目前少数浏览器应用 LM-factor 算法（也就是下面的公式），应用的也是 RFC 协定倡议的比例 10 %，20% 这个说法当初来看曾经过期。

10% 以及乐观预计根据：
This specification does not provide specific algorithms, but does impose worst-case constraints on their results.
本标准未提供具体算法，但对其后果施加了最坏状况束缚，所谓的最坏状况束缚就是 10%。

113 响应状态码

这里有个偏门的 113 响应状态码，示意如果缓存应用了超过 24 小时的无效工夫并且响应工夫大于 24 小时，不应该采取任何操作。1XX 状态码须要后续的确认操作。

然而实际上很多浏览器压根没有搭理过这个倡议，也没有做响应措施，这一点须要留神。

如果 Last-Modified 都没有怎么办？

乖乖，如果这都没有的话，缓存通常会为没有任何陈腐周期线索的文档，调配一个默认的陈腐周期（通常是一个小时或一天）。

有时比拟激进的缓存会将这种试探性陈腐生存期设置为 0，强制缓存在每次将其提供给客户端之前验证一下这些数据是否依然是陈腐的。

启发式缓存工夫害处

凡事都有例外，启发式缓存工夫本意是好的，然而存在显著的弊病。

如果一个文件超过一个月没设置过期工夫，并且曾经通过一个月的工夫，这时候发现文件存在重大问题，须要立即修复。

这时候一旦批改，会导致上个版本 3 天之后才过期（1 个月的 10%= 3 天左右），意味着更新一个文件须要至多 3 天（20% 就是将近一周），申请才会传新文件。如果应用 CDN，这个工夫还会更长。

当然这种问题解决方案也很多，比方在设置文件的时候带上 版本号或者编号，比方对外进行 302 长期重定向到另一个地位并且设置过期工夫，或者先删文件再后从新增加，并且手动强制同步。

综上所述，尽量不要应用启发式缓存，尽量给每个申请设置过期工夫，然而也不要设置过长时间，长时间的强缓存会因为 CDN 等缓存服务器的关系导致一个资源迟迟难以更新（哪怕没有启发式缓存工夫）。

新协定对 RFC2616 的改变

注：[RFC2616] 第 13.9 节禁止缓存计算带有查问组件的 URI 的启发式新鲜度（即蕴含“？”的 URI）。此项在实践中，这并没有失去宽泛推广。

综上所述，如果源服务器心愿排除缓存，则激励它们发送显式指令（例如，缓存管制：无缓存）。

新响应的计算形式

上面这个公式是判断根据：

response_is_fresh = (freshness_lifetime > current_age)

判断根据非常简略，新鲜度的工夫是否超过寿命，超过寿命就须要抛弃缓存从新申请。也正是因为这种简略粗犷的手法，使得缓存既可能提供便当的同时，不至于对于用户拜访造成过多影响。

响应表头设置倡议

因为启发式缓存工夫的存在，强烈建议重要的文件资源都加上缓存有效期。针对缓存有效期的响应头设计，通常有上面的几点倡议：

版本化 URL

比方针对 CSS 文件设置了长达一年的缓存过期工夫，如果呈现长期更改，有的用户如果刚好革除缓存能够看到最新的内容，而没有革除缓存的可能拿到本地旧版本文件。这样能够有更好的用户体验，旧缓存数据的用户在刷新缓存之后就能够看到新内容。

通常状况下，在文件名中嵌入文件的版本号来执行此操作，例如style.x234dff.css。

无版本化 URL

如果是没有版本化的 URL 很久忽然要进行更新，则须要尽量增加头部。

Cache-Control值能够帮忙咱们微调未版本化 URL 的缓存地位和形式：

• no-cache：缓存申请以后 URL 的版本数据之前须要和服务器进行验证。
• no-store：屏蔽两头代理服务器的缓存行为，不存储缓存文件。
• private：浏览器能够缓存文件，然而两头代理缓存服务器不能缓存。
• public：响应能够被任何缓存进行存储。

协商缓存

缓存失效的状况下，浏览器会返回 304 状态码。协商缓存是在强制缓存生效之后，须要从新比照缓存，由服务器决定是否生效的一种机制。

304：申请的资源没有扭转，然而被重定向到已缓冲的文件，所以也叫做缓存重定向，这个子弹次要是用于缓存解决。

协商缓存的申请步骤通常分为两步。

首次拜访：

客户端申请仍然须要发送到服务端，然而服务端会告诉浏览器缓存申请响应信息，浏览器这时候会偷偷缓存申请。

第二至更屡次拜访：

1. 假如客户端申请资源曾经过期，则在申请中携带 Etag 拜访服务器。2. 服务器比对 Etag 进行校验，比拟是否和本地统一。3. 如果统一返回 304，浏览器能够持续应用资源。4. 如果不统一就须要从新返回申请后果，再次进行缓存。

协商缓存实际上就是浏览器和服务器进行协商通过协商的后果判断是否应用本地缓存。

次要波及的申请头部

留神这里一共有 两组四个字段 进行判断，ETag和 If-None-Match（一组），If-Modified-Since 字段与 Last-Modified 字段（一组）， 前者优先级比后者高，同时呈现会呈现“短路效应”。

ETag和If-None-Match

两者的值都是资源的惟一标识符（理论为文件资源的哈希散列值）。

判断过程如下：

• 浏览器申请资源，原始服务器返回报文中退出 Etag 值，资源更新则 Etag 值也会更新。
• 浏览器再次申请资源，此时申请报文会退出If-None-Match，值为上一次响应报文的 Etag 值。
• 服务器比对报文的 If-None-Match 和以后的 Etag 是否统一，不统一则更新 Etag 并且返回，下一次浏览器申请 Etag 将传输新的值。如果统一示意资源没有更新，状态码返回 304，浏览器从本地缓存获取，此时响应头会同时返回 Etag 值。（尽管没有变动）

If-Modified-Since 字段与 Last-Modified 字段

位于申请头部的If-Modified-Since 字段以及位于响应头部中的 Last-Modified 字段。

• 响应头部中的 Last-Modified 字段：示意资源的Last-Modified（最初批改工夫）。
• 申请头部的If-Modified-Since 字段：资源过期并且接管响应头部呈现 Last-Modified（最初批改工夫）申明，会发送此字段，并且此字段值等于Last-Modified（最初批改工夫）。

判断流程如下：

• 浏览器第一次向服务端申请之后，服务端响应中退出 Last-Modified 字段，示意资源最初一次批改工夫。
• 浏览器再次申请，在申请报文中会退出If-Modified-Since 字段，字段值等于上一次浏览器返回的Last-Modified（最初一次批改工夫）。
• 服务器比对 Last-Modified 和If-Modified-Since 字段，如果不统一则承受申请并且返回更新之后的资源，如果统一示意资源没有更新，返回 304 状态码，此时浏览器会从本地缓存获取资源文件。值得注意的是， 本地申请如果是 304，此时响应头中不会再增加 Last-Modified 字段。

协商缓存和强制缓存流程图

这个图来自参考文章的第一篇，画的很棒，为作者点个赞：

留神：If-None-Match 和 If-Modified-Since 的关系是：If-None-Match && If-Modified-Since。

上面的图和下面相似，不过把 If-None-Match 和 If-Modified-Since丰盛了一下：

如果同时发送 If-None-Match、If-Modified-Since 字段怎么解决

此时服务器只有比拟 If-None-Match 和ETag的内容是否统一即可，内容统一则返回 304 并且仍然应用，不统一则返回新的申请后果，并且从新缓存。

If-None-Match判断优先级总是要高一些，IETF 同样如此倡议。

Etag 和 Last-Modifed 比照

Etag和 Last-Modifed 成果是雷同的，为什么雷同的性能须要两个字段管制？

首先说一下论断，Etag 实际上更为举荐并且更常应用，因为它的细粒度更小，上面咱们举个例子，再进行总结。

咱们先来举个栗子，假如一个资源从资源申请开始到以后申请过来了 120 秒靠近过期节点，并且浏览器启用了同一个资源的新申请，此时 HTTP 刚好卡在过期节点之前找到缓存。尽管查到的缓存在获取那一刻是没有过期的，然而他不能这么干，因为此时在浏览器看来 响应曾经过期了，浏览器须要从新发一个新申请取得残缺响应。

下面的例子本意是好的，然而如果资源没有呈现扭转，就没有必要下载曾经在缓存本地的信息，这么做显著是节约服务器资源。如果很多个申请都在这个临界点拜访，这样会加大服务器资源的节约。

所以基于工夫的判断是不牢靠的，Etag 标头负责查看文件内容的哈希码，浏览器不须要晓得哈希算法，只须要拿客户端申请的 Etag 值和以后本地缓存比对即可，如果 Etag 值统一，哪怕此时申请资源响应曾经过期了，仍然能够用本地缓存文件返回，跳过下载步骤。

有了下面的案例，上面咱们晓得了为什么要引入 Etag，上面是相干 论断。

论断

• 有时候文件仅仅是改了日期（比方从新传了一份截然不同的笼罩），咱们能够认为文件内容是没有扭转的，仍然能够用本地缓存而不是 GET 申请。
• 文件如果改变十分频繁然而内容没有扭转，Last-Modifed是 S（秒）级，管制粒度大，很容易呈现申请响应过期，并且频繁的从新下载。
• 某些服务器不能准确示意最初批改工夫，只能给出抽象的日期。

总的来说就是基于工夫的判断是不牢靠的，应用 Etag 值能够更加准确管制缓存，所以引入服务器主动生成 Etag 校验码作为惟一标识符，如果资源频繁改变会从新生成 Etag 值，然而如果资源只是频繁的刷新批改日期，则 Etag 不变。

在默认的状况下这两个值能够一起应用，然而牢记 优先校验 ETag（起因请看下面的栗子）。

用户行为对缓存影响

这里间接用了网上的一张图，次要记住几个有效的项即可。

上面是日常用户操作

1. 大部分网站关上网页通常优先查看 disk cache，有就应用，没有就发送申请。
2. F5 刷新，因为此时 TAB 没有敞开，应用 memory cache 是可用的，会被优先应用，而 disk cache 会被滞后应用。
3. 强制刷新 (Ctrl + F5)：浏览器不应用缓存，因而发送的申请头部均带有 Cache-control: no-cache(为了兼容，还带了Pragma: no-cache)，此时返回 200 状态码和最新内容。

缓存策略倡议

因为缓存是作用于文件的，而文件资源根本状况有两种：频繁改变的资源 和短暂不变动的资源。

频繁变动的资源：

• 首先须要应用 Cache-Control: no-cache 使浏览器每次都申请服务。
• 配合 ETag 或者 Last-Modified 来验证资源是否无效。

这样的解决办法能够显著的缩小响应内容的大小。

短暂不变的资源：

间接给一个Max-age=31536000 一年的工夫让浏览器强制应用缓存，所以通常倡议在文件名中退出哈希码和版本号等信息，避免短暂缓存文件忽然须要更新的时候能及时反馈给客户端。

参考文章

一张图了解 Http 缓存 – SegmentFault 思否

RFC7234 中文翻译 中文 RFC RFC 文档 RFC 翻译 RFC 中文版 (rfc2cn.com)

【第 1398 期】一文读懂前端缓存 (qq.com)

Prevent unnecessary network requests with the HTTP Cache (web.dev)

# 深刻了解浏览器的缓存机制