浏览器缓存

• memory cache是浏览器为了加快读取缓存的速度而作的优化

HTTP缓存控制

条件请求

• 没有 If 开头的 条件请求 头字段时

1. 用HEAD请求获取该资源的Last-modified 或 ETag
2. 获取到的Last-modified 或 ETag与缓存的资源对比
3. 若资源发生了变化，那么就发送一次GET请求获取新的资源
   否则直接用缓存

• HTTP定义了一系列的 If 开头的 条件请求 头字段，交由服务端来检验缓存是否过期

       客户端			      服务端
if-Modified-Since		Last-modified	        (弱检验器)	
if-None-Match			ETag			(强检验器)

• ETag 全称 Entity Tag，资源的唯一标识符，用于解决Last-modified（单位秒）无法准确区分文件变化的问题

  • 强ETag要求资源在字节级别相同
  • 弱ETag要求资源在语义上相同即可（值前面有个 W/ 标记）

• 图片来源

两端缓存控制

• 以前用Expires，缺点就是客户端这边可以修改本地时间，那就乱了呀，而现在Cache-Control: max-age=x，用相对响应报文创建的时间（Date头字段）

• 响应报文的头字段没有对缓存进行说明时，浏览器会采用一套 启发式算法来尽量缓存一段时间

  • 响应报文提供了Last-modified，但没有提供Cache-Control 或 Expires

  • 如果响应报文连Last-modified都没有呢，这个得看具体客户端是采用什么算法去缓存了

• 响应报文的头字段 Cache-Control: max-age=0时，浏览器会不会缓存该资源呢 ？

  • 会，浏览器收到数据就会将其缓存起来，而内部有一套算法去清除，而max-age是浏览器清除缓存的参照物

• 返回304和200的区别在于304不会携带实体数据，只是告诉浏览器Not Modified，让它去用缓存

应用

模式1: 不常变化的资源

• 设置很长时间的强制缓存（时效性不强）

Cache-Control: max-age=31536000

模式2: 经常变化的资源

• 设置使用前需要验证的强制缓存（时效性很强）

Cache-Control: no-cache
ETag: xxx
Last-modified: xxxx

模式1和2结合

• 时效性不算太强，也不算太弱，来取个中

no-cache <=> max-age=0,must-revalidate
# 取中间
Cache-Control: max-age=600,must-revalidate

• 很容易导致不同版本的资源组合在一起，导致报错

假设有三种资源：  index.html  index.js  index.css 存入浏览器缓存
	1. index.html的缓存有效时间先到期，被浏览器清除，而index.js index.css的缓存仍存在。
	2. 而此时浏览器请求到的新版本的index.html和旧版本的index.js和index.css组合很容易会报错

困惑

• 浏览器什么情况下会存储到memory cache ？

参考

• calendar.perfplanet.com/2016/a-tale…
• 极客时间：透析HTTP协议
• zhuanlan.zhihu.com/p/44789005
• jakearchibald.com/2016/cachin…