Session是服务器为每个访问这个服务器的客户端用户创建的一个容器。这个容器中存储的数据能够在多个request之间实现共享。而且，这个容器只属于当前这个用户。

Session是怎么标识每一个用户的

表面上，我们说Session容器是属于某一个用户。其实在会话过程中，只有客户端(浏览器)和服务器两个角色。所以，Session容器标识的不是用户，而是当前用户正在使用的浏览器。浏览器与服务器交流是通过给服务器发送请求实现的，浏览器的每次请求中如果都有一个相同的标记用来标记session。服务器就能够识别这个用户了。
这个标记叫做JSESSIONID。我们重新演示，cookie的setPath练习，发现服务器启动后，浏览器的每次请求都会携带一个name属性值为"JSESSIONID"的cookie，这个cookie的值在每次请求过程中都是相同的。
Session的作用

为每个访问服务器的用户创建一个存储数据的容器；

容器中的数据在多个请求之间共享；
获得Session对象API

Session容器的创建，调用的方法是：request.getSession()。
//获取Session容器对象（创建session对象）
   HttpSession session = request.getSession();
   System.out.println(session);

session常用API

实践：

需求：

在第一个Servlet中往Servlet中存储数据；
在另外两个Servlet中获取session和session中存储的值，分别打印session和值；

//往session中设置值
@WebServlet("/sessionone")
public class SessionOneServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        doGet(request, response);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        //在session中存储值
        //获取session
        HttpSession session = request.getSession();
        //储存值
        session.setAttribute("session","sessionvlaue");
    }
}

//从session中取值
@WebServlet("/sessontwo")
public class SessionTwoServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        doGet(request, response);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        //获取session中存储的值
        //获取session
        HttpSession session = request.getSession();
        String session1 = (String) session.getAttribute("session");
        System.out.println("session1 = " + session1);
    }
}

Session的生命周期

当客户端浏览器第一次访问服务器时，服务器默认为每个浏览器创建不同的HttpSession对象。我们可以使用request.getSession()方法来获得HttpSession对象。
当第一次执行 request.getSession()时，有session对象就返回创建的session，没有session就创建session对象。后续的request.getSession()只能获取已创建的session。
Session销毁

方式一：时间超出了session的存活时间

session的默认存活时间是30分钟，在tomcat的全局配置文件web.xml中。(路径：tomcat/config/web.xml)

我们可以在web.xml中自己设置这个存活时间。我们设置的这个时间会覆盖原来的存活时间。
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://java.sun.com/xml/ns/javaee"
           xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
           xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
		  http://java.sun.com/xml/ns/javaee/web-app_3_1.xsd"
           version="3.1">
    <!--将session的存活时间设置成1-->
    <session-config>
        <session-timeout>1</session-timeout>
    </session-config>
</web-app>

//获取session
        HttpSession session = request.getSession();
        //打印session和sessionId
        System.out.println("session="+session+";sessionId="+session.getId());

注意： Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session"活跃（active）"了一次。
方式二：在Servlet中手动销毁

手动销毁session，调用的方法是：session.invalidate()方法；
 //可以删除session
        HttpSession session = request.getSession();//可以获取session
        System.out.println(session.getId());

        session.invalidate();//session被销毁了

浏览器关闭后，session持久化方案

通过上面的例子我们发现，浏览器关闭后，JSESSIONID就消失了，再次访问的时候又重新创建了一个新的session对象。这样，是比较消耗资源的。

session之所以重新创建是因为，浏览器关闭后JESSIONID这个cookie消失了。所以，就不能够在标识这个session了。如果能够让cookie不消失（或者存活时间长点）就能够在很长一段时间内把这个标识发送给Servlet了。此时Servlet就能够找到之前创建的session对象了。

【实现方案】

在servlet中手动创建JESSIONID；

手动设置JESSIONID的存活时间；

将JESSIONID响应给浏览器；
@WebServlet("/chi")
public class ChiServlet extends HttpServlet {
    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        doGet(request, response);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        //实现持久化session
        HttpSession session = request.getSession();
        //获取sessionid
        String id = session.getId();

