引发这个问题是今天测试前段图片服务器发现已经做了缓存还时不时200或304 经过检查原来是etag发生了变化，后端图片服务器上的文件生成时间不一致导致。改变nginx按ip分配即可。
这里简单说下：200是正常访问后的状态，200 OK (from cache) 是浏览器没有跟服务器确认，直接用了浏览器缓存；而 304 Not Modified 是浏览器和服务器多了一次缓存确认有效性，再用的缓存。
服务器返回如下几个缓存控制头部：
- Last-Modified：表示文档的最后修改时间，当去服务器验证时会拿这个时间去；
- Expires：http/1.0规范定义，表示文档在浏览器中的过期时间，当缓存的内容超过这个时间则需要重新去服务器获取最新的内容；
- Cache-Control：http/1.1规范定义，表示浏览器缓存控制，max-age=3153600表示文档可以在浏览器中缓存一年。
- ETag：发送到服务端进行内容变更验证的，而Catch-Control是用于控制缓存时间的（浏览器、代理层等）。nginx在生成etag时使用的算法是Last-Modified + Content-Length计算的。
总结：
- Last-Modified/Modified-Since 用于验证文档内容是否变更
- max-age/Expires 定义文档缓存时间，如在有效期内会返回 200（from cache）
这里以nginx为例
location ~ .*\.(gif|jpg|jpeg|png|bmp|swf)$ {
#etag off;
#proxy_http_version 1.1;
expires 1d;
}
- 200 from cache 的首要触发条件是图片需要嵌入在html页面中，同时不是刷新页面（而是直接在页面中跳转 或者 浏览器重新键入页面地址），如果使用 ctrl(cmd)+R 或者 F5 进行强制刷新，那么无论是什么网站，那么图片的请求都会是 304，如果是 ctrl(cmd)+shift+R 那么都会是 200 的重新请求；
- 所以只要在页面中跳转，或者在地址栏重新键入地址，那么大量的资源请求，都会被浏览器主动拦截，请求状态码为 200 from cache，其中 200 from cache 和之前的 304 请求的请求头部信息并没有实质的改变；
- 当使用 F5 等方式刷新后，taobao仍然有部分的图片可以是 200 from cache，这部分图片的请求的 initiator 基本是 js 或者 css，并不是直接嵌入在html页面中，而是通过 js 或者 css 进行加载，具体加载方式由于 taobao中该部分图片的引用方式被隐藏，所以并不好确定他们的优化方式；
