搜档网
当前位置:搜档网 › Session详解

Session详解

Session详解
Session详解

Session详解

一、术语session

在我的经验里,session那个词被滥用的程度大概仅次于transaction,更加有味的是transaction与session在某些语境下的含义是相同的。

session,中文经常翻译为会话,其本来的含义是指有始有终的一系列动作/消息,比如打电话时从拿起电话拨号到挂断电话这中间的一系列过程能够称之为一个 session.有时候我们能够看到如此的话“在一个扫瞄器会话期间,……”,那个地点的会话一词用的确实是其本义,是指从一个扫瞄器窗口打开到关闭那个期间①。最混乱的是“用户(客户端)在一次会话期间”如此一句话,它可能指用户的一系列动作(一般情况下是同某个具体目的相关的一系列动作,比如从登录到选购商品到结账登出如此一个网上购物的过程,有时候也被称为一个transaction),然而有时候也可能仅仅是指一次连接,也有可能是指含义①,其中的差不只能靠上下文来推断②。

然而当session一词与网络协议相关联时,它又往往隐含了“面向连接”和/或“保持状态”如此两个含义,“面向连

接”指的是在通信双方在通信之前要先建立一个通信的渠道,比如打电话,直到对方接了电话通信才能开始,与此相对的是写信,在你把信发出去的时候你并不能确认对方的地址是否正确,通信渠道不一定能建立,但对发信人来讲,通信差不多开始了。“保持状态”则是指通信的一方能够把一系列的消息关联起来,使得消息之间能够互相依靠,比如一个服务员能够认出再次光临的老顾客同时记得上次那个顾客还欠店里一块钞票。这一类的例子有“一个TCP session”或者“一个POP3 session”③。

而到了web服务器蓬勃进展的时代,session在web开发语境下的语义又有了新的扩展,它的含义是指一类用来在客户端与服务器之间保持状态的解决方案④。有时候session也用来指这种解决方案的存储结构,如“把xxx保存在session 里”

⑤。由于各种用于web开发的语言在一定程度上都提供了对这种解决方案的支持,因此在某种特定语言的语境下,session也被用来指代该语言的解决方案,比如经常把Java里提供的javax.servlet.http.HttpSession简称为session⑥。

鉴于这种混乱已不可改变,本文中session一词的运用也会依照上下文有不同的含义,请大伙儿注意分辨。

在本文中,使用中文“扫瞄器会话期间”来表达含义①,使用“session机制”来表达含义④,使用“session”表达含义⑤,使用具体的“HttpSession”来表达含义⑥

二、HTTP协议与状态

保持HTTP 协议本身是无状态的,这与HTTP协议本来的目的是相符的,客户端只需要简单的向服务器请求下载某些文件,不管是客户端依旧服务器都没有必要纪录彼此过去的行为,每一次请求之间差不多上独立的,好比一个顾客和一个自动售货机或者一个一般的(非会员制)大卖场之间的关系一样。

然而聪慧(或者贪心?)的人们专门快发觉假如能够提供一些按需生成的动态信息会使web变得更加有用,就像给有线电视加上点播功能一样。这种需求一方面迫使HTML逐步添加了表单、脚本、DOM等客户端行为,另一方面在服务器端则出现了CGI规范以响应客户端的动态请求,作为传输载体的HTTP协议也添加了文件上载、 cookie这些特性。其中cookie的作用确实是为了解决HTTP协议无状态的缺陷所作出的努力。至于后来出现的session机制则是又一种在客户端与服务器之间保持状态的解决方案。

让我们用几个例子来描述一下cookie和session机制之间的区不与联系。笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠,然而一次性消费5杯咖啡的机会微乎其微,这时就需要某种方式来纪录某位顾客的消费数量。想象一下事实上也无外乎下面的几种方案:1、该店的店员专门厉害,能记住

每位顾客的消费数量,只要顾客一走进咖啡店,店员就明白该如何对待了。这种做法确实是协议本身支持状态。

2、发给顾客一张卡片,上面记录着消费的数量,一般还有个有效期限。每次消费时,假如顾客出示这张卡片,则此次消费就会与往常或以后的消费相联系起来。这种做法确实是在客户端保持状态。

3、发给顾客一张会员卡,除了卡号之外什么信息也不纪录,每次消费时,假如顾客出示该卡片,则店员在店里的纪录本上找到那个卡号对应的纪录添加一些消费信息。这种做法确实是在服务器端保持状态。

