Servlet学习笔记(五)------ session(java中)

本文参考多篇文章,只提取了个人觉得目前有用的地方。文末贴了链接,有兴趣的朋友可以去阅读。


1.HTTP协议和状态保持

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

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

  让我们用几个例子来描述一cookiesession机制之间的差别和联系。笔者原来常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠,然而一次性消费5杯咖啡的机会微乎其微,这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案:

  1、该店的店员非常厉害,能记住每位顾客的消费数量,只要顾客一走进咖啡店,店员就知道该怎么对待了。这种做法就是协议本身支持状态。

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

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

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


2.理解cookie机制 

  cookie机制的基本原理就如上面的例子相对简单,不过更有几个问题需要解决:会员卡怎么分发;会员卡的内容;及客户怎么使用会员卡

  正统的cookie分发是通过扩展HTTP协议来实现的,服务器通过在HTTP的响应头中加上一行特别的指示以提示浏览器按照指示生成相应的cookie。然而纯粹的客户端脚本如JavaScriptVBScript也能生成cookie

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

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

  其中域能指定某一个域比如.google.com,相当于总店招牌,比如宝洁公司,也能指定一个域下的具体某台机器比如www.google.comfroogle.google.com,能用飘柔来做比。

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

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

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

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

  下面就是个goolge设置cookie的响应头的例子

HTTP/1.1 302 Found
Location: http://www.google.com/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=.google.com
Content-Type: text/html


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

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

  使用Firefox能非常容易的观察现有的cookie的值

  使用HTTPLook配合Firefox能非常容易的理解cookie的工作原理。

  IE也能设置在接受cookie前询问

  这是个询问接受cookie的对话框。


3、理解session机制


3.1 session的工作方式。


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

  当程式需要为某个客户端的请求创建一个session的时候,服务器首先检查这个客户端的请求里是否已包含了一个session标识 - 称为session id如果已包含一个session id则说明以前已为此客户端创建过session服务器就按照session id把这个session检索出来使用(如果检索不到,可能会新建一个),如果客户端请求不包含session id则为此客户端创建一个session并且生成一个和此session相关联的session idsession id的值应该是个既不会重复,session id将被在本次响应中返回给客户端保存。

  保存这个session id的方式能采用cookie,这样在交互过程中浏览器能自动的按照规则把这个标识发挥给服务器。一般这个cookie的名字都是类似于SEEESIONID,而。比如weblogic对于web应用程式生成的cookieJSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764,他的名字就是JSESSIONID


3.2 cookie被禁止时URL的重写

  由于cookie能被人为的禁止,必须有其他机制以便在cookie被禁止时仍然能够把session id传递回服务器。经常被使用的一种技术叫做URL重写,就是把session id直接附加在URL路径的后面,附加方式也有两种,一种是作为URL路径的附加信息,表现形式为http://...../xxx;jsessionid=ByOK ... 99zWpBng!-145788764另一种是作为查询字符串附加在URL后面,表现形式为http://...../xxx?jsessionid=ByOK ... 99zWpBng!-145788764
这两种方式对于用户来说是没有差别的,只是服务器在解析的时候处理的方式不同,采用第一种方式也有利于把session id的信息和正常程式参数区分开来。(具体实现我还没懂怎么重写)

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

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

  这种技术目前已较少应用,笔者接触过的非常古老的iPlanet6(SunONE应用服务器的前身)就使用了这种技术。实际上这种技术能简单的用对action应用URL重写来代替。


3.3 关于是否关闭浏览器session就自动消失的讨论。


  在谈论session机制的时候,常常听到这样一种误解只要关闭浏览器,session就消失了其实能想象一下会员卡的例子,除非顾客主动对店家提出销卡,否则店家绝对不会轻易删除顾客的资料。对session来说也是相同的,除非程式通知服务器删除一个session,否则服务器会一直保留,程式一般都是在用户做log off的时候发个指令去删除session。然而浏览器从来不会主动在关闭之前通知服务器他将要关闭,因此服务器根本不会有机会知道浏览器已关闭,之所以会有这种错觉,是大部分session机制都使用会话cookie来保存session id,而关闭浏览器后这个session id就消失了,再次连接服务器时也就无法找到原来的session。如果服务器设置的cookie被保存到硬盘上,或使用某种手段改写浏览器发出的HTTP请求头,把原来的session id发送给服务器,则再次打开浏览器仍然能够找到原来的session

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