        Cookie cookie = new Cookie("JSESSIONID",id);
        //是cookie持久化
        cookie.setMaxAge(60*30);

        //响应回浏览器
        response.addCookie(cookie);
    }
}

Servlet作用域总结

ServletContext域：

一个WEB应用（项目）对应一个ServletContext，这个对象中保存的数据正在整个WEB项目中都有效；

创建：服务器启动的时候；
销毁：服务器关闭或项目移除后；


HttpSession：

一次会话给客户端（浏览器）创建一个session。这个对象中保存的数据，一次会话（多次请求）内数据有效；

创建：服务器第一次调用getSession()的时候；
销毁：

服务器非正常关闭（正常关闭：Session被序列化）；
Session过期了：默认存活时间30分钟；
手动调用session的invalidate()方法；




HttpServletRequest：

一次请求创建一个request。这个对象中保存的数据，一次请求（请求链）内数据有效；

创建：客户端向服务器发送一次请求；
销毁：服务器为这次请求做出响应之后，销毁request；



【API操作】操作三个作用域对象的API

存储数据：setAttribute(name,value);
获得数据：getAttribute(name);
删除数据：removeAttribute(name)；

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

开发工具与关键技术：Java，HTTP协议，session原理

撰写时间：2019-06-17

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

以下这些大多都是文字表达，没有一一写实际的案例出来演示，但是详细的看一下的话，也就知道什么意思了，文中表达比较通俗。

Web三大概念：cookie，session，application

Session：记录一系列状态

Session与cookie功能效果相同。Session与Cookie的区别在于Session是记录在服务端的，而Cookie是记录在客户端的。

解释session：当访问服务器否个网页的时候，会在服务器端的内存里开辟一块内存，这块内存就叫做session，而这个内存是跟浏览器关联在一起的。这个浏览器指的是浏览器窗口，或者是浏览器的子窗口，意思就是，只允许当前这个session对应的浏览器访问，就算是在同一个机器上新启的浏览器也是无法访问的。而另外一个浏览器也需要记录session的话，就会再启一个属于自己的session

原理：HTTP协议是非连接性的，取完当前浏览器的内容，然后关闭浏览器后，链接就断开了，而没有任何机制去记录取出后的信息。而当需要访问同一个网站的另外一个页面时(就好比如在第一个页面选择购买的商品后，跳转到第二个页面去进行付款)这个时候取出来的信息，就读不出来了。所以必须要有一种机制让页面知道原理页面的session内容。

问题：如何知道浏览器和这个服务器中的session是一一对应的呢？又如何保证不会去访问其它的session呢？

原理解答：就是当访问一个页面的时候给浏览器创建一个独一无二的号码，也给同时创建的session赋予同样的号码。这样就可以在打开同一个网站的第二个页面时获取到第一个页面中session保留下来的对应信息（理解：当访问第二个页面时将号码同时传递到第二个页面。找到对应的session。）。这个号码也叫sessionID，session的ID号码，session的独一无二号码。

session的两种实现方式（也就是传递方式）：第一种通过cookies实现。第二种通过URL重写来实现

第一种方式的理解：就是把session的id 放在cookie里面（为什么是使用cookies存放呢，因为cookie有临时的，也有定时的，临时的就是当前浏览器什么时候关掉即消失，也就是说session本来就是当浏览器关闭即消失的，所以可以用临时的cookie存放。保存再cookie里的sessionID一定不会重复，因为是独一无二的。），当允许浏览器使用cookie的时候，session就会依赖于cookies，当浏览器不支持cookie后，就可以通过第二种方式获取session内存中的数据资源。

第二种方式的理解：在客户端不支持cookie的情况下使用。为了以防万一，也可以同时使用。

