在应用交付设备的功能指标中有一项叫HTTP智能缓存,这个功能在各品牌的产品中大都能实现。应用交付设备的“全代理”模式,使得服务器的HTTP RESPONSE内容可以在应用交付设备中缓存下来,当客户端再次发起请求,对应的内容先在缓存空间中查找,命中的由缓存进行回应,没命中的再转发给源服务器获取。缓存最大的作用就是减少客户端对源服务器的直接压力,由于一部分请求已由应用交付设备代为回应,如果相同的内容被经常访问,那还能极大提高客户端的响应速度。

应用交付设备是利用本身的内存空间进行缓存,因而也叫RAM CACHE。我们知道内存空间是有限的,不能像硬盘阵列那样存储超大量的数据,所以RAMCACHE只适用于反向缓存,即对IDC内部的webserver实现内容缓存。如果需要做正向代理缓存,则建议选用专业的正向代理设备,那些设备一般会配置“T”级存储空间,可存放大数据量的内容。既然说应用交付设备的缓存空间有限,那就有必要知道有哪些内容是需要缓存的,还有缓存的规则是什么?(可参考RFC2616的13、14章节,规范对HTTP缓存有很详细的描述)。RAM CACHE对如下内容进行缓存:


1)200、203、300、301、302和410的响应(若响应中没有Content-Length的包头字段,将不做缓存);

2)缺省只响应GET方法;

3)基于策略定义的特定URI或内容类型,如.css。.jpg等等;

4)基于自定义脚本策略定义的其他HTTP方法;


RAM CACHE不做缓存的项目包括:

1)request中包含认证信息或带有Proxy-Authorization报头的不作缓存,此类认证内容涉及安全性;

2)在HTTP response中带有Vary报头(Accept-Encoding除外)的不做缓存;

3)response中带有Cache-Control报头且赋值为No-Cache、No-Store、Private的不作缓存;

4)response中带有Pragma报头的不做缓存;

5)response中带有Set-Cookie或Set-Cookie2报头的不作缓存,因为cookie中常带有终端用户的信息;

6)如果response属于FIN类型,或没携带Content-Length、Transfer-Encoding:Chunked属性的将不作缓存

如上方一个示例,既有Pragma报头,且Cache-Control赋值为no-cache,可看到由服务器直接回应了响应的内容;而符合条件的内容,直接由缓存回复(如下图)。

接下来再探讨一下缓存内容更新的问题,缓存内容必须“fresh”才能保证客户端获取内容的准确性和完整性,根据RFC2616的规范,缓存内容可通过缓存AGE、验证机制等方式来确认缓存内容的正确性。

如果本地时钟与源服务器时钟同步,且响应途径的所有缓存符合HTTP/1.1,我们就能得到一个可信赖的结果。而通过验证模型,既能确认缓存对象是否正确可用,也能减少真实内容传输带来的带宽资源等的占用。如我们可在响应内容中看到304代码,表示“没有改变”,源服务器在响应缓存代理时只有校验,没有传输实体。

通过上述说明,相信大家对应用交付的RAMCACHE不难理解了,把源服务器响应的可缓存的内容先缓存下来,如果客户端对相同内容多次请求,那缓存就能马上响应了。

通过策略定制,还能实现以下功能:

1)调整缓存对象的AGE;

2)根据内容的大小范围了定义哪些可被缓存;

3)可针对特定的URI定义为缓存或不缓存;

4)可针对特定类型的内容进行缓存,如.CSS、.JPG等等


(ZJM)