由于HTTP协议是无状态的,而出于种种考虑也不希望使之成为有状态的,因此,后面两种方案就成为现实的选择。具体来讲cookie机制采纳的是在客户端保持状态的方案,而session 机制采纳的是在服务器端保持状态的方案。同时我们也看到,由于采纳服务器端保持状态的方案在客户端也需要保存一个标识,因此session机制可能需要借助于cookie机制来达到保存标识的目的,但实际上它还有其他选择。

三、理解cookie机制

cookie机制的差不多原理就如上面的例子一样简单,然而还

有几个问题需要解决:“会员卡”如何分发:“会员卡”的内容;以及客户如何使用“会员卡”。

正统的cookie分发是通过扩展HTTP协议来实现的,服务器通过在HTTP的响应头中加上一行专门的指示以提示扫瞄器按照指示生成相应的cookie.然而纯粹的客户端脚本如JavaScript或者VBScript也能够生成cookie.

而cookie 的使用是由扫瞄器按照一定的原则在后台自动发送给服务器的。扫瞄器检查所有存储的cookie,假如某个cookie所声明的作用范围大于等于将要请求的资源所在的位置,则把该cookie附在请求资源的HTTP请求头上发送给服务器。意思是麦当劳的会员卡只能在麦当劳的店里出示,假如某家分店还发行了自己的会员卡,那么进这家店的时候除了要出示麦当劳的会员卡,还要出示这家店的会员卡。

cookie的内容要紧包括:名字,值,过期时刻,路径和域。

其中域能够指定某一个域比如。https://www.sodocs.net/doc/d42793437.html,,相当于总店招牌,比如宝洁公司,也能够指定一个域下的具体某台机器比如https://www.sodocs.net/doc/d42793437.html,或者https://www.sodocs.net/doc/d42793437.html,,能够用飘柔来做比。

路径确实是跟在域名后面的URL路径,比如/或者/foo 等等,能够用某飘柔专柜做比。

路径与域合在一起就构成了cookie的作用范围。

假如不设置过期时刻,则表示那个cookie的生命期为扫瞄器会话期间,只要关闭扫瞄器窗口,cookie就消逝了。这种生命期为扫瞄器会话期的 cookie被称为会话cookie.会话cookie一般不存储在硬盘上而是保存在内存里,因此这种行为并不是规范规定的。假如设置了过期时刻,扫瞄器就会把cookie 保存到硬盘上,关闭后再次打开扫瞄器,这些cookie仍然有效直到超过设定的过期时刻。

存储在硬盘上的cookie 能够在不同的扫瞄器进程间共享,比如两个IE窗口。而关于保存在内存里的cookie,不同的扫瞄器有不同的处理方式。关于IE,在一个打开的窗口上按Ctrl-N(或者从文件菜单)打开的窗口能够与原窗口共享,而使用其他方式新开的IE进程则不能共享差不多打开的窗口的内存cookie;关于 Mozilla Firefox0.8,所有的进程和标签页都能够共享同样的cookie.一般来讲是用javascript的window.open 打开的窗口会与原窗口共享内存cookie.扫瞄器关于会话cookie的这种只认cookie不认人的处理方式经常给采纳session机制的web应用程序开发者造成专门大的困扰。

下面确实是一个goolge设置cookie的响应头的例子HTTP/1.1 302 FoundLocation:

https://www.sodocs.net/doc/d42793437.html,/intl/zh-CN/Set-Cookie:

PREF=ID=0565f77e132de138:NW=1:TM=1098082649:

LM=1098082649:S=KaeaCFPo49RiA_d8; expires=Sun,

17-Jan-2038 19:14:07 GMT; path=/;

domain=https://www.sodocs.net/doc/d42793437.html,Content-Type: text/html

这是使用HTTPLook那个HTTP Sniffer软件来俘获的HTTP通讯纪录的一部分

扫瞄器在再次访问goolge的资源时自动向外发送cookie

用Firefox能够专门容易的观看现有的cookie的值使用HTTPLook配合Firefox能够专门容易的理解cookie的工作原理。

IE也能够设置在同意cookie前询问

四、理解session机制

session机制是一种服务器端的机制,服务器使用一种类似于散列表的结构(也可能确实是使用散列表)来保存信息。

