PHP SESSION过期时间

自PHP5以后，SESSION的实现中采用COOKIE技术。客户端的$_COOKIE['PHPSESSIONID'](默认cookie名称为PHPSESSIONID，可通过php.ini中的session_name修改)，服务器端存储对应的session文件（session文件名与上述的cookie值一一对应）默认时间为24分钟；

当执行session_start的时候，做了两件事：1.检查客户端发送过来的所有cookie，根据$_COOKIE['PHPSESSID']（如果有的话，apache产生的随机字符串,比如0lkbd2se458r600m2m7o1r4ic5）的值来访问相应的session文件（如sess_0lkbd2se458r600m2m7o1r4ic5），这两者是一一对应的关系，session文件里面存储是序列化的用户信息；2. 如果客户端没有传过来$_COOKIE['PHPSESSID'],就会由服务器段生成一个随机的$_COOKIE['PHPSESID']并存储在客户端。

首先，session的过期时间由两方面决定：

1. 存储在客户端的$_COOKIE['PHPSESSID']的过期时间，默认cookie名称为PHPSESSID，可通过php.ini中的session.name修改；

2. 存储在服务器的对应的session文件，（session文件名和上述的cookie值一一对应），默认为1440秒，即24分钟；

当执行session_start的时候，做了两件事：1.检查客户端发送过来的所有cookie，根据$_COOKIE['PHPSESSID']（如果有的话，apache产生的随机字符串,比如0lkbd2se458r600m2m7o1r4ic5）的值来访问相应的session文件（如sess_0lkbd2se458r600m2m7o1r4ic5），这两者是一一对应的关系，session文件里面存储是序列化的用户信息；2. 如果客户端没有传过来$_COOKIE['PHPSESSID'],就会由服务器段生成一个随机的$_COOKIE['PHPSESID']并存储在客户端。

鉴于客户端的cookie不一定可用（internet禁用项），SessionID可以使用客户端的Cookie或者Http1.1协议的Query_String（就是访问的URL的“?”后面的部分）来传送给服务器【修改php.ini， session.use_trans_sid 都被激活，相对 URI 将被自动修改为包含会话 ID。】，然后服务器读取Session的目录……

如此，我们如果想要修改session文件的过期时间就有两种途径：

1. session_set_cookie_params('50');//修改$_COOKIE['PHPSESSID']的生存时间为50秒；

（或者可以：secookie(session_name(),session_id(),time()+50);），当cookie中PHPSESSIONID，服务器端无此sessionid文件,服务器端会重新创建session文件；

2.ini_set('session.gc_maxlifetime','50');//设置session文件的有效时间为50秒，此为session数据在服务器端存储时间，如果超过，session数据会自动删除；

详情可参见：https://www.oschina.net/question/196568_59569

神奇的是通过第二种方法修改参数基本不起作用，session有效期仍然保持24分钟默认值，这是因为PHP的工作机制中并没有一个daemon进程定时的扫描session信息并判断其失效。

PHP虽然采用Garbage Collection Process对过期的session进行回收，然而并不是每次session建立时都能唤起‘garbage collection' process。GC是按照一定的概率启动的【默认情况下，session.gc_probability ＝ 1，session.gc_divisor ＝100，也就是说有1%的可能性会启动GC】。这主要是出于服务器性能方面的考虑，每个session都触发gc的话，访问量大时，服务器端是吃不消的，然而按照一定概率开启gc，当流览量大的时候，session过期机制能够正常运行，而且服务器效率得到节省。至于具体设置细节应该都是多年的经验积累得出的。

综上所述，session_set_cookie_params('50')是在客户端cookie未被禁用时间接的作用【改变键值】了服务器端sessionID文件，而设置session文件有效时间，服务器端sessionFile的GC机制又是“碰运气”式的小概率事件，皆非明智之举，如想长远稳定发展：要么解决GC的鸡肋：自定义session类文件处理【http://www.jb51.net/article/71200.htm】，要么建表ecs_session记录维护了。