expires cache-control

Expires/Cache-Contro

Expires/Cache协议与上述验证协议最大的不同在于，他可以省略发送验证请求环节，不需要服务器的验证，而直接使用本地缓存。 通常这种方式，适用于，项目稳定，版本迭代不多的时候。
Expires
在服务器端可以设置Expires的一个绝对时间。

//Response Headers
Expires:Tue, 03 May 2016 09:33:34 GMT

这告诉浏览器,在2016.5.3号之前,可以直接使用该文本的缓存副本。但是，可能会因为服务器和客户端的GMT时间不同，会有一定的bug。 所以，这里只提议在长时间缓存的情况下使用。否则，应该选择Cache-Control.
那在服务器端该怎么设置呢？ 这里以nginx为例:

location ~* \.(?:css|js)$ {
  expires 1d;
  access_log off;
  add_header Cache-Control "public";
}

通过expires设置过期时间为一天，此时，服务器会根据当前的时间，加上一天.同时添加Expires和Cache-Control头部标签。
即,得到的Response Header为:

Expires: Fri, 28 Feb 2014 10:42:09 GMT
Cache-Control: max-age=86400 //24*60*60

(HTTP规定，如果出现max-age和expires，则max-age默认覆盖掉expires)
当expires为负数表示no-cache，正数或零表示max-age=time。
如果你不想缓存，可以直接设置:

expires -1; //永远过期，Cache-Control: no-cache

详细可以直接参阅:nginx配置

Cache-Control
这应该是HTTP1.1为了解决HTTP1.0中expires的时间差的bug，而新添加的一个tag. 他的配置项很多，其实完全都可以取代expires(现在大多数服务器都支持). 引用一段原话:

Cache-Control 头在 HTTP/1.1 规范中定义，取代了之前用来定义响应缓存策略的头（例如 Expires）。当前的所有浏览器都支持 Cache-Control，因此，使用它就够了。
不过，目前大部分服务器都会将两者添加上，因为HTTP规定，如果Cache-Control和expires同时出现的话，expires会默认被覆盖掉。
此时，返回的响应码不再是304(文件未改动),而是200(资源成功访问).

当前每次发送请求之前浏览器会检查缓存系统里，是否有相应文件的备份，如果有的话，则直接从本地模仿一个Response头
理论知识铺垫完毕，我们来take a look. 看看cache-control 有哪些可以配置的属性(以下属性都跟在cache-control后)

public: 共有缓存，可被缓存代理服务器缓存,比如CDN
private: 私有缓存，不能被共有缓存代理服务器缓存，可被用户的代理缓存如浏览器。

max-age=[秒]：表示在这个时间范围内缓存是新鲜的无需更新。类似Expires时间，不过这个时间是相对的，而不是绝对的。也就是某次请求成功后多少秒内缓存是新鲜的。

s-maxage=[秒]：类似max-age, 除了仅应用于共享缓存（如代理）。

no-cache：这里不是不缓存的意思，只是每次在使用缓存之前都强制发送请求给源服务器进行验证，检查文件该没改变(其实这里和ETag/Last区别不大)

no-store：就是禁止缓存，不让浏览器保留缓存副本

must-revalidate：告诉浏览器，你这必须再次验证检查信息是否过期, 返回的代号就不是200而是304了。

proxy-revalidate：类似must-revalidate，除了只能应用于代理缓存。
比如，这里我可以设置Cache-Control为:

//Response Headers
Cache-Control:private, max-age=0, must-revalidate

该文件是一个私有文件,只能被浏览器缓存，而不能被代理缓存。max-age标识该缓存立即过期，其实和no-cache实际上区别不大. 然后must-revalidate告诉浏览器，你必须给我再验证文件过没过期，比如接下来可能会验证Last-Modified或者ETag.如果没有过期则使用本地缓存.