之前在一个叫魔法实验室的博客中看过一篇《php session原理彻底分析》的文章，作者从session的使用角度很好阐述了在代码运行过程中，每个环节的变化以及相关参数的设置及作用。本来想把原文转帖过来，但是原博客被关闭了。不知是这次大范围的重新备案，还是其他什么原因所致。通过百度快照找到一些原文资料，没找到的将按之前的理解重新整理，以使大家对session能有更多了解。
楔子：Session大白话
Session，英文翻译为“会话”，两个人聊天，从第一句问好，到最后一句再见，这就构成了一个会话。PHP里的session主要是指客户端浏览器与服务端数据交换的对话，从浏览器打开到关闭，一个最简单的会话周期。计算机语言一般怎么实现会话呢？举个通俗的例子：
服务端好比一个理发店，客户端好比每一个去理发的客人，很多理发店都有这种促销手段，连续消费10次的客人，可以免费一次，大概有三种方式来实现：
1、理发师傅记性太好，你来过几次，他看一眼就知道——这叫协议本身支持会话；
2、每个客人发一个会员卡，你每次消费，都要带着这个卡片，消费一次记录一笔，当然还要加盖印章——这叫通过cookie实现会话，缺点是安全性不高，我完全可以伪造会员卡或者公章；
3、理发店准备一个大帐本，客人每人对应一个会员号或者自己的个人资料，甚至密码，每个客人来消费，报一下自己的会员号，再把消费次数记录到大帐本里——这就是session实现会话，客人脑子里的会员号就是保存在客户端的SESSIONID，大帐本就是保存在服务端的session数据，这样相比第二种方法，安全性要高很多，除非你说你把自己的会员号和密码都搞丢了，这叫做伪造客户端的SESSIONID。
因为http协议是无状态的，所以php要实现会话只能通过后面两种方式，前一种cookie，缺点已经说了，安全性不高，所以重要的会话会选择使用session。session会话必须依靠一个标识，也可以理解成一个暗号，就是SESSIONID。这是个经过加密的串，保存在客户端，通常在cookie里，客户端与服务端的每次交流都是通过这个SESSIONID，客户端先自报家门，服务器才能找到你在服务端保存的会话数据，继续通话。
php.ini常用session设置
[服务端]
session.save_handler = files
默认为file，定义session在服务端的保存方式，file意为把sesion保存到一个临时文件里，如果我们想自定义别的方式保存（比如用数据库），则需要把该项设置为user；
session.save_path = "/tmp/"
定义服务端存储session的临时文件的位置。
session.auto_start = 0
如置1，则不用在每个文件里写session_start(); session自动start。
session.gc_probability = 1
session.gc_divisor = 100
session.gc_maxlifetime = 1440
这三个配置组合构建服务端session的垃圾回收机制session.gc_probability与session.gc_divisor构成执行session清理的概率，理论上的解释为服务端定期有一定的概率调用gc函数来对session进行清理，清理的概率为：gc_probability/gc_divisor 比如：1/100 表示每一个新会话初始化时，有1%的概率会启动垃圾回收程序，清理的标准为session.gc_maxlifetime定义的时间。
[客户端]
session.use_cookies = 1
sessionid在客户端采用的存储方式，置1代表使用cookie记录客户端的sessionid，同时，$_COOKIE变量里才会有$_COOKIE[‘PHPSESSIONID’]这个元素存在；
session.use_only_cookies = 1
也是定义sessionid在客户端采用的存储方式，置1代表仅仅使用 cookie 来存放会话 ID。一般来说，现在客户端都会支持cookie，所以建议设置成1，这样可以防止有关通过 URL 传递会话 ID 的攻击。
session.use_trans_sid = 0
相对应于上面那个设置，这里如果置1，则代表允许sessionid通过url参数传递，同理，建议设置成0；
session.referer_check =
这个设置在session.use_trans_sid = 1的时候才会生效，目的是检查HTTP头中的"Referer"以判断包含于URL中的会话id是否有效，HTTP_REFERER必须包含这个参数指定的字符串，否则URL中的会话id将被视为无效。所以一般默认为空，即不检查。
session.name = PHPSESSID
定义sessionid的名称，即变量名，通过浏览器http工具可以查看PHPSESSID的值；
session.hash_function = 0
选择session_name的加密方式，0代表md5加密，1代表sha1加密，默认是0，但是据说用sha1方式加密，安全性更高；
session.hash_bits_per_character = 4
指定在session_name字符串中的每个字符内保存多少位二进制数，这些二进制数是hash函数的运算结果。
4 bits: 0-9, a-f
5 bits: 0-9, a-v
6 bits: 0-9, a-z, A-Z, "-", ","
url_rewriter.tags = "a=href,area=href,frame=src,input=src,form=,fieldset="
指定重写哪些HTML标签来包含sid(session_id)（仅在"session.use_trans_sid"打开的情况下有效），URL重写器将添加一个隐藏的"<input>"，它包含了本应当额外追加到URL上的信息。
session.cookie_lifetime = 0
保存sessionid的cookie文件的生命周期，如置0，代表会话结束，则sessionid就自动消失，常见的强行关闭浏览器，就会丢失上一次的sessionid；
session.cookie_path = /
保存sessionid的cookie文件在客户端的位置；
session.cookie_domain = /
保存sessionid的cookie的域名设置，这跟cookie允许的域名的访问权限设置有关，一般来说想让自己网站所有的目录都能访问到客户端的cookie，就应该设置成“/”如需要详细了解，可以看下setcookie()函数的domain参数相关设置和使用方法；
session.bug_compat_42 = 1
session.bug_compat_warn = 1
这两个可以说几乎是快要被废弃的设置，是为了老版本的php服务的，主要是针对session_register函数，因为php5的register_global默认是关闭状态，所以在php5里根本用不到session_register这个函数；并且php6就要废除这个设置，直接定义为关闭，所以没必要研究这两个了；
session_start()做了些什么？
假设php.ini中session的几个关键参数配置为：
session.save_handler = files
session.use_cookies = 1
session.name = PHPSESSID
session.save_path = "/tmp/"
下面通过代码样例阐述，在一个会话过程中session_start的作用。
程序1:
<?php
session_start();
$_SESSION['uname'] = 'monkey';
$_SESSION['ukey'] = 20119999;
?>
程序1执行后，session_start()会做两件事：
1、在客户端生成一个存放PHPSESSID的cookie文件，这个文件的存放位置和存放方式跟程序的执行方式有关，不同的浏览器也不尽相同，这一步会产生一个序列化后的字符串——PHPSESSID；查看浏览器中的cookie信息，可以安装相关插件。firefox中httpfox,web developer等都是很好的工具。
2、在服务端生成一个存放session数据的临时文件，存放的位置由session.save_path参数指定，名称类似于“sess_85891d6a81ab13965d349bde29b2306c”，“sess_”代表这是个session文件，“85891d6a81ab13965d349bde29b2306c”即此次会话的PHPSESSID，跟客户端的PHPSESSID值是一样的。
用编辑器打开“sess_85891d6a81ab13965d349bde29b2306c”文件，会看到一串“uname|s:6:"monkey";ukey|i:20119999;”这样的内容。这个文件里存放的就是$_SESSION变量的具体内容，每个变量用“;"分号隔开。
格式为：变量名 | 变量类型 : [长度] : 值; 例如: uname|s:6:"monkey"; 表示SESSION变量uname的类型为字符串，值长度为6，值为monkey.
那么问题来了，上面说的两件事，是在程序执行到session_start()，就完成的吗？这两件事，谁先谁后呢？
让试验来证明，稍微改动一下程序：
程序2:
<?php
session_start();
$_SESSION['uname'] = 'monkey';
$_SESSION['ukey'] = 20119999;
sleep(30);
?>
先把客户端和服务端的session数据通通删除，然后执行程序2，趁着程序里的sleep30秒的工夫，去查看客户端和服务端的session情况，发现：在程序执行过程中，客户端并没有建立保存PHPSESSID的cookie文件，服务端却已经有了保存session内容的临时文件，但是文件里没有内容，等30秒时间过了之后，客户端的cookie文件才会生成，服务端的session文件里才有了内容。
由此推断大致流程应该为：在程序执行到session_start()的时候，服务端首先生成PHPSESSID，并生成相对应的session文件，但是在程序进行$_SESSION赋值的时候，并没有把相应的值写入到session文件里，姑且臆断为保存在内存里吧，到了程序执行完毕后，才会在客户端生成保存PHPSESSID的cookie文件，并把$_SESSION变量里的值写入服务端的session文件里，至于最后两个步骤谁先谁后，暂时还没有想到好办法来证明。
为了更进一步论证，删除客户端和服务端的session相关内容执行程序3，观察第一次和第二次的结果：
程序3:
<?php
session_start();
$_SESSION['uname'] = 'monkey';
$session_id = session_id();
$sess_file = "/tmp/sess_".$session_id;
$content = file_get_contents($sess_file);
echo '***'.$_COOKIE['PHPSESSID'] .'***';
echo '<br />' . $_SESSION['uname'] . '<br />';
echo '***'.$content.'***';
?>
上面说的是第一次sessin_start()的执行方式，也就是一套程序里，第一个session_start()出现的时候所做的事情，下面来看之后的session_start()：
假设的php.ini配置：session.cookie_lifetime = 0
程序4:
<?php
session_start();
echo $_SESSION['uname'];
echo $_SESSION['ukey'];
?>
现在，客户端已经有了保存PHPSESSID的cookie文件，服务端也有了保存session内容的sess_文件，执行程序4，会打印出正常的内容。这时，如果强行关闭浏览器，再执行程序4，结果会怎样呢？
首先，session.cookie_lifetime设置成0，表示客户端保存PHPSESSID的cookie文件的生存周期为0，浏览器如果处于开启状态，PHPSESSID的值会保存在内存中，一旦强行关闭，保存PHPSESSID的cookie文件会同时销毁，但是服务端并没有执行session_destroy（），所以，服务端的session数据文件还在，但是当浏览器再次打开执行程序4，发现什么都没有输出，由此推理：
session_start()首先会去获取客户端cookie里的PHPSESSID，然后与“sess_”组成文件名，去服务端查找这个文件，然后取出文件里的内容，把内容放到$_SESSION全局变量里以供使用。浏览器强行关闭，再打开，之前的PHPSESSID丢失，这时遇到session_start()就相当于上面说的第一次执行，会生成一个新的PHPSESSID，这个PHPSESSID匹配不到之前那个服务端的sess_文件，所以取不到内容。当然，服务端也有能跟这个PHPSESSID匹配的文件，不过，那个文件还是空的。
所以，有的系统为了实现同一用户只能在一台机器甚至一个浏览器登录的机制，如果没有修改session.cookie_lifetime的设置，就会出现强行关闭浏览器之后，在服务端session生存期截止前该，用户登录不进去的情况，比较好的办法是把session.cookie_lifetime设置成一个比较大的值，反正一个cookie文件存在时间久一些也没什么影响。
http://victorwmh.iteye.com/blog/1068679
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 下，这一路径通常为\tmp，在 Windows下通常为C:\Windows\Temp。当服务器上有多个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的目录指向一个专用的目录，例如\tmp\myapp\。这样，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文件数目仍然可能导致效率问题。为了解决这一问题，可行的几种方法有：
1. 如果PHP运行在Linux系统下，使用ReiserFS文件系统取代默认的ext2/ext3文件系统。ReiserFS对于大量小文件的存取性能，比ext2/ext3有极大的提高。
2. 将session.save_path指向一个内存路径。这意味着，session文件的读写只在内存中进行，而不执行磁盘操作。
3. 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
4. 终极的解决方案，是放弃PHP的session处理机制，自己编码接管所有的session处理操作，通过 session_set_save_handler()函数来实现。通过自己接管session处理，可以将所有的session保存在专门的数据库（往往使用内存表）中，从而彻底解决session文件带来的问题，并且可以方便地实现session的共享和复制。这也是大型的PHP应用一般会使用的方式。关于session_set_save_handler()函数的使用，网上和相关图书都有详细的说明，这里不再赘述。值得一提的是，即使在这种方式下，启动GC的概率仍然取决于session.gc_probability/session.gc_divisor。
浙公网安备 33010602011771号