如果不支持cookie，必须自己编程使用URL重写的方式实现。

   如何重写URL：通过response.encodeURL()方法

      encodeURL()的两个作用

         第一个作用：转码（说明：转中文的编码，或者一些其他特殊的编码。就好比如网页的链接中存在中文字符，就会转换成为一些百分号或者其他的符号代替。）

第二个作用：URL后面加入sessionID，当不支持cookie的时候，可以使用encodeURL()方法，encodeUTL()后面跟上sessionID，这样的话，在禁用cookie的浏览器中同时也可以使用session了。但是需要自己编程，只要链接支持，想用session就必须加上encodeURL()。

提示：若想程序中永远支持session，那就必须加上encodeURL()，当别人禁用了cookie，一样可以使用session。

简单的代码例子：在没有使用encodeURL()方法前的代码



在使用encodeURL()方法后的代码



看下图，当重写URL 的时候，每一次访问的时候都会将sessionID传过来，传过来了，就没有必要再在cookie里读了。



规则：

如果浏览器支持cookie，创建session多大的时候，会被sessionID保存再cookie里。只要允许cookie，session就不会改变，如果不允许使用cookie，每刷新一次浏览器就会换一个session（因为浏览器以为这是一个新的链接）
	
如果不支持cookie，必须自己编程使用URL重写的方式实现session
	
Session不像cookie一样拥有路径访问的问题，同一个application下的servlet/jsp都可以共享同一个session，前提下是同一个客户端窗口。
Session中的一些常用方法说明

isNew()：是否是新的Session，一般在第一次访问的时候出现

getid()：拿到session，获取ID

getCreationTime()：当前session创建的时间

getLastAccessedTime()：最近的一次访问这个session的时间。

getRrquestedSessionid： 跟随上个网页cookies或者URL传过来的session

isRequestedSessionIdFromCookie()：是否通过Cookies传过来的

isRequestedSessionIdFromURL()：是否通过重写URL传过来的

isRequestedSessionIdValid()：是不是有效的sessionID

其中下面的结果图对应上面的8个方法

  

 

其对应的代码



session有期限：

当一个网站的第一个窗口关掉了，而没有继续接着访问第二个页面，就没有使用到session。那么session会在中断程序后立刻关闭session吗？这个时候session就需要给它保留的时间，当最近一次访问的时候开始计时，每刷新一次重写开始计时。当隔了这么久的时间，没有访问这个session后，对不起，要关闭这个session了。session有过期时间，session什么时候过期，要看配置，

session能干什么：

session就是服务器里面的一块内存，内存里面能放任何东西，只要是名值对就可以了。

session里面的名字永远都是String类型

 

一、术语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的内容主要包括：名字，值，过期时间，路径和域。

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

路径就是跟在域名后面的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 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的对话框。


四、理解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=ByOK ... 99zWpBng!-145788764

另一种是作为查询字符串附加在URL后面，表现形式为http://...../xxx?jsessionid=ByOK ... 99zWpBng!-145788764

这两种方式对于用户来说是没有区别的，只是服务器在解析的时候处理的方式不同，采用第一种方式也有利于把session id的信息和正常程序参数区分开来。

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


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


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


这种技术现在已较少应用，笔者接触过的很古老的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。


cookie生存时间的设置则会影响浏览器生成的cookie是否是一个会话cookie。默认是使用会话cookie。有兴趣的可以用它来试验我们在第四节里提到的那个误解。


cookie的路径对于web应用程序来说是一个非常重要的选项，Weblogic Server对这个选项的默认处理方式使得它与其他服务器有明显的区别。后面我们会专题讨论。


关于session的设置参考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869


六、HttpSession常见问题

（在本小节中session的含义为⑤和⑥的混合）


1、session在何时被创建

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


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


2、session何时被删除

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


3、如何做到在浏览器关闭时删除session

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


4、有个HttpSessionListener是怎么回事

你可以创建这样的listener去监控session的创建和销毁事件，使得在发生这样的事件时你可以做一些相应的工作。注意是session的创建和销毁动作触发listener，而不是相反。类似的与HttpSession有关的listener还有HttpSessionBindingListener，HttpSessionActivationListener和HttpSessionAttributeListener。


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

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


