图解 HTTP 的缓存机制 | 实用 HTTP

题图：by @joewakeford

1、序

Hi，你们好，我是承香墨影！

HTTP 协议在网络知识中占据了重要的地位，HTTP 协议最基础的就是请求和响应的报文头（Header），大多数 Http 协议的使用方式，都是依赖设置不一样的 HTTP 请求/响应 的 Header 来实现的。

本系列《实用 HTTP》就抛开常规的 Header 讲解式的表述方式，从实际问题出发，来分析这些 Http 协议的使用方式，究竟是为了解决什么问题？同时讲解它是如何设计的和它实现原理。

HTTP 协议是一种无状态的“松散协议”，它不会记录不一样请求的状态，而且由于它自己包含了两端（客户端和服务端），根据请求和响应来区分，它大部分的内容都只是一个建议，其实双边是能够不遵照此建议的。例如：服务端说，这个数据缓存有一天的时效性，可是客户端能够说，我不听我不听，我就要每次去从新请求。

“这里写了建议零售价 2 元...”

“哦，不接受建议！”

说到缓存，本文就来讲说 HTTP 缓存相关的内容。

2、HTTP缓存使用

2.1 为何须要缓存

缓存说白了就是为了快，不管是从磁盘到内存仍是从网络到本地，都是为了在下次实用此资源的时候，可以快速响应，避免屡次的 I/O 操做。

经过网络获取资源，是一件耗时的操做，较大的资源还会须要客户端和服务端之间进行屡次往返通讯，这不但会增长客户端响应的时间，同时还会增长网络流量。

在 HTTP 协议中，自然就有对缓存的支持，浏览器和 App 使用的开源网络库中，都是利用 HTTP 缓存来实现对资源的缓存。

浏览器是自然支持 HTTP 缓存，开源库则须要进行一些例如存规则和缓存的资源存放路径之类的简单设定。

2.2 设计一个缓存策略

那若是让咱们来设计缓存的策略，首先有两个重要的指标须要考虑。

1. 缓存失效

既然缓存主要是针对数据的复用，那咱们就须要有一个条件来断定当前缓存的数据，是否依然有效。

老是不能一次缓存，终身使用吧，咱们还须要在缓存失效以后，从新获取新的数据并进行缓存。这个前提就是，缓存都须要有一个失效的策略。

2. 减小读取

虽然缓存会有失效策略，可是这只是客户端单方面认为失效，此时应该再去服务端从新获取一遍数据。

可有些状况下，其实资源可能依然有效，并无发生变更。那就须要有一个策略，让服务端通知客户端，当前缓存依然有效，能够继续使用。这样在减小传输流量以外，也能够加快相应时间，提升效率。

这就是一个好的缓存策略必需要考虑的地方，实际上 HTTP 缓存，也是这样设计的。

2.3 HTTP 缓存

HTTP 缓存主要是经过请求和响应报文头中的对应 Header 信息，来控制缓存的策略。

这里主要涉及两个 Header：

• Cache-Control：设定缓存策略，是否使用缓存，超时时间是多少。
• ETag：当前返回数据的验证令牌，多是 Hash 值也多是其余指纹，主要用于在下次请求的时候携带上，让服务端依此判断当前数据是否有更改。

服务端在返回响应数据的时候，会在报文头中，增长用于描述当前响应的内容类型、数据长度、缓存策略（Cache-Control）、验证令牌（ETag）等信息。

例如上图就表示了一次请求响应的事务，大概客户端请求一个文件的时候，服务端返回了一个 200 的状态码，表示响应正常，响应的数据长度为 1024 个字节，建议客户端将此资源缓存最多 120 秒，而且提供了一个指纹令牌（“cxmyDev123”），用来做为当前数据的惟一标识。

2.4 ETag 数据令牌

Cache-Control 中设定的 max-age 很好理解，就是设定缓存超时的时间，HTTP 缓存是限定一个超时的秒数，来肯定缓存失效的时间。

上古时期还会使用 expires 来决定超时的日期，可是已经被废弃了，若是和 Cache-Control 同时存在，以 Cache-Control 为准。

在此时间间隔范围内，客户端不会再向服务端发送新的请求。当资源距离上一次缓存的时间间隔，大于 120 秒后，客户端才会再次向服务端发送请求。

假如没有数据令牌的状况下，大概步骤应该是这样的：

