PHP沉思录-第五篇-Session有效期问题-左轻侯-《程序员》2008年10月号

建立时间:2008-11-09 01:12:09   最后修改时间:2008-11-09 01:12:09  
php

本文发表在《程序员》杂志第10期 

PHP沉思录之五:Session有效期问题 
左轻侯 
2008.9.07 
   
Session处理是全部的Web应用都必须面对的问题。PHP中对session有效期的处理,和其余的解决方案有着很大的不一样,这是和PHP的工做机制相关的。 
在传统的client/server应用中,对于session失效的状况,能够交给网络协议本身来处理。不管是client端主动关闭链接,仍是由于网络异常而致使的链接中断,server端都可以获得通知,触发链接中断的事件。只要编程响应这一事件,执行指定的操做便可。但对于web应用来讲,状况却彻底不同。HTTP协议自己是无状态的,也就是说,每当client/server完成一次请求/响应的过程后,链接就会被断开。在断开链接之后,server并不知道client是否继续“在线”,还会继续发送下一次请求。换句话说,不管client端的用户已经关闭了浏览器窗口,仍是用户仅仅在阅读当前网页并准备在下一秒钟继续浏览,或者用户由于Windows崩溃/停电/硬盘坏掉/网线被拔/地球爆炸而完全没法再发送下一个请求,server都一无所知。(在HTTP 1.1中,浏览器能够经过keep-alive参数,来通知server不要在响应请求后主动断开链接,从而实现物理上的长链接。可是,这只是为了提升网络传输的性能而采起的措施,HTTP在逻辑上仍然是无状态的。)所以,只能经过某种模拟的方式来判断当前session是否有效。若是某个session在超过一段时间后没有对server端发出请求,server都会判断用户已经“离线”,当前session失效,并触发链接中断的事件。要作到这一点,server须要运行一个后台线程,定时扫描全部的session信息,判断session是否已经超时。 
PHP处理session的原理也不例外,可是在具体的实现方式上,却不同凡响。这是由于,因为PHP的工做机制,它并无一个后台线程,来定时地扫描session信息并判断其是否失效。它的解决之道是,当一个有效请求发生时,PHP会根据某个几率,来决定是否调用一个GC(Garbage Collector)。GC的工做,就是扫描全部的session信息,用当前时间减去session的最后修改时间(modified date),同配置参数(configuration option)session.gc_maxlifetime的值进行比较,若是生存时间已经超过gc_maxlifetime,就把该session删除。这是很容易理解的,由于若是每次请求都要调用GC代码,那么PHP的效率就会低得使人吃不消了。这个几率取决于配置参数session.gc_probability/session.gc_divisor的值(能够经过php.ini或者ini_set()函数来修改)。默认状况下,session.gc_probability = 1,session.gc_divisor=100,也就是说有1%的可能性会启动GC。 
这三个参数,session.gc_maxlifetime/session.gc_probability/session.gc_divisor均可以经过php.ini或者ini_set()函数来修改。但要记得,若是使用ini_set()函数的话,必须在每个页面的开始处都调用ini_set()。 
  这又致使了另一个问题,gc_maxlifetime只能保证session生存的最短期,并不可以保存在超过这一时间以后session信息当即会获得删除。由于GC是按几率启动的,可能在某一个长时间内都没有被启动,那么大量的session在超过gc_maxlifetime之后仍然会有效。固然,发生这种状况的几率很小,可是若是你的应用对session的失效期要求很精确的话,这会致使很严重的问题。解决这个问题的一个方法是,把session.gc_probability/session.gc_divisor的机率提升,若是提到100%,就会完全解决这个问题,但显然会对性能形成严重的影响。另外一个方法是放弃PHP的GC,本身在代码中判断当前session的生存时间,若是超出了 gc_maxlifetime,就清空当前session。 