6、如何才能正确的应付客户端禁止cookie的可能性

对所有的URL使用URL重写，包括超链接，form的action，和重定向的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处理上也有可能会出现问题。

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


七、跨应用程序的session共享


常常有这样的情况，一个大项目被分割成若干小项目开发，为了能够互不干扰，要求每个小项目作为一个单独的web应用程序开发，可是到了最后突然发现某几个小项目之间需要共享一些信息，或者想使用session来实现SSO(single sign on)，在session中保存login的用户信息，最自然的要求是应用程序间能够访问彼此的session。


然而按照Servlet规范，session的作用范围应该仅仅限于当前应用程序下，不同的应用程序之间是不能够互相访问对方的session的。各个应用服务器从实际效果上都遵守了这一规范，但是实现的细节却可能各有不同，因此解决跨应用程序session共享的方法也各不相同。


首先来看一下Tomcat是如何实现web应用程序之间session的隔离的，从Tomcat设置的cookie路径来看，它对不同的应用程序设置的cookie路径是不同的，这样不同的应用程序所用的session id是不同的，因此即使在同一个浏览器窗口里访问不同的应用程序，发送给服务器的session id也可以是不同的。


根据这个特性，我们可以推测Tomcat中session的内存结构大致如下。


笔者以前用过的iPlanet也采用的是同样的方式，估计SunONE与iPlanet之间不会有太大的差别。对于这种方式的服务器，解决的思路很简单，实际实行起来也不难。要么让所有的应用程序共享一个session id，要么让应用程序能够获得其他应用程序的session id。


iPlanet中有一种很简单的方法来实现共享一个session id，那就是把各个应用程序的cookie路径都设为/（实际上应该是/NASApp，对于应用程序来讲它的作用相当于根）。


/NASApp


需要注意的是，操作共享的session应该遵循一些编程约定，比如在session attribute名字的前面加上应用程序的前缀，使得setAttribute("name", "neo")变成setAttribute("app1.name", "neo")，以防止命名空间冲突，导致互相覆盖。


在Tomcat中则没有这么方便的选择。在Tomcat版本3上，我们还可以有一些手段来共享session。对于版本4以上的Tomcat，目前笔者尚未发现简单的办法。只能借助于第三方的力量，比如使用文件、数据库、JMS或者客户端cookie，URL参数或者隐藏字段等手段。


我们再看一下Weblogic Server是如何处理session的。


从截屏画面上可以看到Weblogic Server对所有的应用程序设置的cookie的路径都是/，这是不是意味着在Weblogic Server中默认的就可以共享session了呢？然而一个小实验即可证明即使不同的应用程序使用的是同一个session，各个应用程序仍然只能访问自己所设置的那些属性。这说明Weblogic Server中的session的内存结构可能如下


对于这样一种结构，在session机制本身上来解决session共享的问题应该是不可能的了。除了借助于第三方的力量，比如使用文件、数据库、JMS或者客户端cookie，URL参数或者隐藏字段等手段，还有一种较为方便的做法，就是把一个应用程序的session放到ServletContext 中，这样另外一个应用程序就可以从ServletContext中取得前一个应用程序的引用。示例代码如下，


应用程序A

context.setAttribute("appA", session);


应用程序B

contextA = context.getContext("/appA");

HttpSession sessionA = (HttpSession)contextA.getAttribute("appA");


值得注意的是这种用法不可移植，因为根据ServletContext的JavaDoc，应用服务器可以处于安全的原因对于context.getContext("/appA");返回空值，以上做法在Weblogic Server 8.1中通过。


