关于session

最新推荐文章于 2021-03-27 10:01:04 发布

renwotao2009

最新推荐文章于 2021-03-27 10:01:04 发布

阅读量1k

点赞数

分类专栏： Python/PHP 文章标签： web

Python/PHP 专栏收录该内容

14 篇文章 0 订阅

订阅专栏

第一篇

官方手册：http://www.php.net/session_start
Web中的Session指的就是用户在浏览某个网站时，从进入网站到浏览器关闭所经过的这段时间，也就是用户浏览这个网站所花费的时间。因此从上述的定义中我们可以看到，Session实际上是一个特定的时间概念。
需要注意的是，一个Session的概念需要包括特定的客户端，特定的服务器端以及不中断的操作时间。A用户和C服务器建立连接时所处的Session同B用户和C服务器建立连接时所处的Session是两个不同的Session。
session的工作原理
（1）当一个session第一次被启用时，一个唯一的标识被存储于本地的cookie中。
（2）首先使用session_start()函数，PHP从session仓库中加载已经存储的session变量。
（3）当执行PHP脚本时，通过使用session_register()函数注册session变量。
（4）当PHP脚本执行结束时，未被销毁的session变量会被自动保存在本地一定路径下的session库中，这个路径可以通过php.ini文件中的session.save_path指定，下次浏览网页时可以加载使用。
session存储在服务器端，默认情况下，php.ini中设置的SESSION保存方式是 files（session.save_handler = files），即使用读写文件的方式保存 SESSION 数据，而 SESSION 文件保存的目录由 session.save_path 指定，文件名以 sess_ 为前缀，后跟 SESSION ID，如：sess_c72665af28a8b14c0fe11afe3b59b51b。文件中的数据即是序列化之后的 SESSION 数据了。
如果访问量大，可能产生的SESSION文件会比较多，这时可以设置分级目录进行SESSION文件的保存，效率会提高很多，设置方法为：session.save_path=”N;/save_path”，N 为分级的级数，save_path 为开始目录。
当写入 SESSION 数据的时候，PHP 会获取到客户端的 SESSION_ID，然后根据这个 SESSION ID 到指定的 SESSION 文件保存目录中找到相应的 SESSION 文件，不存在则创建之，最后将数据序列化之后写入文件。读取 SESSION 数据是php中的Session与Cookie在PHP开发中对比起Cookie，session 是存储在服务器端的会话，相对安全，并且不像 Cookie 那样有存储长度限制，本文简单介绍 session 的使用。
由于 Session 是以文本文件形式存储在服务器端的，所以不怕客户端修改 Session 内容。实际上在服务器端的 Session 文件，PHP 自动修改 session 文件的权限，只保留了系统读和写权限，而且不能通过 ftp 修改，所以安全得多。
对于 Cookie 来说，假设我们要验证用户是否登陆，就必须在 Cookie 中保存用户名和密码(可能是 md5 加密后字符串)，并在每次请求页面的时候进行验证。如果用户名和密码存储在数据库，每次都要执行一次数据库查询，给数据库造成多余的负担。因为我们并不能只做一次验证。为什么呢?因为客户端 Cookie 中的信息是有可能被修改的。假如你存储 $admin 变量来表示用户是否登陆，$admin 为 true 的时候表示登陆，为 false 的时候表示未登录，在第一次通过验证后将 $admin 等于 true存储在 Cookie，下次就不用验证了，这样对么?错了，假如有人伪造一个值为 true 的$admin 变量那不是就立即取的了管理权限么?非常的不安全。
而 Session 就不同了，Session 是存储在服务器端的，远程用户没办法修改 session 文件的内容，因此我们可以单纯存储一个$admin 变量来判断是否登陆，首次验证通过后设置$admin 值为 true，以后判断该值是否为 true，假如不是，转入登陆界面，这样就可以减少很多数据库操作了。而且可以减少每次为了验证 Cookie 而传递密码的不安全性了(session 验证只需要传递一次，假如你没有使用 SSL 安全协议的话)。即使密码进行了 md5 加密，也是很容易被截获的。
当然使用 session 还有很多优点，比如控制容易，可以按照用户自定义存储等(存储于数据库)。我这里就不多说了。也是类似的操作流程，对读出来的数据需要进行解序列化，生成相应的 SESSION 变量。
用$_SESION之前必须要session_start()—-其中之一的功能,$_SESSION是服务器端的cookie，相当一个大数组(浏览器关闭前，和session销毁前)$_SESSION中的数据可以一直用(除了重新赋值)。 $_SESSION 好比一个数组 $_SESSION[‘name’]=’caocao’ 这好比在数组中加了一个元素，相当于$_SESSION=array(“name”=>”caocao”) 使用的时候还要使用$_SESSION[‘name’]才能得到’caocao’。

本文转自：http://blog.sina.com.cn/s/blog_969555e30101cx5l.html

第二篇

假设的php.ini配置：

session.save_handler = files
session.use_cookies   = 1
session.name              = PHPSESSID
session.save_path      = "/sessiondata/"

1.php:

<?PHP  

session_start();  

