会话跟踪

HTTP是“无状态”协议:客户程序每次读取Web页面,都打开到Web服务器的单独的连接,并且,服务器也不自动维护客户的上下文信息。即使那些支持持续性(继续使用)HTTP连接的服务器,尽管多个客户请求连续发生且间隔很短时它们会保持socket打开,但是,它们也没有维持上下文信息的内建支持。


1. cookie

使用cookie存储会话的ID,在后续的连接中,取出当前的会话ID,并使用这个ID从服务器上的查找表(lookup table)中提取出会话的相关信息。

两个表:将会话ID与用户关联起来的表存储用户具体数据的表

会话跟踪_第1张图片
使用cookie处理会话

然后,在接下来的请求中,服务器可以使用globalTable散列表,将来自JSESSIONID cookie中的会话ID与sessionInfo散列表中的用户具体数据关联起来。


2. URL重写

采用这种方式时,客户程序在每个URL的尾部添加一些额外数据。这些数据标识当前的会话,服务器将这个标识符与它存储的用户相关数据关联起来。

即使浏览器不支持cookie或在用户禁用cookie的情况下,URL重写也能够工作。

但是,URL重写具有cookie所具有的同样缺点,也就是说,服务器端程序要做许多简单但是冗长乏味的处理任务。

每个引用你的站点的URL,以及那些返回给用户的URL(即使通过间接手段,比如服务器重定向中的Location字段)都要添加额外的信息。这种限制意味着,在你的站点上不能有任何静态HTML页面(至少静态页面中不能有任何链接到站点动态页面的链接)。因此,每个页面都必须使用Servlet或JSP动态生成。即使所有的页面都动态生成,如果用户离开了会话并通过书签或链接再次回来,会话的信息也会丢失,因为存储下来的链接含有错误的标识信息。


3. 隐藏的表单域

这个隐藏域可以用来存储有关会话的信息,但它的主要缺点是:仅当每个页面都是由表单提交而动态生成时,才能使用这种方法。

单击常规的()超文本链接并不产生表单提交,因此隐藏的表单域不能支持通常的会话跟踪,只能用于一系列特定的操作中。


4. Servlet中的会话跟踪

Servlet提供一种出色的会话跟踪解决方案:HttpSession API。这个高层接口构筑在cookie或URL重写之上。所有的服务器都需要支持使用cookie的会话跟踪,大多数服务器提供一项设置,可以全局地切换到URL重写。


(完)

你可能感兴趣的:(会话跟踪)