那么Weblogic Server为什么要把所有的应用程序的cookie路径都设为/呢？原来是为了SSO，凡是共享这个session的应用程序都可以共享认证的信息。一个简单的实验就可以证明这一点，修改首先登录的那个应用程序的描述符weblogic.xml，把cookie路径修改为/appA访问另外一个应用程序会重新要求登录，即使是反过来，先访问cookie路径为/的应用程序，再访问修改过路径的这个，虽然不再提示登录，但是登录的用户信息也会丢失。注意做这个实验时认证方式应该使用FORM，因为浏览器和web服务器对basic认证方式有其他的处理方式，第二次请求的认证不是通过session来实现的。具体请参看[7]
 secion 14.8 Authorization，你可以修改所附的示例程序来做这些试验。


八、总结

session机制本身并不复杂，然而其实现和配置上的灵活性却使得具体情况复杂多变。这也要求我们不能把仅仅某一次的经验或者某一个浏览器，服务器的经验当作普遍适用的经验，而是始终需要具体情况具体分析。




session与cookie区别


Session是由应用服务器维持的一个服务器端的存储空间，用户在连接服务器时，会由服务器生成一个唯一的SessionID,用该SessionID为标识符来存取服务器端的Session存储空间。而SessionID这一数据则是保存到客户端，用Cookie保存的，用户提交页面时，会将这一SessionID提交到服务器端，来存取Session数据。这一过程，是不用开发人员干预的。所以一旦客户端禁用Cookie，那么Session也会失效。


服务器也可以通过URL重写的方式来传递SessionID的值，因此不是完全依赖Cookie。如果客户端Cookie禁用，则服务器可以自动通过重写URL的方式来保存Session的值，并且这个过程对程序员透明。


可以试一下，即使不写Cookie，在使用request.getCookies();取出的Cookie数组的长度也是1，而这个Cookie的名字就是JSESSIONID，还有一个很长的二进制的字符串，是SessionID的值。


Cookie是客户端的存储空间，由浏览器来维持。


在一些投票之类的场合，我们往往因为公平的原则要求每人只能投一票，在一些WEB开发中也有类似的情况，这时候我们通常会使用COOKIE来实现，例如如下的代码：


< % cookie[]cookies = request.getCookies();


if (cookies.lenght == 0 || cookies == null)


doStuffForNewbie();


//没有访问过 www.2cto.com


}


else


{


doStuffForReturnVisitor(); //已经访问过了


}


% >


这是很浅显易懂的道理，检测COOKIE的存在，如果存在说明已经运行过写入COOKIE的代码了，然而运行以上的代码后，无论何时结果都是执行doStuffForReturnVisitor()，通过控制面板-Internet选项-设置-察看文件却始终看不到生成的cookie文件，奇怪，代码明明没有问题，不过既然有cookie，那就显示出来看看。


cookie[]cookies = request.getCookies();


if (cookies.lenght == 0 || cookies == null)


out.println("Has not visited this website");


}


else


{


for (int i = 0; i < cookie.length; i++)


{


out.println("cookie name:" + cookies[ i ].getName() + "cookie value:" +


cookie[ i ].getValue());


}


}


运行结果:


cookie name:JSESSIONID cookie value:KWJHUG6JJM65HS2K6


为什么会有cookie呢,大家都知道，http是无状态的协议，客户每次读取web页面时，服务器都打开新的会话，而且服务器也不会自动维护客户的上下文信息，那么要怎么才能实现网上商店中的购物车呢，session就是一种保存上下文信息的机制，它是针对每一个用户的，变量的值保存在服务器端，通过SessionID来区分不同的客户,session是以cookie或URL重写为基础的，默认使用cookie来实现，系统会创造一个名为JSESSIONID的输出cookie，我们叫做session cookie,以区别persistentcookies,也就是我们通常所说的cookie,注意sessioncookie是存储于浏览器内存中的，并不是写到硬盘上的，这也就是我们刚才看到的JSESSIONID。


我们通常情是看不到JSESSIONID的，但是当我们把浏览器的cookie禁止后，web服务器会采用URL重写的方式传递Sessionid，我们就可以在地址栏看到sessionid=KWJHUG6JJM65HS2K6之类的字符串。