$_SESSION['test'] = 'test111';  

$_SESSION['test2'] = 22222;  

?>

程序1执行后，session_start()会做两件事：

1、在客户端生成一个存放PHPSESSID的cookie文件，

这个文件的存放位置和存放方式跟程序的执行方式有关，不同的浏览器也不尽相同，这一步会产生一个序列化后的字符串——PHPSESSID；

2、在服务端生成一个存放session数据的临时文件；
存放的位置由session.save_path参数指定，名称类似于“sess_b2f326ee7a8b7617c215a30d22a602f1”，“sess_”代表这是个session文件，“b2f326ee7a8b7617c215a30d22a602f1”即此次会话的PHPSESSID，跟客户端的PHPSESSID一定是一样的。

这个文件里存放的就是$_SESSION变量里的具体值，格式为：

变量名 | 变量类型 : [长度] : 值
eg：test|s:7:"test111";test2|i:22222;

那么问题来了，上面说的两件事，是在程序执行到session_start()，就完成的吗？这两件事，谁先谁后呢？

让试验来证明，稍微改动一下程序：

2.php:

<?PHP  

session_start();  

$_SESSION['test'] = 'test111';  

$_SESSION['test2'] = 22222;  

Sleep(30);  

?>

先把客户端和服务端的session数据通通删除，然后执行程序2，趁着程序里的sleep30秒的工夫，去查看客户端和服务端的session情况，发现：

在程序执行过程中，客户端并没有建立保存PHPSESSID的cookie文件，服务端却已经有了保存session内容的临时文件，但是文件里没有内容，等30秒时间过了之后，客户端的cookie文件才会生成，服务端的session文件里才有了内容。

由此推断大致流程应该为：在程序执行到session_start()的时候，服务端首先生成PHPSESSID，并生成相对应的session文件，但是在程序进行$_SESSION

赋值的时候，并没有把相应的值写入到session文件里，姑且臆断为保存在内存里吧，到了程序执行完毕后，才会在客户端生成保存PHPSESSID的cookie文件，并把$_SESSION变量里的值写入服务端的session文件里，至于最后两个步骤谁先谁后，暂时还没有想到好办法来证明。

下面用一个更直接的方法来证明刚才的结论：

3.php:

<?PHP  

session_start();  

echo $_SESSION['test'];  

echo $_SESSION['test2'];  

?>

现在，客户端已经有了保存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://blog.sina.com.cn/s/blog_6e70abbd0100n6ns.html

第三篇

在日常的web开发中，我们经常需要用到一些关于会话处理的知识，今天在这里就讨论一下关于在用户退出网站时候的关于session销毁的问题。

session的销毁，php为我们提供了一个session_destroy()函数，我们都知道$_SESSION是一个数组，那么既然是数组，我们就可以用unset来删除。

首先说一下$_SESSION数组，我们每次通过访问$_SESSION数组里面的值其实都有一个我们没看到的过程，这个过程就是每次php都需要首先从对应的session文件中去读出这个文件里的session信息，放到$_SESSION数组里面，然后我们开始使用这个数组。那么在我们需要删除的session信息的时候，我们想要删除的其实不是这个session数组，我们想要做的是删除这一切有关的信息，包括$_SESSION数组里面的信息，保存在服务器端的session文件以及保存在客户端cookie里面的sessionID，其实要删除保存在客户端的sessionID删除客户端的cookie就可以了。

下面我们来说具体情况，最简单的是你想到用unset删除$_SESSION数组，这个时候你做的仅仅是删除了$_SESSION数组，这个时候保存在服务器端的session文件没有删除，里面的信息依然完好，客户端的cookie也没有被删除，这种情况下在使用$_SESSION数组注册session信息已经不可能了，也就是说你注册的信息不会被写入session文件，在别的页面当然也就不能使用。第二种情况是你使用session_destroy()函数，这个时候你所做的其实是彻底删除了保存在服务器端的session文件，在执行session_destroy()函数以后，还可以引用$_SESSION数组里面的值，这不是期望的结果；正确的做法是我们首先通过$_SESSION数组清空保存在服务器端session文件里面的信息，然后删除客户端的cookie，然后彻底删除session即执行session_destroy()函数。

完整做法的代码：

<?php

session_start();//启用session

$_SESSION=array();//清空session文件里面的内容

if(isset($_COOKIE[session_name()])){

setcookie(session_name(),'',time()-3600,'/');//如果是基于cookie的session，删除保存在客户端的sessionID

}

session_destroy();//彻底删除session

?>

本文转自：关于session销毁的一些总结

第四篇

由于PHP的工作机制，它并没有一个daemon线程，来定时地扫描session信息并判断其是否失效。当一个有效请求发生时，PHP会根据全局变量 session.gc_probability/session.gc_divisor（同样可以通过php.ini或者ini_set()函数来修改）的值，来决定是否启动一个GC（Garbage Collector）。默认情况下，session.gc_probability ＝ 1，session.gc_divisor ＝100，也就是说有1%的可能性会启动GC。

