CI自带的缓存系统确实很方便，但她存在一个很大的弊端，看缓存系统的源码：
CI把md5(index.php+uri_string)作为缓存文件名（没完全copy，详见libraries/output.php）
这个uri_string允许URI串夹杂垃圾信息，比如：
http://ci-site.com/index.php/index/index/1
http://ci-site.com/index.php/index/index/1/2
http://ci-site.com/index.php/index/index/1/2/3
上面三个请求，CI将生成3个不同的缓存文件
问题来了，假如攻击者写一个并发访问脚本：
每秒并发访问100次（任何adsl用户都有足够带宽发起攻击）
循环访问 index.php/index/index/1 至 index.php/index/index/10000000
那么服务器将生成一千万个首页垃圾缓存，在同一个目录里面！
假如你的网站首页html有10kb（一般来讲，10kb作为首页不算大）
这个缓存目录的尺寸将达到：10kb x 10,000,000 = 100GB
完成攻击所需时间：大约27小时
更重要的是CodeIgniter本身并没有提供更详细的缓存检测机制和缓存容量限制机制，加入你没有对cache目录进行磁盘配额限制的话，那么一轮并发高的缓存攻击将有可能将硬盘塞满，之后网站就会变得异常缓慢。而且更要命的是CodeIgniter本身没有缓存清除机制，只能干等着缓存过期或者手动清除，CodeIgniter最大的优势在于它的性能和学习曲线。
总觉得CodeIgniter本身就是一个半成品，没有缓存清除机制也就算了，还没有模块化缓存（即只缓存页面某个或者某几个部分）的的机制，CodeIgniter这么优秀的Framework在缓存方面算是做得很失败了，不过得益于它优秀的扩展性能，仍然有很多解决方法，况且任何Framework都不是完美的。
解决CodeIgniter大体上有四种方法
1）关闭缓存，我觉得这基本上算不得一种解决方法，因为这牺牲了网站的性能
2）架设缓存服务器，对于一般的中小型网站来说这也比较奢侈，且不说squid或者vanish的学习曲线有点长，也没与服务器设备。
3）增加严格的检测机制，这是一个非常可行的方案，比如对URI每个传入参数的类型进行严格的验证，在一个页面显示前进行详细的处理，比如ID为10000的记录数据库中根本不存在，那么使用show_404（）方法输出404页面，这个页面并不会被缓存，假如没有增加这个验证，程序输出的页面将会被缓存，只是页面的某个区域的内容为空而已。比如显示文章的区域是空，侧边栏和头部都是从模板中继承过来了，仍然被缓存了。
4）使用其他cache类替代CodeIgniter的缓存类，比如APC
有道理。
[Reply]
寺
[Reply]