明白了原理，我们就可以很容易的分辨出persistent cookies和sessioncookie的区别了，网上那些关于两者安全性的讨论也就一目了然了，session cookie针对某一次会话而言，会话结束sessioncookie也就随着消失了，而persistentcookie只是存在于客户端硬盘上的一段文本（通常是加密的），而且可能会遭到cookie欺骗以及针对cookie的跨站脚本攻击，自然不如session cookie安全了。


通常sessioncookie是不能跨窗口使用的，当你新开了一个浏览器窗口进入相同页面时，系统会赋予你一个新的sessionid，这样我们信息共享的目的就达不到了，此时我们可以先把sessionid保存在persistentcookie中，然后在新窗口中读出来，就可以得到上一个窗口SessionID了，这样通过session cookie和persistentcookie的结合我们就实现了跨窗口的session tracking（会话跟踪）。


在一些web开发的书中，往往只是简单的把Session和cookie作为两种并列的http传送信息的方式，sessioncookies位于服务器端，persistentcookie位于客户端，可是session又是以cookie为基础的，明白的两者之间的联系和区别，我们就不难选择合适的技术来开发webservice了、

前言

由于HTTP协议是无状态的协议，一次浏览器和服务器的交互过程就是一次会话，对话完成后，这次会话就结束了，服务器端并不能记住这个人，下次再对话时，服务器端并不知道是上一次的这个人，所以服务端需要记录用户的状态时，就需要用某种机制来识别具体的用户，这个机制就是Session，服务端如何识别特定的客户？这个时候需要使用Cookie；每次HTTP请求的时候，客户端都会发送相应的Cookie信息到服务端。实际上大多数的应用都是用 Cookie 来实现Session跟踪的，第一次创建Session时，服务端会在HTTP协议中向客户端 Cookie 中记录一个Session ID，以后每次请求把这个会话ID发送到服务器，这样服务端就知道客户端是谁了；那么如果客户端的浏览器禁用了 Cookie 怎么办？ 一般这种情况下，会使用一种叫做URL重写的技术来进行session会话跟踪，即每次HTTP交互，URL后面都会被附加上一个诸如 sessionId=xxxxx 这样的参数，服务端据此来识别客户端是谁；

Session会话管理

在Web项目开发中，Session会话管理是一个很重要的部分，用于存储与记录用户的状态或相关的数据；通常情况下session交由容器（tomcat）来负责存储和管理，但是如果项目部署在多台tomcat中，则session管理存在很大的问题；1、多台tomcat之间无法共享session，比如用户在tomcat A服务器上已经登录了，但当负载均衡跳转到tomcat B时，由于tomcat B服务器并没有用户的登录信息，session就失效了，用户就退出了登录；2、一旦tomcat容器关闭或重启也会导致session会话失效；因此如果项目部署在多台tomcat中，就需要解决session共享的问题；

Session会话共享方案

第一种是使用容器扩展插件来实现，比如基于Tomcat的tomcat-redis-session-manager插件，基于Jetty的jetty-session-redis插件、memcached-session-manager插件；这个方案的好处是对项目来说是透明的，无需改动代码，但是由于过于依赖容器，一旦容器升级或者更换意味着又得重新配置；

第二种是使用Nginx负载均衡的ip_hash策略实现用户每次访问都绑定到同一台具体的后台tomcat服务器实现session总是存在；

第三种是自己写一套Session会话管理的工具类，在需要使用会话的时候都从自己的工具类中获取，而工具类后端存储可以放到Redis中，这个方案灵活性很好，但开发需要一些额外的时间。

第四种是使用框架的会话管理工具，也就是本文所使用的Spring session，这个方案既不依赖tomcat容器，又不需要改动代码，由Spring session框架为我们提供，可以说是目前非常完美的session共享解决方案；

Spring Session简介

Spring Session 是Spring家族中的一个子项目，Spring Session提供了用于管理用户会话信息的API和实现。

它把servlet容器实现的httpSession替换为spring-session，专注于解决 session管理问题，Session信息存储在Redis中，可简单快速且无缝的集成到我们的应用中；

