浅谈HTTP缓存

1、HTTP缓存概述（HTTP Cache）

要搞清楚HTTP缓存，首先固然是要搞清楚缓存是啥，按照MDN的描述，缓存是这样的：

缓存是一种保存资源副本并在下次请求时直接使用该副本的技术。当 web 缓存发现请求的资源已经被存储，它会拦截请求，返回该资源的拷贝，而不会去源服务器从新下载。这样带来的好处有：缓解服务器端压力，提高性能(获取资源的耗时更短了)。对于网站来讲，缓存是达到高性能的重要组成部分。缓存须要合理配置，由于并非全部资源都是永久不变的：重要的是对一个资源的缓存应截止到其下一次发生改变（即不能缓存过时的资源）。

上面已经将会缓存是什么描述的很清楚了，而HTTP缓存顾名思义，就是经过HTTP协议，来实现对资源缓存的目的。总的来讲，HTTP缓存主要经过两个HTTP头来实现的，其中Expires是由HTTP1.0提供的，而Cache-Control则是由HTTP1.1所提供的：

下面咱们就来对这两个头进行一个了解。

2、Expires

Expires是由HTTP1.0所提供的支持HTTP缓存的头部，由服务器返回，用GMT格式的字符串表示：

expires: Tue, 14 Aug 2018 14:32:49 GMT
复制代码

而读取缓存的条件则是：缓存过时时间（服务器的时间）< 当前时间（客户端的时间）

值得注意的是，咱们在expires所设置的时间是一个绝对的时间，并且所参照的是用户电脑上所设置的时间。这种绝对的时间很容易出问题，当用户本地的时间不许确，或用户进行跨时区的移动时，这个时间极可能就会过时，而没法发挥它本应该发挥的做用。

其次，在HTTP1.0里，没有提供相应的配置缓存的方法，只是提供了这个强缓存的头部而已，不足以知足项目对缓存多样化的需求。也正是出于以上两个缘由，在HTTP1.1中对HTTP缓存又进行了升级。

3、 Cache-Control

正是因为Expires存在着不少不足，因此HTTP1.1又为咱们提供了

Cache-Control主要可配置的参数有如下几个：

1. max-age 会指定从请求的时间开始，容许获取的响应被重用的最长时间（单位：秒）。例如，“max-age=60”表示可在接下来的 60 秒缓存和重用响应。
2. Public 表示响应可被任何缓存区缓存
3. Private 表示对于单个用户的整个或部分响应消息，不能被共享缓存处理。这些响应一般只为单个用户缓存，所以不容许任何中间缓存对其进行缓存。例如，用户的浏览器能够缓存包含用户私人信息的 HTML 网页，但 CDN 却不能缓存。
4. no-cache 表示必须先与服务器确认返回的响应是否发生了变化，而后才能使用该响应来知足后续对同一网址的请求。所以，若是存在合适的验证，no-cache 会发起往返通讯来验证缓存的响应，但若是资源未发生变化，则可避免下载。
5. no-store则要简单得多。它直接禁止浏览器以及全部中间缓存存储任何版本的返回响应，例如，包含我的隐私数据或银行业务数据的响应。每次用户请求该资产时，都会向服务器发送请求，并下载完整的响应。
6. min-fresh 表示客户端能够接收响应时间小于当前时间加上指定时间的响应。（用的很少）
7. max-stale 表示客户端能够接收超出超时期间的响应消息。若是指定max-stale消息的值，那么客户机能够接收超出超时期指定值以内的响应消息。（用的很少）

4、强缓存

上面已经将Catch-Control作了一个简单的介绍，而具体使用它们两者进行缓存操做的具体实现又分为强缓存与协商缓存。首先来聊一聊强缓存。

强缓存是利用Expires或者Cache-Control这两个http response header实现的，它们都用来表示资源在客户端缓存的有效期。在这个有效期内当浏览器对某个资源的请求命中了强缓存时，其返回的http状态为200，而且不会去对服务器进行请求，而是直接使用其本地的缓存。

具体实现以下：

