1、概论
1.1、 什么是缓存？
Web缓存是可以自动保存常见文档副本的HTTP设备。当Web请求抵达缓存时，如果本地有“已缓存的”副本，就可以从本地存储设备而不是原始服务器中提取这个文档。因此，可以这样理解，缓存拦截了客户端的请求，代替服务器端做出响应。
1.2、缓存的作用
使用缓存主要有如下几个有点：
- 缓存减少了冗余的数据传输，节省了你的网络费用。
- 缓存缓解了网络瓶颈问题。不需要更多的带宽就能够更快的加载页面。
- 缓存降低了对原始服务器的要求。服务器可以更快地响应，避免过载的出现。
- 缓存降低了距离时延，因为从较远的地方加载页面会更慢一些。
1.3、缓存分类
缓存主要分为两类：
- 私有缓存：缓存存储在客户端的存储器里面。
- 公有代理缓存：又称为缓存代理服务器或者代理缓存。它较私有缓存的优点是，避免了每个客户端都需要去服务器获取数据，从而节省一定的流量。
二者之间的对比如下图所示：
私有缓存和共享缓存.png
2、缓存的处理步骤
一个缓存从接收到请求到做出响应，大概可以分为如下7个步骤：
（1）接收——缓存从网络中读取抵达的请求报文。
（2）解析——缓存对报文进行解析，提取出URL和各种首部。
（3）查询——缓存查看是否有本地副本可用，如果没有，就获取一份副本（并将其保存在本地）。
（4）新鲜度检测——缓存查看已缓存副本是否足够新鲜，如果不是，就询问服务器是否有任何更新。
（5）创建响应——缓存会用新的首部和已缓存的主体来构建一条响应报文。
（6）发送——缓存通过网络将响应发回给客户端。
（7）日志——缓存可选地创建一个日志文件条目来描述这个事务。
下图描述了缓存中有新鲜缓存时，缓存的处理过程。由此可以看出，这整个过程已经与服务器没有关系了：
处理一个新鲜的缓存命中.png
2.1、缓存处理流程图
下图以简化的形式显示了缓存是如何处理请求以获取一个方法为GET的URL的。
缓存GET请求的流程图.png
3、判断是否新鲜
从上一节的流程图可以看出，有两个工作在缓存的过程中是非常重要的。一个是如何判断该缓存还是新鲜的？另一个是验证缓存副本是否与服务器原本一致？这两个工作都是由HTTP报文相关的首部字段决定的。这一节我们先考虑第一个问题，下一节再探讨第二个问题。
3.1、Expires
服务器使用Expires首部来指定过期日期。比如说，如果服务器发送一个响应报文，其中首部有如下字段：
Expires: Mon, 30 Oct 2017, 12:00:00 GMT
这也就说明，该报文会在2017年10月30日的12点整过期。在此后到来的响应请求，缓存就会判断其中的副本不新鲜，需要与服务器进行再验证。
3.2、Cache-Control: max-age
使用Expires来判断是否新鲜虽然可行，但也有一定的问题。那就是它所依赖的是缓存本地的时间，假设我所用的缓存是私人缓存，我将自己电脑的时间调到2200年，那么，该副本将在我的有生之年都不会过期。待我老时，浏览的还是几十年前的页面。
实际上Expires是HTTP 1.0协议引入的。在HTTP 1.1协议中引入了Cache-Control: max-age头部，解决了Expires所遇到的难题。Expires使用的是绝对时间，而max-age使用的则是相对时间。当服务器生产一个响应或者再验证成功时，它会在报文中存储此刻的时间，max-age中的时间就是相对该时间的。比如，如果响应报文是此刻生产的，那么下面的语句就是说该缓存会在60秒后过期，如果你60秒后再来访问该URL，那么就需要与服务器进行再验证：
Cache-Control: max-age=60
3.3、请求报文如何控制新鲜度
上面的内容都是针对服务器的响应报文的。那么，请求报文有没有办法控制新鲜度呢？或者可以先问这样一个问题，客户端是否有必要插手管理缓存的新鲜度呢？
答案是肯定，比如服务器端使用了Expires字段，而我一不小心将时间设置成了2200年。一天又一天，无论我怎么请求，该页面亘古不变。我依然没想到是时间设置的错误（我可真笨）。然而，有一天，我不再只是在浏览器输入网址然后敲回车键，而是按F5刷新，页面终于奇迹的刷新了。
请求报文中与缓存新鲜度有关的也在名为Cache-Control的首部字段中。大概有如下几种：
3.3.1 max-age
和响应报文中的max-age类似，该值也是一个相对时间。如果当前时间减去缓存中存储的响应报文的创建时间超过max-age的值的话，那么缓存就得去和服务器再验证了。
3.3.2 max-stale
stale的意思是不新鲜，max-stale的意思就是说，在多大的范围内，客户端还是愿意接受缓存中保存的不新鲜的副本的。也即是说，如果当前时间超过了max-age的范围，但却没有超过max-stale值得范围，那么缓存副本还是可以代替服务器做出响应的。
3.3.3、min-fresh
该字段的意思是说，客户端不希望缓存中副本的新鲜生命周期不低于其创建时间再加上min-fresh指定的时间。如果超过了，那就从服务器获取。
4、再验证
第二个工作就是，缓存是如何与服务器进行交互并再验证的呢？HTTP协议提供了两种主要的方式：If-Modified-Since：Date和If-None-Match：Etag。它们又被称为条件验证。这两个标签的原理类似，只是有一点点细微的差别而已。
整个再验证的过程和客户端没有任何关系，仅涉缓存和服务器双方。
- 对于If-Modified-Since：Date的方式，缓存会根据缓存副本的创建时间来创建If-Modified-Since的值，这个值可以和服务器的响应首部Last-Modified相配合使用，以此判断内容是否被修改了。
- 如果使用的是If-None-Match：Etag方式，那么服务器会为该文档提供一个特殊的标签（Etag），当缓存去和服务器沟通时，发现服务器原本的Etag和缓存副本不同，也就认为服务器中的资源被修改了。
如果再验证发现缓存副本没有更改，那么服务器会回送给客户端304 Not Modified响应。客户端自动重定向到缓存拉取副本，同时缓存更新相关首部。如Age、max-age、Etag等。
如果再验证发现缓存副本已改变，那么服务器就会将携带新首部的新文档发送给缓存，缓存进行存取后并对首部进行改装后再以200 OK对客户端做出响应。
如果再验证发现服务器中已没有此资源时，服务器直接向客户端返回404 Not Found响应。
注：如果报文中即有If-Modified-Since验证，又有If-None-Match验证，那么只有当两个条件都满足的情况下才会返回304 Not Modified*响应。
5、缓存控制
到这里为止，缓存的处理流程基本上已经理清了。然而，HTTP协议的能力不仅如此，它还为我们开发人员提供了强大的控制缓存的机制，我们可以通过相关首部控制是否使用缓存，是否一定要再验证等，这也是由名为Cache-Control的首部字段提供的：
5.1、no-Store
如果请求报文或响应报文中含有no-Store时，它会禁止缓存对响应进行复制。
5.2、no-Cache
如果请求报文和响应报文中含有no-Cache时，也就是强制了缓存需要与服务器端进行在验证。
5.3、must-revalidate
这是响应报文专用的。
上面说过，请求报文中可以包含Cache-Control：max-stale标签，它允许缓存提供一定期限的超过了新鲜生命周期的信息。而如果响应报文使用了must-revalidate，那就意味着，缓存将严格遵守过期信息，只要超过了新鲜生命周期，就需要和服务器进行再验证。
5.4、only-if-cached
这是请求报文专用的。
如果请求报文中有此标签。那就意味着，客户端只希望从缓存中读取资源。如果缓存中不存在，缓存会返回504 Gateway Timeout响应。
5.5、控制私有和公有
- 如果响应报文中含有Cache-Control:public字段，那就意味着，服务器只希望代理缓存对其进行复制。
- 反之，如果响应报文中含有Cache-Control:private字段，那就意味着，服务器只希望私有缓存对其进行复制。
5.6 补充：Pragma
由于Control-Cache是HTTP 1.1协议指定的，因此，为了兼容1.0版本，客户端可以发送包含Pragma：no-Cache首部字段的请求报文。如果其中有Control-Cache：no-Cache并且该字段能够被理解，那么Pragma中定义的就会被忽略。
6、一种缓存策略决策树
作为Web服务器端的开发者，可以参考google提供如下决策树：
image.png
7、总结
缓存机制是HTTP协议中相对较难的一块，也是非常重要的一块，因此，很难说这篇文章没有任何错误，如有错误还请指正批评，谢谢！
代理服务器简分类:(并不太全，仅当科普, 了解代理在web中的重要作用是有必要的.这里仅仅是简单介绍下.)
缓存角度分类:
(1) 缓存代理 : 根据某种约定,缓存曾经请求过的数据
(2) 常规代理 : 只转发请求的那一种.并不缓存数据的代理
控制方分类：
(1) 反向代理：(对于原始服务器来说,反向代理即是一个客户端)
a) 服务提供者主观使用,并控制.
b) 相对其他客户端来说,离原始服务器最近(主观上)
c) 转发请求,缓存,用于负载均衡.
d) 屏蔽其他客户端与原始服务器的直接联,避免原始服务器被直接攻击
e) CDN的应用(严格来说,CDN已经并非纯粹意义上的反向代理了.)
(2) 非反向代理: (非服务提供者所控制)
其他分类:
(1) 用户代理
a) 浏览器
b) 各类终端机
c) 搜索引擎爬虫.
(2) 透明代理
(3) 拦截代理
(4) http代理
(5) socket代理(UDP,FTP…etc)
缓存相关的约定,HTTP协议、相关概念
HTTP1.1协议:
继承自http1.0，在其基础上扩展或修改而产生. 比如1.0中Date标头,允许使用的RFC1036日期格式,的千年虫问题的修正.悲剧的是,有些明显的错误,无法矫正,比如一个著名的拼写错误. Referer 标头的拼写错误.一直沿用至今.因其,已经被广泛应用.在实际使用上，又无伤大雅,所以也就被继续将错就错了.
实体: 用于表示一个,请求或响应的消息中的一个资源,如post提交的表单内容,或请求服务器上的abc.jpg时,abc.jpg就代表一个实体.对于一个实体响应来说，除去响应标头外所剩余的部分,即是实体主体部分,比如abc.jpg的真实2进制数据.
标头(头域):
(1) 请求标头 : 在一个请求中使用的相关标头,用于添加附加信息,或对被请求服务器增加限制.
(2) 响应标头 : 用于添加相关响应的附加信息.
(3) 实体标头 : 提供实体相关的附加信息,如果修改时间,实体的大小等等.
(4) 常规标头 : (通用标头)在请求和响应中都可以使用的一些常规标头,如HTTP1.0所定义的Date.和 Pragma(是的,这并不是一个实体标头,它仅仅是试图与客户端,包括代理,进行协商,不要使用缓存的副本.).
补充:HTTP1.1的常规标头:
Date,Pragma,Cache-Control,Connection,Transfer-Encoding,Upgrade,Trailer,Via,Warning
缓存相关标头:
. Expires (实体标头,HTTP 1.0+)
一个GMT时间,试图告知客户端,在此日期内,可以信任并使用对应缓存中的副本,缺点是,一但客户端日期不准确.则可能导致失效.
.Pragma : no-cache(常规标头,http1.0+)
对Pragma定义的唯一的伪指令,同http1.1的Cache-Control : no-cache
.Last-Modified(实体标头,HTTP1.0+)
一个GMT时间,告知,被请求实体的最后修改时间.用于客户端校验其缓存副本是否仍然可以信任.与其相关的两个条件请求标头：
（1） If-Modified-Since：（此标头,仅对Get方法有意义）
如果实体在指定时间后,没有修改则返回一个304,否则返回一个常规的Get请求的响应(比如200). 另外,如果该标头的值是一个非法的值,那么也同样返回一个常规的Get请求的响应.
PS:用户代理发起 If-Modified-Since尝试握手的条件，可能会有不同,比如IE系,如果该实体第一次响应头中包含Cache-Control:no-cache.则 IE不会使用If-Modified-Since请求资源.而其他浏览器则会. 但是如果使用Cache-Control:no-store.则所有用户代理的表现一致.都不使用If-Modified-Since(因为no-store的语义十分强烈.不允许任何缓存,这个在后续有专门介绍.)
（2） If-Unmodified-Since:
如果实体在指定时间后,没有任何修改,那么就可以直接执行该请求使用方法的对应行为. 而如果有修改,则返回一个412 Precondition Failed状态码,并且抛弃该方法对应的行为操作(GET方法除外).
. Cache-Control : (常规标头,HTTP1.1)
| .public:(仅为响应标头) 响应:告知任何途径的缓存者,可以无条件的缓存该响应.
响应:告知缓存者(据我所知,是指用户代理，常见浏览器的本地缓存.用户也是指,系统用户.但也许,不应排除,某些网关,可以识别每个终端用户的情况),只针对单个用户缓存响应. 且可以具体指定某个字段.如private –“username”,则响应头中，名为username的标头内容，不会被共享缓存.
请求: 告知缓存者，必须原原本本的转发原始请求,并告知任何缓存者,别直接拿你缓存的副本,糊弄人.你需要去转发我的请求,并验证你的缓存(如果有的话).对应名词:端对端重载. 响应: 允许缓存者缓存副本.那么其实际价值是,总是强制缓存者,校验缓存的新鲜度.一旦确认新鲜,则可以使用缓存副本作为响应. no-cache,还可以指定某个包含字段,比如一个典型应用,no-cache=Set-Cookie. 这样做的结果,就是告知缓存者,对于Set-Cookie字段,你不要使用缓存内容.而是使用新滴.其他内容则可以使用缓存.
请求:告知,请求和响应都禁止被缓存.(也许是出于隐私考虑) 响应:同上.
请求:强制响应缓存者，根据该值,校验新鲜性.即与自身的Age值,与请求时间做比较.如果超出max-age值,则强制去服务器端验证.以确保返回一个新鲜的响应.其功能本质上与传统的Expires类似,但区别在于Expires是根据某个特定日期值做比较.一但缓存者自身的时间不准确.则结果可能就是错误的.而max-age,显然无此问题. Max-age的优先级也是高于Expires的.
响应:同上类似,只不过发出方不一样.
请求:意思是,我允许缓存者，发送一个,过期不超过指定秒数的,陈旧的缓存. 响应:同上. .must-revalidate(仅为响应标头) 响应:意思是,如果缓存过了新鲜期，则必须重新验证.而不是试图返回一个不在新鲜期的缓存.与no-cache的区别在于,no-cache,完全无视新鲜期的概念.总是强制重新验证.理论上,must-revalidate更节省流量,但相比no-cache,可能并不总是那么精准.因为即使缓存者，认为是新鲜的,也不能保证服务器端没有做过更新.如果缓存者是一个缓存代理服务器,如果其试图重新验证时，无法连接上原始服务器,则也不允许返回一个不新鲜的,缓存中的副本.而是必须返回一个504 Gateway timeout. .proxy-revalidate(仅为响应标头) 响应:限制上与must-revalidate类似.区别在于受体的范围.proxy-revalidate,是要排除掉用户代理的缓存的.即，其规则并不应用于用户代理的本地缓存上. .min-fresh(仅为请求标头) 请求:告知缓存者,如果当前时间加上min-fresh的值,超了该缓存的过期时间.则要给我一个新的.其实个人觉得,其功能上有点和max-age类似.但是更大的是语义上的区别. .only-if-cached:(仅为请求标头) 请求:告知缓存者,我希望内容来自缓存，我并不关心被缓存响应,是否是新鲜的. .s-maxage(仅为响应标头) 响应:与max-age的唯一区别是,s-maxage仅仅应用于共享缓存.而不引用于用户代理的本地缓存,等针对单用户的缓存. 另外,s-maxage的优先级要高于max-age. .cache-extension (cache-extension是一个泛化的代称.它指所有自定义，或者说扩展的,指令,客户端和服务器端都可以自定义扩展Cache-Control相关的指令.) 那么,实际上我们可以这样 Cache-Control:max-age=300, custom-directive = xxx, public. 这样我们就定义了一个被统称为cache-extension的扩展指令.该指令如果对应的客户端或服务器端，不认识,就会忽略掉. 扩展指令 中一个常见的东西是 none-check post-check 和 pre-check. 这玩意是IE5被加入的. 所以如果响应头中有这几个扩展指令,那么IE就会认得他们, 我经常在一些 为了解决 no-cache + gzip 命中ie6 JSONP 请求,导致脚本不执行bug的方案中见到这几个扩展指令，其目的是为了让IE放弃使用本地缓存. 我倒是觉得,对IE6放弃使用gzip,是更合理的做法. 当然缺点也很明显, 如果是cdn部署静态资源.显然这样做会很困难.
bug描述: IE6,某些情况下,开启gzip的资源,会不渲染或不执行(如果是.js的话.) 会引发此bug的条件: 1. 首先,必须由a页面脚本导致跳转到b页面 : 即 a页面有 location.href = b页面.(点链接,form post,replace, assign等方式都会导致问题,包括target=_blank弹窗的情况) 2. b页面自身,或其使用动态创建脚本(硬编码script src=xxx 也会有此问题) 的响应头中包含下面情况: cache-control 包含下列伪指令: (1) no-store (2) no-cache + 其他与缓存新鲜度检验有关头共存时, 如 max-age=xxx (xxx无所谓.0 或3000都会触发,) 或 no-cache + must-revalidate甚至是,no-cache, pre-check=0等情况.. (3) no-cache独立存在时,体现为一种不稳定情况.即当访问页面被cache时,可能会触发.但也不是100%.仅仅是偶尔...
遇到以上情况,页面可能会不渲染,而脚本可能会不执行. ps: 本bug ,与 http1.0 头域 : Pragma : no-cache ,无关.
解决办法: 1. 放弃压缩. 2. 放弃cache-control 中的 no-cache,no-store头域. 比如 单独使用max-age=0.并对不支持http1.0的老浏览器配合Expires = 一个过期时间. 关于这个bug的msdn的描述: To work around this problem, you can do either of the following:
显然,微软给了我们两条路,去掉no-cache头,或者使用Expires指定过期时间，强制使其过期代替no-cache, 或者别压缩. 而pre-check=0.显然可以代替Expires做到这件事.
关于这几个扩展指令的, 参考msdn 的描述:http://msdn.microsoft.com/en-us/library/ms533020%28VS.85%29.aspx#Use_Cache-Control_Extensions
一张图: 简单来说, 就是控制IE,如何使用本地缓存 ,如果缓存时间,超过post-check的值,就要保证下一次请求该资源,去要验证过的新鲜的.而pre-check则是超过了，就马上给个新的. no-check就无需解释了..
.no-transform 请求:告知代理,不要更改媒体类型,比如jpg,被你改成png. 响应:同上. |
.Etag :(实体标头，HTTP1.1)
通过[Mog95],( http://www.research.digital.com/wrl/publications/abstracts/95.4.html
遗憾的是，该地址，现在似乎访问不能.)生成一段可代表实体版本的字串.默认就是一段hash + 时间戳的形式.其实我们是可以使用自己的算法来生成Etag值.比如md5.
PS:Apache的默认Etag包含Inode,Mtime,Size三部分.而且Etag有强弱之分.比如一般的弱Etag,是以W/开头的,如:W/”abcde12”,这部分不是我们关注的焦点.因为弱Etag和强Etag的区别只在于算法.比如某种弱Etag关注的时间精度,为秒.而我们在项目中,最常见的做法是使用MD5.是一种忽略时间维度的,强Etag.为的是保证精确度.以及负载均衡设备的同步.除非我们的项目有特殊需求.但是往往我们可以根据需求,来调整算法.而不是沿用一些传统的弱Etag算法.
这东西,是要和客户端的两个请求标头配合使用的:
(1) If-Match:
语义:如果有匹配,或者值为”*”,才可以能去执行,请求所使用的方法,所对应的行为.
If-Match,可以看做是一个过滤器,主要应用于资源多版本共存的解决方案.比如服务器端对同一实体，有多个版本.那么客户端，即可按照指定版本来获取实体.
If-Match的值就是对应指定版本的Etag值.这个值可以是多选的.典型的应用场景是,客户端使用put方式请求服务器端,并带有多个If-Match的值.服务器端检查所有该实体的版本.找到匹配项,就立刻更新服务器端的对应版本.如果无一匹配,则发送一个412 Precondition Failed状态码.
(2) If-None-Match:
语义:如果有任何匹配,或值是”*”,并且原始服务器存在其请求的实体,则不允许执行该请求所使用放的对应行为,如果此时,该请求使用的get,或head方法.则返回一个304状态码.以及其他一些相关的缓存控制的标头.
与If-Match相反 .但它的典型应用,也是我们要关注的部分.支持http1.1的现代浏览器,以及web server,应用If-None-Match头用于,缓存新鲜度校验.典型应用场景就是,一但原始服务器的某个响应中包含Etag时,如果浏览器本地缓存了该实体.那么在第二次的常规的get或head请求时,就会自动带上 If-None-Match头.当原始服务器上该实体的版本对应的Etag值与之匹配时,则原始服务器会返回304状态码.然后浏览器认为本地缓存是新鲜的.则继续使用缓存的实体. 但,其实Etag的本意是版本管理.而并不是缓存有效性校验.这应该是一个衍生出来的使用方式. 而这种方式相比Last-Modified校验方式的好处是,如果我们消除时间戳部分,仅使用hash作为Etag值. 就可以方便做负载均衡同步.
.Age(响应标头,HTTP1.1)
Age标头,对于原始服务器来说,用于指明,当前资源被生成了多久,即存活期.而对于一个缓存代理服务器来说，它表示缓存副本,被缓存了多久.缓存代理服务器，必须生成Age头.其值以秒为单位.且可能为负值.
.Vary(响应标头,HTTP1.1)
Vary标头，用于列出一组响应标头,用于缓存者从其缓存副本中筛选合适的变体.举个例子来说,不同的请求方法,导致对同一资源的响应有区别.这就导致缓存者有多份缓存副本.那么Vary所列出的标头项,就是选择副本时的一个重要依据. 比如Vary:Accept-Language.那么如果新的请求中的Accept-Language标头的值,而原始请求(被缓存的那个)中并未包含与之匹配的Accept-Language的标头的话.那就必须放弃该副本.而是把请求转发到原始服务器.
另一个Vary的典型应用是,Vary:Accept-Encoding.这样做的意义在于,某些用户使用的浏览器,可能不支持一些特定的压缩算法.那么当这个用户途径的某个共享的缓存代理服务器,所缓存的使用了某种压缩算法的响应,就不能直接返回给该用户.如果服务器端,并没有配置这个标头,那就可能产生悲剧.即用户的浏览器无法解压缩返回的资源.导致各种异常状况的出现.
范围相关标头.以及缓存的意义.
请求标头:
.Range : 1000- | -1000 | 0 - Content-Length
Range头可以指定像服务器(并不一定总是原始服务器,比如一个缓存代理服务器)端获取范围内的数据,这种格式是很松散的,可以用”,”逗号分割范围的一种表达式.比如1-100,-1 这就表示要获取第一到100个字节,以及最后一个字节的部分.又或者 50-则表示50个字节之后的所有数据搭配可以很灵活.不过,当使用多个范围的Range标头时,假设范围都是合法的(不存在越界的情况,如果越界,则可能返回417 Requested Range Not Satisfiable状态码).则服务器响应时,会修改响应中的Content-Type标头为 如下格式:
Content-Type : multipart/byteranges;boundary=----ROPE----
----ROPE----
Content-Type:image/jpeg
Content-Range:bytes 0-100/2000
此处为0-100的数据
----ROPE----
Content-Type:image/jpeg
Content-Range:xxx-xxx/2000
xxx-xxx范围的数据.
----ROPE----
好吧,以上这些不是我们关心的重点.我们关心的是和缓存有关的情况,其实对于任何客户端(包括用户代理，以及各类缓存服务器)来说.如果它明确的知道自己想要某一部分范围的数据.就可以使用Range标头. 但事实上,比如对于浏览器来说,一般情况下,只有当服务器端的响应中包含Accept-Ranges:bytes标头时,才可能会在有断点续传需求的时候,自动使用Range头去请求实体.而代只有在响应中，明确出现Accept-Ranges:none时.才会完全避免客户端(包括缓存代理服务器),使用Range标头去获取部分数据.这是要区别看待的.
PS:Range头,还可以在GET方式下与If-Unmodified-Since标头配合,进行条件请求.其行为类似于If-Range头中使用日期格式做新鲜度校验.
.If-Range : 实体的Etag值 | date日期值.
配合Range使用的条件请求标头,该标头的值可以是被请求实体的Etag值，又或者是其Last-Modified的日期.客户端所缓存的部分数据,是新鲜的,服务器端才会,以206方式返回这部分数据.否则,以200方式返回全部数据.
响应标头:
.Accept-Ranges : bytes | none
用于说明,服务器是否支持范围请求.一般，我们常常为图片等资源设置Accept-Ranges:bytes标头.以便使客户端,可以使用断点续传功能.当然,这一切的前提是,客户端之前有缓存部分数据.或者换个角度说,如果服务器端明确声明,不允许缓存某个实体.那么断点续传也就无从说起了. 所以正确的服务器端配置.是一切的基础.
.Content-Range : bytes 0-xxxx/xxxx
标明当前服务器端返回数据的范围. /xxxx部分是总长度.
HTTP响应类别:
.信息类：1xx(信息类响应头,是在1.1中才被真正具体定义.我们暂时不关注它.)
.成功类：2xx
.重定向类：3xx （我们目前只关注304,是的,304是属于重定向类的,我们姑且理解为,重定向到客户端缓存副本上去.）
.客户机错误类：4xx
.服务器错误类：5xx
关于客户端缓存，我们应该关注哪些概念
1. 寿命:
即响应的寿命,指从原始服务器发出实体后所经历的时间,或者是重新验证,证明某缓存仍处于最新状态（可信赖）之后,所经历的时间. 参考响应头中的 Age,其单位是秒.
2. 过期时间:
对于一个缓存实体来说，其过期时间,是由原始服务器设定的.(参考响应头中的Expires,Cache-Control:max-age…等)一但发现过期,则缓存,必须重新验证实体，才能决定是否使用缓存中对应的实体副本,作为响应.如果原始服务器,未设定过期时间,则缓存可以自己做主,设置一个它认为合适的过期时间(就浏览器来说,IE浏览器再这里实现的与众不同,非IE的主流浏览器,不会自作主张的设置一个自认为合适的过期时间,或者说他们总是认为这样的实体.不应该被缓存下来.而IE，则会有一个会话级的缓存.实际上也不是真正有一个过期时间了.所谓会话级缓存,即浏览器不关闭的情况下,始终去读取浏览器本地的缓存.而不会去试图做任何验证的工作.)
3. 新鲜期和陈旧性:（此概念为服务器端概念）
一个HTTP响应是在服务器端某个特定时刻生成的.原始服务器决定这个响应在多长时间内,是确定新鲜的.在这个新鲜期内,相同实体的请求.可以使用原来生成的那个内容作为响应.即服务器端缓存.一但原始服务器端确认某相同实体的响应,已过了新鲜期.即处于陈旧状态.则原始服务器,需要进一步处理这个响应,比如重新生成响应，或者验证是否可以继续使用该响应.并重新设置其新鲜期.
4. 有效性:
缓存,可以与服务器联系,来验证某个缓存副本,是否是可信赖的最新状态.这种检查，被称为有效性重验证.重验证也可以针对代理服务器进行,而不一定总要和原始服务器进行验证.
5. 可缓存性(缓存能力):
缓存者, 必须决定是否存对一个响应,进行缓存.这取决于很多因素,比如原始服务器是否允许响应被缓存,是否设置了缓存过期时间.而有时候即缓存者缓存了一个响应.它仍然需要对该响应，进行验证,以确保该缓存是新鲜的.缓存能力和响应验证，是紧密相关的.
那么协议就是全部么？用户代理就那听话么？ 我们理所当然的写一些东西的时候就可靠了么？
下面这段是我的evernote中翻找出来的一段和缓存有关的坑爹的例子.也算给我们自己提个醒. 用户代理可能应为某些原因,给我们造成一些困扰. 所以切记想当然. 一切应以实测为准. 同样.代理服务器也完全可以违背http协议相关的缓存策略.所以 理论上很多东西，都是不可信的：
demo:
document.onclick = function () {
var img = new Image;
document.body.appendChild(img);
img.src=https://passport.baidu.com/?verifypic";
alert(img.complete)
//CollectGarbage();
}IE7+,opera 如果src是一个静态不变的地址.则 不会再发起请求(无视http缓存相关头域).而直去取缓存文件 。 而且是完全不走network 模块的那种. 所以甚至httpWatch也不会抓到 cache 的项.
因为该img 会被保存在内存中. 即使 没有 img句柄,而直接是一个 new Image().src=xxx 也是如此. 并且 无论图片资源是否强制缓存.http头指定该资源不缓存,亦如此. 这也是为什么IE6有另外某个必须保持new Image句柄的原因.因为IE6 和 IE7+对new Image的策略完全不同， IE6是不会在内存中保持new Image对象的(这也是为什么ie6会有后面提到的那个问题的本质原因.).而 IE7+会在内存中缓存该对象. 并以url作为索引.opera12-也是如此.
所以,如果是借助new Image 上报，即使image资源的http 相关缓存头,配置正确(no-cache,no-store,expires过期).在IE7+和Opera12-中，也应该使用随机数.来绕过浏览器 内存缓存new Image的坑. 但是不能因此而放弃配置正确的http缓存策略先关头. 因为这才是正道. 符合语义的做法. 随机数是为了修正用户代理的错误. 不能混淆或相互代替. 另外随机数，也可能是为了解决另外一个问题, 仍然和IE系列有关，比如未指定相关缓存头域情况下,IE系默认对资源有会话级缓存的bug.
而ie6 , 一个简单的 new Image().src=xxx 的上报. 会可能在GC(浏览器主动触发,如因页面渲染触发的GC,而不是主动调用CollectGarbage方法)时abort 掉这个请求.(此问题其他浏览器，IE7+都不存在.)
即使是
var img = new Image();
img.src= xxx 也如此
解决办法:
var log = function(){
var list = [];
return function(src){
var index = list.push(new Image) -1;
list[index].onload = function(){
list[index] = list[index].onload = null;
}
list[index ].src = src;
}
}();
但是要注意的问题是: 0 content length or not image mimeTypes . 不会触发onload. 也就是说，上面的代码.有可能不会及时回收资源.这取决于上报的服务器的配置了. 也许可以借助onerror来综合解决。但我个人认为.这里不会造成内存泄露. 就算你一个页面有100次上报,也无所谓. 而且 对于ie7 - ie10 pp2(更高版本还不好说)来说 .总是在内存中自动缓存每个new Image对象,那么是否我们主动使其持有句柄,其实意义也都不大了.