Http协议：完全弄懂 Http 缓存机制 - 基于缓存策略三要素分解法

时间 2019-12-06

标签 http 协议完全弄懂缓存机制基于策略要素分解栏目 HTTP/TCP 繁體版

原文原文链接

转载：http://mp.weixin.qq.com/s/uWPls0qrqJKHkHfNLmaenQhtml

导语

Http 缓存机制做为 web 性能优化的重要手段，对从事 Web 开发的小伙伴们来讲是必需要掌握的知识，但最近我遇到了几个缓存头设置相关的题目，发现有好几道题答错了，有的甚至在知道了正确答案后依然不明白其缘由，可谓至关的郁闷呢！！为了确认下是否只是本身理解不深，我特地请教了其余几位小伙伴，发现状况也或多或少和我相似。web

为了避免给你们卖关子，下面我贴出2道题，你们能够尝试解答下：浏览器

如下为 page.html 内容：缓存

<!DOCTYPE html><html xmlns="http://www.w3.org/1999/xhtml"><head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <title>page页</title></head><body>
    <img src="images/head.png" />
    <a href="page.html">从新访问page页</a></body></html>复制代码

首次访问该页面，页面中 head.png 响应头信息以下：性能优化

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: image/png
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT
Accept-Ranges: bytes
Date: Thu, 10 Nov 2016 02:48:50 GMT
Content-Length: 3534复制代码

问题1：请问当点击“从新访问 page 页”连接从新加载该页面后， head.png 如何二次加载？bash
问题2：若是将上述信息中的 Cache-Control 设置为 private，那么结果又会如何呢？服务器

以上2道题，若是你能所有答对（哈哈，还请仔细确认下 why，以防歪打正着），那么恭喜你，你已对这些知识理解很是透彻了，我后面讲的内容你能够忽略，不然还请继续陪我往下唠唠吧！ide

首先回到开篇提到不少小伙伴（包括我）在解答 Http 缓存题目时栽跟头的问题，我以为出现这种现象的根本缘由在于咱们吸取的知识还不够体系化，平时咱们在学习这些知识时多半将其看成知识点来记，什么这个缓存头做什么、那个缓存头做什么用的，但实际中缓存头每每是多个之间相互配合协同工做的，有一套完整的工做体系。性能

今天我将按本身的理解，从系统体系化角度来说讲 Http 缓存头是如何协同工做的（不正确的地方还请指正，但请不要喷我哦）：学习

HTTP 缓存体系

首先我将 Http 缓存体系分为如下三个部分：

1. 缓存存储策略

用来肯定 Http 响应内容是否能够被客户端缓存，以及能够被哪些客户端缓存

这个策略的做用只有一个，用于决定 Http 响应内容是否可缓存到客户端

对于 Cache-Control 头里的 Public、Private、no-cache、max-age 、no-store 他们都是用来指明响应内容是否能够被客户端存储的，其中前4个都会缓存文件数据（关于 no-cache 应理解为“不建议使用本地缓存”，其仍然会缓存数据到本地），后者 no-store 则不会在客户端缓存任何响应数据。另关于 no-cache 和 max-age 有点特别，我认为它是一种混合体，下面我会讲到。

通过 Cache-Control：Public 设置咱们能够将 Http 响应数据存储到本地，但此时并不意味着后续浏览器会直接从缓存中读取数据并使用，为啥？由于它没法肯定本地缓存的数据是否可用（可能已经失效），还必须借助一套鉴别机制来确认才行，这就是咱们下面要讲到的“缓存过时策略”。

2. 缓存过时策略

客户端用来确认存储在本地的缓存数据是否已过时，进而决定是否要发请求到服务端获取数据

这个策略的做用也只有一个，那就是决定客户端是否可直接从本地缓存数据中加载数据并展现（不然就发请求到服务端获取）

刚上面咱们已经阐述了数据缓存到了本地后还须要通过判断才能使用，那么浏览器经过什么条件来判断呢？答案是：Expires，Expires 指名了缓存数据有效的绝对时间，告诉客户端到了这个时间点（比照客户端时间点）后本地缓存就做废了，在这个时间点内客户端能够认为缓存数据有效，可直接从缓存中加载展现。

不过 Http 缓存头设计并无想象的那么规矩，像上面提到的 Cache-Control（这个头是在Http1.1里加进来的）头里的 no-cache 和 max-age 就是特例，它们既包含缓存存储策略也包含缓存过时策略，以 max-age 为例，他实际上至关于：

Cache-Control：public/private（这里不太肯定具体哪一个）
Expires：当前客户端时间 + maxAge 。复制代码

而 Cache-Control：no-cache 和 Cache-Control：max-age=0 （单位是秒）至关

这里须要注意的是：

Cache-Control 中指定的缓存过时策略优先级高于 Expires，当它们同时存在的时候，后者会被覆盖掉。
缓存数据标记为已过时只是告诉客户端不能再直接从本地读取缓存了，须要再发一次请求到服务器去确认，并不等同于本地缓存数据今后就没用了，有些状况下即便过时了仍是会被再次用到，具体下面会讲到。

3. 缓存对比策略

将缓存在客户端的数据标识发往服务端，服务端经过标识来判断客户端缓存数据是否仍有效，进而决定是否要重发数据。