1. 客户端会首先找到本地缓存，而后发现它已经失效，没法再次使用。

2. 客户端再次向服务端发出新的请求，并获取完整的数据再次进行缓存。以后再刷新该缓存的超时时间。

可是这是一件效率很是低的事情，服务端并没有法肯定所持有的源资源何时会失效，因此提供的 max-age 值，只是一个参考值，是须要取平衡的，过短会致使请求频繁，太长又会致使没法及时刷新客户端资源。而此时再次请求的时候，是存在必定的几率，客户端缓存的数据和服务端上持有的数据是一致的，咱们就不须要再次对此数据资源进行二次缓存，直接使用客户端以前缓存的数据便可，同时还须要刷新缓存超时时间。

这正是数据验证令牌（ETag）想要解决的问题，服务端生成并返回的这个数据指纹令牌，一般就是返回数据的 Hash 值或者其余数据指纹，客户端无需关心它的生成规则，只须要知道它是当前数据的一个惟一标识。

客户端须要在下次请求时将其经过 If-None-Match 这个请求报文头，将此验证令牌发送至服务端，若是数据令牌指纹和服务端当前的数据一致，则标识资源未发生新的变化。就会返回一个 304 的状态码，表示能够继续使用客户端本地缓存的数据，并刷新超时时间。注意当响应码为 304 的时候，它是不包含数据内容的。

一般此缓存操做对咱们都是透明的，它是浏览器和开源网络库的基本实现，咱们无需本身去判断 max-age 和 ETag 的值，这一步咱们只须要肯定服务端对此有支持便可。

这里只是提到了 If-None-Match，它标识比较 ETag 是否不一致，除此以外，还有一些其余的相关报文头，例如 If-Match，有兴趣能够查阅相关资料。

2.5 Cache-Control

前面举的例子中，咱们只为 Cache-Control 设定了一个 max-age，可是其实还有一些更丰富的配置。

从缓存性能最优化的角度来看，最佳的缓存是无需与服务端通讯的缓存，能够经过缓存来消灭网络延迟以及数据请求，从而来提升用户的体验。

Cache-Control 是在 HTTP/1.1 中被定义的，它能够用于取代以前的缓存策略，如今全部的浏览器都支持 Cache-Control ，它已经成为一种通用的标准。

Cache-Control 还有一些更灵活的配置，用来对缓存作一些更细致的操做。

1. “no-cache” 和 “no-store”

这两个参数都表示每一次请求，都须要真实的发送一个网络请求。

它们之间的区别在于，“no-cache”并非真的不缓存数据，它只是要求每次都确认资源是否过时，也就是它会利用数据令牌 ETag 来必定程度的减少传输的流量。

而 “no-store” 彻底是要求客户端，每次都从新请求数据并下载最新的数据，不作任何缓存处理。这种不缓存的策略，也包括中间链接的代理、网关 等中间传输的通道，也一并不对数据进行缓存，每次都从源服务器上获取数据。

2. “public” 和 “private”

“public” 是一种默认的策略，表示当前缓存是开放的，任何请求响应的中间环节，均可以对其进行缓存，若是咱们不显式指定，则当前为 “public” 缓存。

与之相对的 “private”，则表示当前响应是针对单个用户的，并不是通用数据，所以不建议任何中间缓存对其进行缓存。例如：浏览器就是一个比较私人的缓存源，它会缓存 “private” 的缓存，而 CDN 则不会。

3、最佳的缓存策略树

前面提到，缓存的核心目的就是为了快，能让下次使用的时候快速复用。因此在理想状况下，咱们应该将响应数据尽量多的缓存，尽量的缓存足够长的时间，而且为每一个资源提供单独的数据验证令牌，以便在时间过时以后快速校验。

可是任何事情都是要取其平衡点的，不存在什么最佳缓存策略，并不是全部响应资源都须要加缓存，这就须要根据业务场景来设定。

这里给出一个增长 HTTP 缓存的通用策略树，你在对响应增长缓存的时候，能够参考它来执行。

正常状况下，咱们针对不一样的响应属性，会对它设置不一样的缓存策略，下面根据场景，举几个例子。

3.1 用户相关的数据

和单个用户紧密相关的数据，一般咱们是不建议使用缓存的，可是依然存在几个等级。

1. 严格不使用缓存

Cache-Control:no-store

2. 容许客户终端缓存，可是每次使用都须要确认

