我一直希望有一个具有快速更新能力的缓存，因为很多需求都要求更新及时，用小学数学方法也很容易计算出缓存5秒所能提升的效率。但是，在squid中，却无法将一个页面缓存5秒钟，59秒也不行，64秒是一个模糊的界线。低于模糊界线的，一概MISS。

我无法给出这个问题的确切原因，因为我不愿意花时间读squid的源码，经过大量测试，估计问题出在squid对Expires和Cache-Control的判断上，我无法解释其来由，难道是一个逻辑上的经典bug？。

仅仅是可能啊，猜测来的，不必认真。以下是我测试的结果，结合网上的极少的一些资料一并整理，这些通常称为现象：

1、缓存最小的expires大概是65秒，我测试64秒有通过，但国外的一个玩家居然发现有穿透的现象。

http://markmail.org/message/fcn2z4ym47svjdmc（估计邪了，穿之）

其中提到用Squid 2.7.STABLE4 or 3.0.STABLE9能解决问题，经测试无效，squid的Change Log也没提到此类事宜。

2、具有Last-Modified的页面，设多长的Cache-Control没有任何问题，目前news.163.com是30秒，无问题，有朋友也提到：

http://blog.csdn.net/ikmb/archive/2009/01/07/3729014.aspx

所以，要想实现超短缓存，加上Last-Modified吧。

3、在squid配置文件中的refresh_pattern，以分钟为单位，最小是零分钟，其次是一分钟，所以这个配置可以将缓存压在60秒。

4、在部分squid上可缓存60秒的Cache-Control，但要多刷新几次……

5、两个squid连在一起，有一个squid不能缓存60秒Cache-Control，但另一个能做到，所不同的是后一个承载的请求量大。

6、经测试不是由于cache_replacement_policy所造成。

7、经测试不是由于refresh_patterns所造成。

8、其他的选项，更没能瞬间改变此状况，或许是测漏了……基本确信不是配置所能控制，此乃bug，待开源社区解决。

这些测试结果另我比较沮丧，本来希望squid3.0能解决此问题，这样就可有一个冠冕堂皇的理由去装3.0了。目前的squid3.0、2.7、2.6和2.5版本，我现在还在用2.5，但确实很难找出有什么能说服人去升级的理由？这是squid一个很失败之处啊。