我参与了整个无Cookie域名/ CDN的事情,我了解如何将请求的Cookie发送到www.yourdomain.com,同时设置一个单独的域名,例如cdn.yourdomain.com,以保留不必要的Cookie被发送可以帮助表现。
我很好奇的是,如果使用PHP的本机会话对性能产生负面影响,如果是,如何?我知道会话密钥是在cookie中跟踪的,这很小,所以看起来很好。
我被提示问这个问题,因为过去我编写了我的网络应用程序,并在$_SESSION
变量中存储了一小部分用户的活动数据,首选项和身份验证信息。但是,我注意到一些流行的Web应用程序,如Wordpress,根本不使用$_SESSION
。但是会话易于使用并且看起来相当安全,特别是如果您将其与跟踪用户代理/ IP更改结合起来以防止会话劫持。那么为什么Wordpress和其他网络应用程序不使用php的会话?我还应该停止使用会话吗?
另外,我还要澄清一下,我确实意识到服务器必须加载会话数据来处理页面请求,但这不是我在这里问的问题。我的问题是它是否/如何影响网络性能,特别是关于发送/接收的报头。例如,使用会话是否会阻止网站上的页面或图像从浏览器的缓存中提供? PHPSESID cookie是唯一要发送的附加标头吗?这些事情。
答案 0 :(得分:3)
$_SESSION
的标准存储是文件系统,每个会话只有一个文件。这需要付出代价:
使用cookie存储会话数据(Wordpress,Codeigniter),竞争条件相同,但锁定不是内在的,但浏览器可能会在cookie管理中锁定。
使用Cookie的缺点是,您无法存储那么多数据,并且每次请求和响应都会传递数据。这也可能引发安全问题。窃取cookie并获得数据。如果它是加密的,攻击者可以尝试解密它以获取存储在其中的数据。
Wordpress的历史原因是该平台从未使用过PHP会话。根项目始于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。但是,如果需要,您将能够切换到基于数据库的会话 - 无需重写应用程序的大部分内容。
答案 1 :(得分:1)
我不是100%确信这是事实,但是在PHP中避免内置$ _SESSION机制的一个原因是,如果要在高可用性Web场方案中部署Web应用程序。
因为PHP中的默认会话行为是将进程中的会话对象存储在内存中,所以很难(如果不是不可能)让多个服务器处理来自同一用户的请求。如果您希望在Web场环境中部署Web应用程序,您将只有这样,您可以使用许多PHP Web服务器处理请求以平衡负载。
因此,虽然进程内会话状态通常比基于数据库的解决方案快得多,但后者在您需要处理大量请求并为使用Web服务器场环境的容量提供服务时是有利的。 / p>
正如我在开始时所说,我不是100%确定PHP是否支持将会话状态提供程序配置为数据库或会话状态服务器,而不是进程内默认值。