PHP会话,无cookie域和性能

>当两个请求访问同一个会话时,一个请求将胜过另一个请求,另一个请求需要等到第一个请求完成.由文件锁定控制的竞争条件.

使用cookie存储会话数据(WordPress,Codeigniter),竞争条件相同,但锁定不是内在的,但浏览器可能会在cookie管理中锁定.

使用cookie的缺点是,您无法存储那么多数据,并且每次请求和响应都会传递数据.这也可能引发安全问题.窃取cookie并获得数据.如果它是加密的,攻击者可以尝试解密它以获取存储在其中的数据.

WordPress的历史原因是该平台从未使用过PHP Sessions.根项目始于2000年左右,它在2002年和2004年引起了很多关注.由于会话处理仅适用于PHP 4,因此PHP 3更受欢迎.

稍后,当$_SESSION可用时,应用程序的主要设计已经完成,并且它可以工作.接下来,在2004/2005年,wordpress决定开始商业多博客托管服务.这就需要跨服务器扩展应用程序,而cookie数据库看起来比使用$_SESSION实现更容易进行会话/用户处理.事实上,这很简单,只是有效,所以从来没有必要改变它.

对于Codeigniter,我不能说太多.我知道它默认将所有会话信息存储在cookie中.因此会话只是cookie的另一个名称.可选地,它可以加密,但这需要配置.据说IIRC已经完成,因为“大多数用户不需要会话”.对于那些需要的人,有一个数据库后端(需要额外的配置),因此用户可以在他们的应用程序中透明地从cookie更改为数据库存储.还有一个新的实现,允许您更改到您喜欢的任何商店,例如本地PHP会话也是如此.这是通过所谓的驱动程序完成的.

但是,这并不意味着你现在无法实现基于$_SESSION的相同功能.你可以用任何你喜欢的东西(甚至是cookies :)替换商店,并且它的PHP实现应该被封装在一个好的程序设计中.

完成后,您可以实现一个商店,您可以更好地控制锁定(例如数据库),并且可以在不支持粘性会话的负载平衡基础架构中跨服务器工作.

WordPress是一个很好的例子,自己实现的会话处理与PHP提供的完全无关.这意味着轮子已被重新发明.从今天开始,我不会将他们的设计明确地称为创新,因此它在一个非常特定的环境中完全满足了一个非常具体的需求,只有了解项目根源才能理解.

Codeigniter可能领先一步(在界面意义上),因为它为会话提供某种(不稳定的)接口,并且可以用你喜欢的任何实现替换它.这对新开发者来说要好得多,但它也有点重新发明轮子,因为PHP已经开箱即用了.

在应用程序设计中,您可以做的最好的事情是使实现独立于系统需求,从而使会话数据的存储机制独立于程序流的其余部分. PHP提供了一个非常直接的接口,$_SESSION数组和会话配置.

由于$_SESSION是一个超全局数组,您可能希望阻止应用程序直接访问它,因为这会引入全局状态.因此,在一个好的设计中,你将拥有一个接口,以便能够完全脱离超全局.

做了这个,再加上商店加配置的抽象(例如,所有在一个会话依赖容器中),您应该能够根据自己的喜好在任意数量的服务器上扩展和维护您的应用程序.如果您认为这是适合您的话,那么您的实现就可以使用cookie.但是,如果需要,您将能够切换到基于数据库的会话 – 无需重写应用程序的大部分内容.