客户端检测到数据过时或浏览器刷新后，每每会从新发起一个 http 请求到服务器，服务器此时并不急于返回数据，而是看请求头有没有带标识（ If-Modified-Since、If-None-Match）过来，若是判断标识仍然有效，则返回304告诉客户端取本地缓存数据来用便可（这里要注意的是你必需要在首次响应时输出相应的头信息（Last-Modified、ETags）到客户端）。至此咱们就明白了上面所说的本地缓存数据即便被认为过时，并不等于数据今后就没用了的道理了。

关于 Last-Modified，这个响应头使用要注意，可能会影响到缓存过时策略，具体缘由，后面我会经过解答开篇提到的2道题来做说明。

以上就是我所认识的缓存策略，下面我将缓存策略三要素和经常使用的几个缓存头（项）结合一块儿，让你们更清晰的认识到它们之间的关系：

经过上图我能够清晰的看到各缓存项分别属于哪一个缓存策略范畴，这其中有部分重叠，它代表这些缓存项具备多重缓存策略，因此实际在分析缓存头的时候，除了常规的头外，咱们还须要将这些具备双重缓存策略的项分解开来。

最后咱们回到最开始提到的2道题目，咱们来一块儿分解下：

第一道题：

HTTP/1.1 200 OK
Cache-Control: no-cache
Content-Type: image/png
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT
Accept-Ranges: bytes
Date: Thu, 10 Nov 2016 02:48:50 GMT
Content-Length: 3534复制代码

分析上述 Http 响应头发现有如下两项与缓存相关：

Cache-Control: no-cache 
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT复制代码

咱们上面讲到了 Cache-Control: no-cache 至关于 Cache-Control: max-age=0，且他们都是多重策略头，咱们需将其分解：

Cache-Control: no-cache 等于 Cache-Control: max-age=0，
接着 Cache-Control: max-age=0 又可分解成：

Cache-Control: public/private （不肯定是两者中的哪个）
Expires: 当前时间复制代码

最终咱们获得了如下完整的缓存策略三要素：

因此最终结果是：浏览器会再次请求服务端，并携带上 Last-Modified 指定的时间去服务器对比：

a）对比失败：服务器返回200并重发数据，客户端接收到数据后展现，并刷新本地缓存。
b）对比成功：服务器返回304且不重发数据，客户端收到304状态码后从本地读取缓存数据。如下为模拟此种状况下请求后的抓包状况：

这道题自己不难，但若认为 no-cache 不会缓存数据到本地，那么你理解起来就会很矛盾，由于若是文件数据没有被本地缓存，服务器返回304后将会没法展现出图片内容，但实际上它是能正常展现的。这道题很好的证实了 no-cache 也会缓存数据到本地这一说法。

第二道题：

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: image/png
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT
Accept-Ranges: bytes
Date: Thu, 10 Nov 2016 02:48:50 GMT
Content-Length: 3534复制代码

解题思路和上题同样，首先先找到缓存相关项：

Cache-Control: private     
Last-Modified: Tue, 08 Nov 2016 06:59:00 GMT复制代码

这时咱们会发现根本找不到缓存过时策略项，那答案会不会和上面同样？一时半会也分析不出答案，那只能实际测试下了：

再看看 Chrome 浏览器下抓包：

能够看到，浏览器后续请求都直接取的本地缓存，看来的确存在某种缓存过时策略（根据我上面的缓存过时策略理论，浏览器若是直接从本地加载缓存数据，说明它相信本地缓存数据有效，那必定存在某种缓存过时判断条件）。这个问题百思不得其解，困扰了我很久，直到一次偶然的机会我在 Fiddler 响应信息面板里的 Caching 选项卡中找到了答案：

原来，在没有提供任何浏览器缓存过时策略的状况下，浏览器遵循一个启发式缓存过时策略：

根据响应头中2个时间字段 Date 和 Last-Modified 之间的时间差值，取其值的10%做为缓存时间周期。

贴一下Caching面板里的描述，英语好的同窗能够精准翻译下：

HTTP/1.1 Cache-Control Header is present: private
HTTP Last-Modified Header is present: Tue, 08 Nov 2016 06:59:00 GMT
No explicit HTTP Cache Lifetime information was provided.
Heuristic expiration policies suggest defaulting to: 10% of the delta between Last-Modified and Date.
That's '05:15:02' so this response will heuristically expire 2016/11/11 0:46:01.复制代码

最终咱们获得了如下完整的缓存策略三要素：

最终结果

浏览器会根据 Date 和 Last-Modified 之间的时间差值缓存一段时间，这段时间内会直接使用本地缓存数据而不会再去请求服务器（强制请求除外），缓存过时后，会再次请求服务端，并携带上 Last-Modified 指定的时间去服务器对比并根据服务端的响应状态决定是否要从本地加载缓存数据。

总结

Http 缓存设置起来并不复杂，但却容易被轻视，今天这篇文章结合2道题目，经过分析、解剖相关缓存头，从系统化角度对 Http 缓存机制作了一个较完整的剖析：Http 缓存机制其实是 Http 缓存策略三个要素（纬度）相互做用的集合，因此在分析和设置 Http 报文缓存头时，只要能从中精准的分解出缓存三要素，咱们就能很是准确的预判到缓存设置最终能达到的效果。