GC的工作，就是扫描所有的session信息，用当前时间减去session的最后修改时间（modified date），同session.gc_maxlifetime参数进行比较，如果生存时间已经超过gc_maxlifetime，就把该session删除。

那为什么会发生gc_maxlifetime无效的情况呢？

在默认情况下，session信息会以文本文件的形式，被保存在系统的临时文件目录中。在Linux下，这一路径通常为\tmp，在Windows下通常为C:\Windows\Temp。当服务器上有多个PHP应用时，它们会把自己的session文件都保存在同一个目录中。同样地，这些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的目录指向一个专用的目录，gc_maxlifetime参数工作正常了。

还有一个问题就是，gc_maxlifetime只能保证session生存的最短时间，并不能够保存在超过这一时间之后session信息立即会得到删除。因为GC是按机率启动的，可能在某一个长时间内都没有被启动，那么大量的session在超过gc_maxlifetime以后仍然会有效。解决这个问题的一个方法是，把session.gc_probability/session.gc_divisor的机率提高，如果提到100%，就会彻底解决这个问题，但显然会对性能造成严重的影响。另一个方法是自己在代码中判断当前session的生存时间，如果超出了gc_maxlifetime，就清空当前session。

php session GC功能，就是Garbage Collector。这个GC启动的时候，会清除那些已经“超时”的session。它的工作原理是这样的：

用户访问并登陆网站，这时候后台会调用session_start来尝试生成一个会话（如果已经有会话，则相当于一次有效会话请求）
对于这样的每一次有效会话请求（Request），apache的php模块会根据session相关的全局变量gc_probability/gc_divisor =>计算出启动GC的概率，并由此概率来决定在这次请求中是否应该启动GC。举例来说，session.gc_probability的缺省值为1，session.gc_divisor的缺省值为100，则启动“垃圾回收”器的概率是1%，这就意味着在每100次请求中，会有可能清理一次过期会话
如果GC启动，则GC会扫描当前会话所在路径（session.save_path）下的所有会话文件，并根据另外一个全局变量session.gc_maxlifetime的多少来判断哪些session已经过期（“当前时间”与“会话文件的atime或者mtime”之间的差大于gc_maxlifetime：过期），并删除这些过期的session
如果你在一个session启动后，长时间没有任何交互操作（譬如，不停地码字，没有提交或者保存为草稿），那么你的保存在后台的会话文件将得不到机会被修改或者访问，在gc_maxlifetime（缺省值1440秒＝24分钟）时间后，它有可能因失效而被清理，这以后你再提交，就会因为会话失效而报错

由此可见，gc_maxlifetime设置为24分钟，对于写某些文章来说还不够。这是一个原因，另外，session.save_path的缺省路径在linux上是/tmp，很少有程序会修改这个设置。如果这台服务器上有多个虚拟主机，那么，/tmp目录下会存放许多不同session_name的会话文件。糟糕的是，php的GC不区分会话归属，它会根据它取得的gc_maxlifetime来清理这个目录下的所有过期session文件。

据以上分析，解决方案是：UTBLOG在.htaccess文件内添加了一条语句，将session.gc_maxlifetime的local value扩大为14400（4小时），同时在后台将session.save_path设置为/tmp/utblog，这样，utblog的会话文件就不受其他网站干扰了，而4小时的失效时间，我想，无论如何应该够用了。

测试下来，一切如我所愿。

另，如果直接改动/etc/php.ini当然也可以。如果没有权限改动php.ini，也没有权限改动apache的conf文件，.htaccess被禁止，那么直接修改plog的sessionmanager.class.php文件，在session_start行前添加ini_alter(“session.gc_maxlifetime”, 14400)亦可。plog结构良好，只有这一处调用session_start，所以也只有这一处需要修改。我在本地做过测试，可以工作。

session.gc_probability integer
    session.gc_probability 与 session.gc_divisor 合起来用来管理 gc（garbage collection 垃圾回收）进程启动的概率。默认为 1。详见 session.gc_divisor。 
session.gc_divisor integer
    session.gc_divisor 与 session.gc_probability 合起来定义了在每个会话初始化时启动 gc（garbage collection 垃圾回收）进程的概率。此概率用 gc_probability/gc_divisor 计算得来。例如 1/100 意味着在每个请求中有 1% 的概率启动 gc 进程。session.gc_divisor 默认为 100。 
session.gc_maxlifetime integer
    session.gc_maxlifetime 指定过了多少秒之后数据就会被视为“垃圾”并被清除。

    Note:
    如果不同的脚本具有不同的 session.gc_maxlifetime 数值但是共享了同一个地方存储会话数据，则具有最小数值的脚本会清理数据。此情况下，与 session.save_path 一起使用本指令。 

    Note: 
    如果使用默认的基于文件的会话处理器，则文件系统必须保持跟踪访问时间（atime）。Windows FAT 文件系统不行，因此如果必须使用 FAT 文件系统或者其他不能跟踪 atime 的文件系统，那就不得不想别的办法来处理会话数据的垃圾回收。自 PHP 4.2.3 起用 mtime（修改时间）来代替了 atime。因此对于不能跟踪 atime 的文件系统也没问题了。