聊一聊HTTP缓存

前言

• 什么是HTTP缓存？

• 为何须要HTTP缓存，由于使用HTTP缓存能够减小请求响应时间和避免网络时延带来的等待时间。

• 如何合理使用缓存，设置不一样文件的缓存时间？

缓存的种类

缓存分为两种，Private cache和Shared cache

• Private cache是针对单个用户而言，一个例子就是本身的浏览器缓存，使用这些缓存实现了浏览器的前进/后退，而无需再次请求资源

• Shared Cache针对多个用户，好比代理服务器，一个ISP (Internet Service Provider)或者公司都有代理服务器，用来缓存一些资源，供全部员工访问，而没必要再向互联网发出请求，避免网络延迟

缓存控制

要清楚缓存控制，这里要先分清两个概念，一个叫作缓存存储（Cache Storage），一个叫作缓存（Caching）

其实在中文里面，可能直接都说成缓存，可是这样不助于理解下面缓存控制的前两种状况。其实缓存存储是一个实实在在的东西，而缓存只是它的一个动做

后来我又发现国人有强缓存和协商缓存的说法，强缓存就是指Cache Storage会直接返回Cache的内容，协商缓存是指Cache Storage向原始服务器进行验证，若是原始服务器返回304 Not Modified，Cache Storage才返回Cache的内容

淘宝网首页, Chrome Dev Tools下观察到的协商缓存(304)和强缓存 (from xxx cache)

强缓存和协商缓存验证资源是否过时

上面一幅图中，304 Not Modified表示使用了协商缓存，而from memory cache和from disk cache则直接使用强缓存

Chrome在某个版本以后将之前的from cache变成了from disk cache和from memory cache，就跟名字同样，缓存在磁盘中的内容即便在关闭了当前tab以后还能使用，可是缓存到内存的内容，当关闭tab或者浏览器，或者浏览器崩溃后，就消失了。可是memory cache加载速度更快，从上图也能看出

关于强缓存和协商缓存，我没发现这两个词的英文出处，可是这两个词理解起来更形象，因此下面的缓存控制状况我也会用到这两个词

1. 不使用缓存存储

能够理解为每次的请求都不通过Cache Storage，直接发给服务器，返回新的对象

Cache-Control: no-store
Cache-Control: no-cache, no-store, must-revalidate
复制代码

2. 不直接使用缓存内容

Cache Storage会缓存内容，可是每次须要向服务器验证资源是否过时，没过时才能使用缓存，这就是304 Not Modified的状况，也就是咱们所说的协商缓存

Cache-Control: no-cache
复制代码

3. 公共缓存和私有缓存

例如告诉资源只能被Private Browser Cache缓存起来仍是同时也能被Public Proxy Server缓存起来

Cache-Control: private
Cache-Control: public
复制代码

4. 强缓存过时控制

Cache-Control优先级高于Expired，前者是相对时间，后者是绝对时间；前者为General Header的字段，后者为Response Header的字段

Cache-Control: max-age=31536000 
Expires: Wed, 21 Oct 2015 07:28:00 GMT
复制代码

5. 资源验证

Cache-Control: must-revalidate
复制代码

缓存验证

缓存验证发生在用户刷新，或者响应头中包含Cache-Control: must-revalidate的状况

缓存验证有两种形式，均可以用来验证文档是否过时

• 文档的最后修改日期，响应头Last-Modified字段，请求头If-Modified-Since字段请求验证
• 对文档当前版本的惟一标识，叫作entity tag，响应头ETag字段，一般使用MD5 Hash实现，请求头If-None-Match字段请求验证

同时，缓存验证有两种验证类型

• 强验证（strong validator），文档对比一个字节一个字节地进行，严格对比
• 弱验证（weak validator），文档只有语义不一样才认为是改变，例如一个HTML文档也许只是里面的广告发生改变，或者是页脚的日期发生改变，弱验证会认为它们仍是相同的

HTTP默认使用的是强验证

须要注意的是，通常状况下，Last-Modified字段只能做为弱验证，由于它的最小单位是秒，一秒内文档可能改变2次，没法作到标识每一次改变，若是使用它作强验证，则须要明确知道不会发生这种状况。固然，还有一些其余的限制，具体的限制能够看我下面的第4条RFC文档参考，这里就不细说了

而ETag默认做为强验证，若是须要用它实现弱验证比较困难，由于须要判断文档中不一样元素的语义，确保语义变化时ETag的值才发生变化，而不是每次检测到字节变化时就生成一个新的值

缓存验证这部分建议有能力的同窗直接查看第4条RFC参考

条件缓存（响应头增长Vary字段）

该字段指出了筛选条件，若是下一次到达Cache Storage的请求中的该条件与缓存时的该条件的值不同，则从新向真实server发请求，不然使用缓存，看下面这幅图

在响应头使用Vary字段条件验证Content-Encoding

Vary字段一般会对User-Agent进行验证，避免将移动端缓存的文档直接发给桌面端请求的用户，反之亦然

Vary: User-Agent
复制代码

参考

1. developer.mozilla.org/en-US/docs/…
2. stackoverflow.com/questions/4…
3. developer.mozilla.org/en-US/docs/…
4. Weak and Strong Validators