4、HttpSession常见问题



  1session在何时被创建

  一个常见的误解是以为session在有客户端访问时就被创建,然而事实是直到某server端程式调用HttpServletRequest.getSession(true)这样的语句时才被创建,注意如果JSP没有显示的使用 关闭session,则JSP文件在编译成Servlet时将会自动加上这样一条语句HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的session对象的来历。

  由于session会消耗内存资源,因此,如果不打算使用session,应该在所有的JSP中关闭他。

  2session何时被删除

  综合前面的讨论,session在下列情况下被删除a.程式调用HttpSession.invalidate();b.距离上一次收到客户端发送的session id时间间隔超过了session的超时设置;c.服务器进程被停止(非持久session

  3怎么做到在浏览器关闭时删除session

  严格的讲,做不到这一点。能做一点努力的办法是在所有的客户端页面里使用javascript代码window.oncolose来监视浏览器的关闭动作,然后向服务器发送一个请求来删除session。不过对于浏览器崩溃或强行杀死进程这些非常规手段仍然无能为力。

  4有个HttpSessionListener是怎么回事

  你能创建这样的listener去监视session的创建和销毁事件,使得在发生这样的事件时你能做一些相应的工作。注意是session的创建和销毁动作触发listener,而不是相反。类似的和HttpSession有关的listener更有HttpSessionBindingListenerHttpSessionActivationListenerHttpSessionAttributeListener 

5
存放在session中的对象必须是可序列化的吗

  不是必需的。需求对象可序列化只是为了session能够在集群中被复制或能够持久保存或在必要时server能够暂时把session交换出内存。在Weblogic Serversession中放置一个不可序列化的对象在控制台上会收到一个警告。我所用过的某个iPlanet版本如果session中有不可序列化的对象,在session销毁时会有一个Exception,非常奇怪。

  6怎么才能正确的应付客户端禁止cookie的可能性

  对所有的URL使用URL重写,包括超链接,formaction,和重定向的URL,具体做法参见[6]
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

  7开两个浏览器窗口访问应用程式会使用同一个session还是不同的session

  参见第三小节对cookie的讨论,对session来说是只认id不认人,因此不同的浏览器,不同的窗口打开方式及不同的cookie存储方式都会对这个问题的答案有影响。

  8怎么防止用户打开两个浏览器窗口操作导致的session混乱

(这个也是我没有完全懂的地方,因为我还不知道令牌是什么)


  这个问题和防止表单多次提交是类似的,能通过设置客户端的令牌来解决。就是在服务器每次生成一个不同的id返回给客户端,同时保存在session里,客户端提交表单时必须把这个id也返回服务器,程式首先比较返回的id和保存在session里的值是否一致,如果不一致则说明本次操作已被提交过了。能参看《J2EE核心模式》关于表示层模式的部分。需要注意的是对于使用javascript window.open打开的窗口,一般不设置这个id,或使用独立的id,以防主窗口无法操作,建议不要再window.open打开的窗口里做修改操作,这样就能不用设置。

  9为什么在Weblogic Server中改动session的值后要重新调用一次session.setValue
做这个动作主要是为了在集群环境中提示Weblogic Server session中的值发生了改动,需要向其他服务器进程复制新的session值。

  10为什么session不见了

  排除session正常失效的因素之外,服务器本身的可能性应该是微乎其微的,虽然笔者在iPlanet6SP1加若干补丁的Solaris版本上倒也遇见过;浏览器插件的可能性次之,笔者也遇见过3721插件造成的问题;理论上防火墙或代理服务器在cookie处理上也有可能会出现问题。

  出现这一问题的大部分原因都是程式的错误,最常见的就是在一个应用程式中去访问另外一个应用程式。我们在下一节讨论这个问题。

5.session实现原理

5.1、服务器是如何实现一个session为一个用户浏览器服务的?

   服务器创建session出来后,会把session的id号,以cookie的形式回写给客户机,这样,只要客户机的浏览器不关,再去访问服务器时,都会带着session的id号去,服务器发现客户机浏览器带session id过来了,就会使用内存中与之对应的session为之服务。可以用如下的代码证明:

复制代码
 1 package xdp.gacl.session;
 2 
 3 import java.io.IOException;
 4 import javax.servlet.ServletException;
 5 import javax.servlet.http.HttpServlet;
 6 import javax.servlet.http.HttpServletRequest;
 7 import javax.servlet.http.HttpServletResponse;
 8 import javax.servlet.http.HttpSession;
 9 
10 public class SessionDemo1 extends HttpServlet {
11 
12     public void doGet(HttpServletRequest request, HttpServletResponse response)
13             throws ServletException, IOException {
14 
15         response.setCharacterEncoding("UTF=8");
16         response.setContentType("text/html;charset=UTF-8");
17         //使用request对象的getSession()获取session,如果session不存在则创建一个
18         HttpSession session = request.getSession();
19         //将数据存储到session中
20         session.setAttribute("data", "孤傲苍狼");
21         //获取session的Id
22         String sessionId = session.getId();
23         //判断session是不是新创建的
24         if (session.isNew()) {
25             response.getWriter().print("session创建成功,session的id是:"+sessionId);
26         }else {
27             response.getWriter().print("服务器已经存在该session了,session的id是:"+sessionId);
28         }
29     }
30 
31     public void doPost(HttpServletRequest request, HttpServletResponse response)
32             throws ServletException, IOException {
33         doGet(request, response);
34     }
35 }
复制代码

  第一次访问时,服务器会创建一个新的sesion,并且把session的Id以cookie的形式发送给客户端浏览器,如下图所示:

  

  点击刷新按钮,再次请求服务器,此时就可以看到浏览器再请求服务器时,会把存储到cookie中的session的Id一起传递到服务器端了,如下图所示:

  

  我猜想request.getSession()方法内部新创建了Session之后一定是做了如下的处理

复制代码
1 //获取session的Id
2 String sessionId = session.getId();
3 //将session的Id存储到名字为JSESSIONID的cookie中
4 Cookie cookie = new Cookie("JSESSIONID", sessionId);
5 //设置cookie的有效路径
6 cookie.setPath(request.getContextPath());
7 response.addCookie(cookie);
复制代码

6、session对象的创建和销毁时机

6.1、session对象的创建时机

  在程序中第一次调用request.getSession()方法时就会创建一个新的Session,可以用isNew()方法来判断Session是不是新创建的

范例:创建session

复制代码
 1 //使用request对象的getSession()获取session,如果session不存在则创建一个
 2 HttpSession session = request.getSession();
 3 //获取session的Id
 4 String sessionId = session.getId();
 5 //判断session是不是新创建的
 6 if (session.isNew()) {
 7     response.getWriter().print("session创建成功,session的id是:"+sessionId);
 8 }else {
 9     response.getWriter().print("服务器已经存在session,session的id是:"+sessionId);
10 }
复制代码

6.2、session对象的销毁时机

  session对象默认30分钟没有使用,则服务器会自动销毁session,在web.xml文件中可以手工配置session的失效时间,例如:

复制代码
 1 <?xml version="1.0" encoding="UTF-8"?>
 2 <web-app version="2.5" 
 3     xmlns="http://java.sun.com/xml/ns/javaee" 
 4     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 5     xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
 6     http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">
 7   <display-name></display-name>
 8   
 9   <welcome-file-list>
10     <welcome-file>index.jsp</welcome-file>
11   </welcome-file-list>
12 
13   <!-- 设置Session的有效时间:以分钟为单位-->
14     <session-config>
15         <session-timeout>15</session-timeout>
16     </session-config>
17 
18 </web-app>
复制代码

  当需要在程序中手动设置Session失效时,可以手工调用session.invalidate方法,摧毁session。

1 HttpSession session = request.getSession();
2 //手工调用session.invalidate方法,摧毁session
3 session.invalidate();



参考:http://blog.sina.com.cn/s/blog_670b6d880101deff.html   全面的介绍了session的相关内容

参考:https://www.cnblogs.com/xdp-gacl/p/3855702.html   代码演示




  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值