看Volley源码，对HTTP缓存机制分析

Volley是android官方实现的HTTP请求库，实现非常优美，这里暂不分析。这是在网络请求时它有一个对response code == 304 的判断，这个让我很纳闷，度娘加谷哥很久发现，原来这是HTTP协议支持的缓存策略，主要服务器的协作才能达到缓存的目的，下面分析下 如何达成：

首先要明白的是更新操作主要是为了保证缓存中的内容与远端server中的内容保持一致，HTTP协议规范中规定了两种途径：定义文档过期日期以及执行重验证。

针对文档过期时间，HTTP协议中规定了两种方式：第一种是在远端server为所回复的每个文档附上”Expires:”HTTP头部；另外一种是为所回复的每个文档附上缓存控制头部”Cache-Control: max-age= ”.值得注意的是，“Cache-Control: max-age=”头部是在HTTP/1.1中规定的，而“Expires”则是在HTTP/1.0规定的，另外在RFC2616中规定，客户端在处理二者时，“Cache-Control:max-age=”头部具有更高的优先级。当规定的时间过期时，并不代表文档中的内容一定是过时的，它只是提醒缓存需要与远端的server做一致性检查——“重验证”。

前面说过，当超过文档过期时间之后，客户端就必须做一致性检查，也就是本节将要阐述的“重验证”。很明显，重验证的目的就是去与远端server交互去判断缓存中的文档是否已经改变（或者说是否过时），若重验证之后表明文档做了修改，此时就需要重新从远端server下载一份最新的文档，去代替缓存内容；若文档没有做修改，则只需获取从server端获取新的HTTP头部(可能包含新的过期时间)，并更新缓存中的头部。

面主要阐述HTTP规范中所定义的几种常见重验证方法。其中具有代表性的是“If-Modified-Since”以及“If-None-Match”两种头部

(1)  If-Modified-Since
      若server回复的报头中存在“Last-Modified”，那么客户端一定要在下一次请求报头中包含“If-Modified-Since”，所以说，这两个头部是相互对应的。那么当服务器收到客户端回复的“If-Modified-Since”头部之后会如何处理呢？首先服务器通过比较这两个时间，若“Last-Modified”更大，表明客户端缓存中的内容已经过时，此时server会将最新的文档（附上新的Header）返回给客户端，并且状态码为200；否则认为客户端缓存中的内容仍然是最新的，只需向客户端返回304状态码，同时包含最新的HTTP头部。下图比较形象地显示了这两种处理情况。

 
(2) If-None-Match
      可以明显看出，“If-Modified-Since”实现重验证主要是通过比较时间来完成的，但是在某些情况下，它并不能十分凑效：
      ☉服务器上的文档被后台进程周期性地重写，此时虽然日期发生了变化，但是内容却没有发生任何改变；
      ☉虽然服务器上的内容发生了改变，但是却只是一些不太重要的信息，比如说拼写错误等等，这样就导致文     档在客户端重载，显然开销过大；
      ☉一些web服务器上很难精确计算出文档的修改日期；
      ☉对于实时系统而言（文档修改在很短的时间内完成），显然也显得无能为力。
      基于以上几点，HTTP规范定义了另外一种方式，即比较文档标签(Entity tags, Etags).它的基本思想是为每一个文档生成一个Etag，它可以是某个序列号、版本号或者检验。同样“If-None-Match”头部是与server端的“Etag”头部是相对应的，这样server端只需要比较标签号就可以判断出客户端缓存中的文档是否是最新的，其处理方式与“If-Modified-Since”类似，下图是服务器与客户端的一种交互情况：