spring session官网地址：https://spring.io/projects/spring-session

Spring Session的特性：

1、提供用户session管理的API和实现；

2、提供HttpSession，以中立的方式取代web容器的session，比如tomcat中的session；

3、支持集群的session处理，不必绑定到具体的web容器去解决集群下的session共享问题；

Spring Session示例

使用Spring session管理session，开发步骤如下：

1、添加案例所需要的maven依赖

<!-- Spring Session 依赖start -->
<dependency>
	<groupId>org.springframework.session</groupId>
	<artifactId>spring-session</artifactId>
	<version>1.3.1.RELEASE</version>
</dependency>
<!-- Spring Session 依赖end -->

<!-- Spring session redis 依赖start -->
<dependency>
	<groupId>org.springframework.session</groupId>
	<artifactId>spring-session-data-redis</artifactId>
	<version>1.3.1.RELEASE</version>
</dependency>
<!-- Spring session redis 依赖end -->

<!-- spring-data-redis依赖的JAR配置start -->
<dependency>
	<groupId>org.springframework.data</groupId>
	<artifactId>spring-data-redis</artifactId>
	<version>1.8.8.RELEASE</version>
</dependency>
<!-- spring-data-redis依赖的JAR配置end -->

<!-- jedis依赖的JAR配置start -->
<dependency>
	<groupId>redis.clients</groupId>
	<artifactId>jedis</artifactId>
	<version>2.9.0</version>
</dependency>
<!-- jedis依赖的JAR配置end -->

<!-- spring web模块依赖 start -->
<dependency>
	<groupId>org.springframework</groupId>
	<artifactId>spring-web</artifactId>
	<version>5.0.0.RELEASE</version>
</dependency>
<!-- spring web模块依赖end -->

<!-- servlet依赖的jar包start -->
<dependency>
	<groupId>javax.servlet</groupId>
	<artifactId>javax.servlet-api</artifactId>
	<version>3.1.0</version>
</dependency>
<!-- servlet依赖的jar包start -->

<!-- jsp依赖jar包start -->
<dependency>
	<groupId>javax.servlet.jsp</groupId>
	<artifactId>javax.servlet.jsp-api</artifactId>
	<version>2.3.1</version>
</dependency>
<!-- jsp依赖jar包end -->

<!--jstl标签依赖的jar包start -->
<dependency>
	<groupId>javax.servlet</groupId>
	<artifactId>jstl</artifactId>
	<version>1.2</version>
</dependency>
<!--jstl标签依赖的jar包end -->