Cache-Control:no-cache
ETag:"cxmyDev1234"

3. 容许客户终端短期缓存

Cache-Control:private max-age=600
ETag:"cxmyDev1234"

3.2 通用数据

一些通用响应资源，更新的频率很是的低，咱们能够根据须要调整 max-age 的大小便可。

Cache-Control:max-age=86400
ETag:"cxmyDev1234"

4、废弃和更新缓存的响应

缓存的策略，一旦肯定并下发到客户端，服务端就失去了对齐的控制权。也就是说，若是咱们设定了 max-age，在此资源有效期超时以前，哪怕服务端的源资源已经被替换修改，咱们也没有一个合适的时机去通知客户端更新新的响应数据。

那么有没有什么好的策略去标记资源废弃？同时又能友好的利用缓存策略。

在互联网上，全部服务上的资源，都有一个对应的 URL（统一资源定位符），它能够明确说明如何从一个精确且固定的位置获取资源。而 HTTP 缓存，也是依赖于 URL 的，注意 URL 是大小写敏感的，同一个 URL 表示同一个请求响应，依此来判断缓存和后续缓存的复用。

因此咱们是能够在 URL 上作文章的。

4.1 浏览器的废弃策略

前面提到，浏览器是自然支持 HTTP 缓存的，对于浏览器来讲，它所面对的就是一个个 HTML 页面，页面内会包含一些 CSS、Image、JavaScript、JSON 资源和数据。

针对不一样的资源和数据，咱们能够在其 URL 上，增长数据令牌指纹，当资源变更的时候，同时也去刷新改指纹令牌。

到这里就很好理解了：

• HTML 页面，使用 no-cache，强制每次都向源服务器确认数据。
• CSS文件一般变更的频率很是低，因此能够容许中间层缓存，而且缓存时间为一年不过时。
• JavaScript内有业务逻辑，能够设定为只容许客户终端缓存。
• getUserInfo，是为我的用户数据相关，这里推荐可缓存，可是须要每次向服务器从新确认。

4.2 App 接口的缓存策略

在 App 中使用的接口，其实和网页又不同，HTML 网页的结构相似一个树形结构，先经过获取 .html 文件获取其内全部资源的表，而后依次根据缓存策略进行访问。

可是在 App 中，和服务器的交互都是经过数据接口来实现的，就不存在最开始获取一个相似 HTML 文件这样的树形接口，每一个接口都是一个个“孤岛”，能够单独存在。咱们就没法提早知道某个接口的响应数据已通过期，同时也没法修改 URL 上携带的数据指纹令牌。

可是其实咱们是能够经过 App 和设备的一些固有信息，做为 URL 的参数传递，以此来刷新数据。

例如这里 /app/main 获取主页的数据，这里将当前 App 的版本号当参数拼接在 URL 的后面，以此方式来强制不一样的版本，刷新不一样的数据。避免刚升级上来的 App，还在使用旧版本的数据。

这个例子中，版本号只是其中一个维度，若是有必要，还能够传递其余维度的信息，例如当前网络状态，当前用户 id 等等。

5、小结

到这里咱们基本上把 HTTP 的缓存全部相关的内容都讲了一遍，这里简单总结一下。

• HTTP 缓存依赖 URL 作惟一标识，不一样的 URL 使用不一样的缓存。
• Cache-Control 能够控制缓存策略，共有或者私有、缓存超时时长等。
• 经过 ETag 来标记数据指纹令牌，以此来肯定响应数据是否更新。
• 应该为每一个响应资源提供对应的缓存策略。
• 若是须要废弃以前的缓存，能够利用修改请求 URL 的方式，将数据指纹令牌追加在 URL 以后，以此来更新数据。

关于 HTTP 缓存，你还有什么更好的想法，能够在留言区讨论。

参考资料：

• 《HTTP缓存》：http://t.cn/RL1NI8P
• 《基于缓存策略三要素分解法》

---

公众号后台回复成长『 成长』，将会获得我准备的学习资料，也能回复『 加群』，一块儿学习进步；你还能回复『 提问』，向我发起提问。

推荐阅读：

• 小程序 UI 布局指南（一）
• 程序员的密码管理之道
• 手动刷新 MediaStore，保存的图片当即出如今相册中
• 伪代码、幽默和 Google 的艺术！
• 漫画：App 防止 Fiddler 抓包小技巧！