PHP中的session有效期默认是1440秒(24分钟),也就是说,客户端超过24分钟没有刷新,当前session就会失效。要修改这个默认值,正确的解决办法是修改配置参数session.gc_maxlifetime。
我曾经在网上搜索过这个问题的解决方式,找到的结果千奇百怪。有的说要设置“session_life_time”,据我知所,PHP中没有这个参数。有的说要调用session_set_cookie_params,或者设置session.cookie_lifetime,这仅仅用于设置client端cookie的生存时间,换言之,只当client端cookie的生存时间小于server端的session生存期时,修改这个值才有效,而且最长不能超过server端的session生存期,缘由很简单,当server端的session已经失效时,client端cookie的生存时间再长也是没有意义的。还有的说要调用 session_cache_expire,这个参数用于通知浏览器和proxy,当前页面的内容应该被缓存多长时间,和session的生存期并无直接关系。 
听起来,这种解决方案很完美。可是,当你在实际中尝试修改session.gc_maxlifetime的值的时候,你极可能会发现,这个参数基本不起做用,session有效期仍然保持24分钟的默认值。甚至可能出现,在开发环境下工做正常,在服务器上却无效! 
为了完全解决这个问题,须要对PHP的工做细节进行进一步的分析。 
  在默认状况下,PHP 中的session信息会以文本文件的形式,被保存在系统的临时文件目录中。这个路径由配置参数session.save_path指定。在Linux下,这一路径一般为 mp,在 Windows下一般为C:WindowsTemp。当服务器上有多个PHP应用时,它们会把本身的session文件都保存在同一个目录中(由于它们使用同一个session.save_path参数)。一样地,这些PHP应用也会按必定机率启动GC,扫描全部的session文件。 
  问题在于,GC在工做时,并不会区分不一样站点的session。举例言之,站点A的gc_maxlifetime设置为2小时,站点B的 gc_maxlifetime设置为默认的24分钟。当站点B的GC启动时,它会扫描公用的临时文件目录,把全部超过24分钟的session文件所有删除掉,而无论它们来自于站点A或B。这样,站点A的gc_maxlifetime设置就形同虚设了。 
找到问题所在,解决起来就很简单了。在页面的开始处调用session_save_path()函数,它可以修改session.save_path参数,把保存session的目录指向一个专用的目录,例如 mpmyapp。这样,gc_maxlifetime参数就工做正常了。 
使用公用的session.save_path还会致使安全性问题,由于这意味着,同一台服务器上的其它PHP程序也能够读取你的站点的session文件,这可能被用于黑客攻击。另外一个问题是效率:在一个繁忙的站点中,可能存在成千上万个session文件,而把许多不一样网站的session文件都放在同一个目录下,不管是对单个文件的读写,仍是遍历全部文件进行GC,都无疑会致使性能的下降。所以,若是你的PHP应用和别的PHP应用运行在同一台服务器上的话,强烈建议你使用本身的session.save_path。 
严格地来讲,这算是PHP的一个bug。当PHP在进行GC时,它应该区别来自不一样站点的session文件,并应用不一样的gc_maxlifetime值。目前,最新的PHP 5.2.X仍然存在这个问题。 
上文说到,在一个繁忙的站点中,可能存在成千上万个session文件,即便区分了不一样站点的session.save_path目录,单个站点的session文件数目仍然可能致使效率问题。为了解决这一问题,可行的几种方法有: 

 若是PHP运行在Linux系统下,使用ReiserFS文件系统取代默认的ext2/ext3文件系统。ReiserFS对于大量小文件的存取性能,比ext2/ext3有极大的提升。 
 将session.save_path指向一个内存路径。这意味着,session文件的读写只在内存中进行,而不执行磁盘操做。 
 session.save_path接受一个额外的N参数,用于指定目录的级数。例如,“5;/tmp” 将致使建立相似这样的session文件:/tmp/4/b/1/e/3/sess_4b1e384ad74619bd212e236e52a5a174If。具体的说明,请参见:http://cn.php.net/manual/en/session.configuration.php#ini.session.save-path 
 终极的解决方案,是放弃PHP的session处理机制,本身编码接管全部的session处理操做,经过session_set_save_handler()函数来实现。经过本身接管session处理,能够将全部的session保存在专门的数据库(每每使用内存表)中,从而完全解决session文件带来的问题,而且能够方便地实现session的共享和复制。这也是大型的PHP应用通常会使用的方式。关于session_set_save_handler()函数的使用,网上和相关图书都有详细的说明,这里再也不赘述。值得一提的是,即便在这种方式下,启动GC的几率仍然取决于session.gc_probability/session.gc_divisor。 程序员

相关文章
相关标签/搜索