2、在web.xml文件文件中配置springSessionRepositoryFilter过滤器

	<filter>
		<filter-name>springSessionRepositoryFilter</filter-name>
		<filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
	</filter>
	<filter-mapping>
		<filter-name>springSessionRepositoryFilter</filter-name>
		<url-pattern>/*</url-pattern>
	</filter-mapping>

3、在web.xml文件中加载Spring配置文件

<!-- needed for ContextLoaderListener -->
	<context-param>
		<param-name>contextConfigLocation</param-name>
		<param-value>classpath:applicationContext.xml</param-value>
	</context-param>

	<!-- Bootstraps the root web application context before servlet initialization -->
	<listener>
		<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
	</listener>

4、Spring配置文件配置一个RedisHttpSessionConfiguration类

 <!-- spring注解、bean的处理器 -->
    <context:annotation-config/>


    <!-- Spring session 的配置类 -->
    <bean class="org.springframework.session.data.redis.config.annotation.web.http.RedisHttpSessionConfiguration">
        <!--指定session策略-->
        <!--<property name="httpSessionStrategy" ref="httpSessionStrategy"/>-->
    </bean>

    <bean id="httpSessionStrategy" class="org.springframework.session.web.http.CookieHttpSessionStrategy">
        <!--使用cookie策略-->
        <property name="cookieSerializer" ref="cookieSerializer"/>
    </bean>

    <bean id="cookieSerializer" class="org.springframework.session.web.http.DefaultCookieSerializer">
        <!--指定cookie的域名及路径-->
        <property name="cookiePath" value="/"/>
        <property name="domainName" value="web.com"/>
    </bean>

5、Spring配置文件配置Spring-data-redis

<!-- 配置jedis连接工厂，用于连接redis -->
<bean id="jedisConnectionFactory" class="org.springframework.data.redis.connection.jedis.JedisConnectionFactory">
    <property name="hostName" value="${redis.hostName}"/>
    <property name="port" value="${redis.port}"/>
    <property name="password" value="${redis.password}"/>
    <property name="usePool" value="${redis.usePool}"/>
    <property name="timeout" value="${redis.timeout}"/>
</bean>

<!--读取redis.properties属性配置文件-->
<context:property-placeholder location="classpath:redis.properties"/>

6、redis配置文件

redis.hostName=192.168.184.133
redis.port=6379
redis.password=123456
redis.usePool=true
redis.timeout=10000

7、编写一个Servlet或JSP验证session共享问题

@WebServlet(name = "SessionServlet", urlPatterns = "/session")
public class SessionServlet extends HttpServlet {

    protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        this.doGet(request,response);
    }

    protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
        String sesssionID = request.getSession().getId();
        //部署两份，把这个地方8081改成8080就行了，只是为了区分
        response.getWriter().write("8081 Server SessionID"+sesssionID);
    }
}

演示案例：

1、同域名下相同项目实现Session共享

在同一个域名下，比如：www.web.com
	
同一个项目
	
部署了多台tomcat
	
这就是典型的集群
	
使Nginx负载均衡，每次发请求在两个tomcat容器之间负载均衡，这也是Nginx的默认策略
	

	

	

	
很显然看到的是负载均衡，然后放session，默认浏览器中没有session，会自动创键，看到8081服务器的sessionid为
	
795b073c-0e27-4339-bf01-2fb7d39a3ed2f
	
	

	
查看redis，可以看到该session信息存储到Redis里面了，Redis仅仅是一个容器，也可以使用其他容器
	

	

	
#定时Job程序触发Session 过期。(spring-session 功能)，数据类型：Set
	
Key：spring:session:expirations:XXXXX
	
# 存储 Session 数据,数据类型hash
	
Key：spring:session:sessions:XXXXXXX
	
# Redis TTL触发Session 过期。(Redis 本身功能)，数据类型：String
	
Key：spring:session:sessions:expires:XXXXX
	

	
在次执行请求，负载均衡，跳转到8080服务器，8080服务器上是没有session的会新生成一个sessionid，但是这时候没有新生产成sessionid，而是在使用8081生成的sessionid，这就达成了session共享。
2、同域名下不同项目实现Session共享

在同一个域名下，比如：
	
www.web.com/jiekuan
		
www.web.com/touzi
	
	
有多个不同的项目
	

	
做法：设置Cookie路径为根/上下文
3、同根域名不同二级子域名下的项目实现Session共享

同一个根域名，比如：
	
www.web.com
		
beijing.web.com
		
nanjing.web.com
	
	
不同的二级子域名
	

	
做法：
	
设置Cookie路径为根/上下文
		
设置域名为同域名 web.com
	
4、不同根域名下的项目实现Session共享

单点登录
	
单点登录(Single Sign On)，简称为 SSO，是流行的企业业务整合的解决方案之一，SSO是指在多个应用系统中，用户只需要登录一次就可以访问所有相互信任的应用系统；
		
比如阿里巴巴这样的公司，有多个业务线，多个网站，用户在一个网站登录，那么其他网站也会是登录了的状态，比如：登录了淘宝网，则天猫网也是登录的；
	
	
比如：
	
www.web.com
		
www.myweb.com
		
www.webtest.com
		
ip和域名也会产生不同的sessionid
	
	
对于不同根域名的场景，要实现一处登录，处处登录，Spring Session不支持
如果你觉得文章对你有帮助，那就关注下方微信公众号吧，你会收到更多的实用技术干货：