当程序需要为某个客户端的请求创建一个session的时候,服务器首先检查那个客户端的请求里是否已包含了一个session标识 - 称为 session id,假如已包含一个session id 则讲明往常差不多为此客户端创建过session,服务器就按照session id把那个 session检索出来使用(假如检索不到,可能会新建一个),假如客户端请求不包含session id,则为此客户端创建一个session同时生成一个与此session相关联的session id,session id的值应该是一个既可不能重复,又不容易被找到规律以仿造的字符串,那个 session id将被在本次响应中返回给客户端保存。

保存那个session id的方式能够采纳cookie,如此在交互过程中扫瞄器能够自动的按照规则把那个标识发挥给服务器。一般那个cookie的名字差不多上类似于SEEESIONID,而。比如weblogic关于web应用程序生成的cookie,JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764,它的名字确实是 JSESSIONID.

由于cookie能够被人为的禁止,必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写,确实是把session id直接附加在URL路径的后面,附加方式也有两种,一种是作为URL路径的附加信息,表现形式为http://……/xxx;jsessionid=

ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!

-145788764另一种是作为查询字符串附加在URL后面,表现形式为http:// (xxx)

jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ 99zWpBng!-145788764这两种方式关于用户来讲是没有区不的,只是服务器在解析的时候处理的方式不同,采纳第一种方式也有利于把session id的信息和正常程序参数区分开来。

为了在整个交互过程中始终保持状态,就必须在每个客户端可能请求的路径后面都包含那个session id.

另一种技术叫做表单隐藏字段。确实是服务器会自动修改表单,添加一个隐藏字段,以便在表单提交时能够把session id传递回服务器。比如下面的表单

在被传递给客户端之前将被改写成

name="testform" action="/xxx">

value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zW pBng!-145788764">

这种技术现在已较少应用,笔者接触过的专门古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。

实际上这种技术能够简单的用对action应用URL重写来代替。

在谈论session机制的时候,常常听到如此一种误解“只要关闭扫瞄器,session就消逝了”。事实上能够想象一下会员卡的例子,除非顾客主动对店家提出销卡,否则店家绝对可不能轻易删除顾客的资料。对session来讲也是一样的,除非程序通知服务器删除一个session,否则服务器会一直保留,程序一般差不多上在用户做log off的时候发个指令去删除session.然而扫瞄器从来可不能主动在关闭之前通知服务器它将要关闭,因此服务器全然可不能有机会明白扫瞄器差不多关闭,之因此会有这种错觉,是大部分session机制都使用会话cookie来保存session id,而关闭扫瞄器后那个 session id就消逝了,再次连接服务器时也就无法找到原来的session.假如服务器设置的cookie被保存到硬盘上,或者使用某种手段改写扫瞄器发出的HTTP请求头,把原来的session id发送给服务器,则再次打开扫瞄器仍然能够找到原来的session.

恰恰是由于关闭扫瞄器可不能导致session被删除,迫使服务器为seesion设置了一个失效时刻,当距离客户端上一次使用session的时刻超过那个失效时刻时,服务器就能够认为客户端差不多停止了活动,才会把session删除以节约存储空间。

五、理解javax.servlet.http.HttpSession

HttpSession是Java平台对session机制的实现规范,因为它仅仅是个接口,具体到每个web应用服务器的提供商,除了对规范支持之外,仍然会有一些规范里没有规定的细微差异。那个地点我们以BEA的Weblogic Server8.1作为例子来演示。

首先,Weblogic Server提供了一系列的参数来操纵它的HttpSession的实现,包括使用cookie的开关选项,使用URL 重写的开关选项,session持久化的设置,session失效时刻的设置,以及针对cookie的各种设置,比如设置cookie的名字、路径、域, cookie的生存时刻等。

一般情况下,session差不多上存储在内存里,当服务器进程被停止或者重启的时候,内存里的session也会被清空,假如设置了session的持久化特性,服务器就会把session保存到硬盘上,当服务器进程重新启动或这些信息将能够被再次使用, Weblogic Server支持的持久性方式包括文件、数据库、客户端cookie保存和复制。

复制严格讲来不算持久化保存,因为session实际上依旧保存在内存里,只是同样的信息被复制到各个cluster内的服务器进程中,如此即使某个服务器进程停止工作也仍然能够从其他进程中取得session.

相关主题