expires: Tue, 21 Aug 2018 10:17:45 GMT
cache-control: max-age=691200
复制代码

只要存在以上两个头部信息的其中一个，咱们就能够对资源进行强缓存了。另外须要注意的是，当Catch-Control的优先级是要高于expires的。

总的来讲，强缓存是前端性能优化的一大助力。当咱们页面存在不少长期不变的静态资源时，都应该对其进行强缓存的处理，咱们一般能够为这些静态资源所有配置一个超时时间很长的Expires或Cache-Control。当用户在访问网页时，就只会在第一次加载时从服务器请求静态资源，在日后访问该页面时，就只要缓存没有失效而且用户没有强制刷新的条件下都会从本身的缓存中加载。这样既节省了资源加载的时间的消耗，又不会去访问服务器，能够有效地为服务器减压。

不过强缓存也存在一个很大的弊端，那就是对于动态资源它就有点力不从心了。由于若是咱们对动态资源进行了强缓存，那么极可能会在这动态资源更改后，浏览器仍是会直接去请求没有更改前的动态资源。也这是因为这方面的考虑，在强缓存外还存在着协商缓存的缓存方案。

5、协商缓存

当浏览器对某个资源的请求没有命中强缓存，就会发一个请求到服务器，验证协商缓存是否命中，若是协商缓存命中，请求响应返回的http状态为304而且会显示一个Not Modified的字符串； 若未命中请求，则将资源返回客户端，并更新本地缓存数据，并返回200的状态码。

除此以外，咱们也能够设置为协商缓存，以解决动态资源缓存与更新的问题，首先咱们来看一张关于协商缓存的图：

能够看到，在这个实现了协商缓存的Cache-Control中，设置了no-catch，当咱们设置为no-catch时，咱们就是能够直接去访问服务器，去查看该资源的更改状况，已肯定是是否须要使用缓存。而在校验的这一步咱们就须要使用如下几个头来帮助验证资源的更改状况了：

• Last-Modified：表示这个响应资源的最后修改时间。web服务器在响应请求时，会告诉浏览器该资源的最后修改时间，但它的最小单位是秒级，也就是若是咱们在1秒内屡次修改该资源，那么Last-Modified也没法发挥其应有的做用。
• If-Modified-Since：当资源过时时（强缓存失效），发现资源具备Last-Modified声明，则再次向web服务器请求时带上头 If-Modified-Since，表示请求时间。web服务器收到请求后发现有头If-Modified-Since 则与被请求资源的最后修改时间进行比对。若最后修改时间较新，说明资源又被改动过，则响应整片资源内容（写在响应消息包体内），HTTP 200；若最后修改时间较旧，说明资源无新修改，则响应HTTP 304 (无需包体，节省浏览)，告知浏览器继续使用所保存的cache。

也正是因为 Last-Modified存在着缺陷，咱们就须要ETag来帮助咱们来对资源的更改进行判断：

• Etag：当Web服务器响应请求时，会告诉浏览器当前资源在服务器的惟一标识（生成规则是由服务器决定的）。就好比在Apache中，ETag的值，其默认是对文件的索引节（INode），大小（Size）和最后修改时间（MTime）进行Hash后获得的。
• If-None-Match：当资源过时时，若是发现资源具备Etage声明，则再次向web服务器请求时带上头If-None-Match （Etag的值）。Web服务器收到请求后发现有头If-None-Match， 就会将其被请求的资源的相应校验字段进行对比，而后再决定返回200或304。

这就是强缓存与协商缓存的大部分状况了，具体的流程可见下图：

原图连接：user-gold-cdn.xitu.io/2018/8/16/1…

6、定义最佳 Cache-Control 策略

一般咱们能够按照上面这张流程图来对HTTP缓存进行相应的配置，详情能够看这篇文章：

developers.google.com/web/fundame…?

这位大佬对缓存的配置作了一个很好的阐述。

参考资料：

• developers.google.com/web/fundame…?
• www.cnblogs.com/lyzg/p/5125…
• developer.mozilla.org/zh-CN/docs/…