HttpSession工作原理简介

HTTP协议（http://www.w3.org/Protocols/）是“一次性单向”协议。 
服务端不能主动连接客户端，只能被动等待并答复客户端请求。客户端连接服务端，发出一个HTTP Request，服务端处理请求，并且返回一个HTTP Response给客户端，本次HTTP Request-Response Cycle结束。 
我们看到，HTTP协议本身并不能支持服务端保存客户端的状态信息。于是，Web Server中引入了session的概念，用来保存客户端的状态信息。 
这里用一个形象的比喻来解释session的工作方式。假设Web Server是一个商场的存包处，HTTP Request是一个顾客，第一次来到存包处，管理员把顾客的物品存放在某一个柜子里面（这个柜子就相当于Session），然后把一个号码牌交给这个顾 客，作为取包凭证（这个号码牌就是Session ID）。顾客（HTTP Request）下一次来的时候，就要把号码牌（Session ID）交给存包处（Web Server）的管理员。管理员根据号码牌（Session ID）找到相应的柜子（Session），根据顾客（HTTP Request）的请求，Web Server可以取出、更换、添加柜子（Session）中的物品，Web Server也可以让顾客（HTTP Request）的号码牌和号码牌对应的柜子（Session）失效。顾客（HTTP Request）的忘性很大，管理员在顾客回去的时候（HTTP Response）都要重新提醒顾客记住自己的号码牌（Session ID）。这样，顾客（HTTP Request）下次来的时候，就又带着号码牌回来了。 
我们可以看到，Session ID实际上是在客户端和服务端之间通过HTTP Request和HTTP Response传来传去的。 

我们看到，号码牌（Session ID）必须包含在HTTP Request里面。关于HTTP Request的具体格式，请参见HTTP协议（http://www.w3.org/Protocols/）。这里只做一个简单的介绍。 
在Java Web Server（即Servlet/JSP Server）中，Session ID用jsessionid表示（请参见Servlet规范）。 
HTTP Request一般由3部分组成： 
（1）Request Line 
这一行由HTTP Method（如GET或POST）、URL、和HTTP版本号组成。 
例如，GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1 
GET http://www.google.com/search?q=Tomcat HTTP/1.1 
POST http://www.google.com/search HTTP/1.1 
GET http://www.somsite.com/menu.do;jsessionid=1001 HTTP/1.1 

（2）Request Headers 
这部分定义了一些重要的头部信息，如，浏览器的种类，语言，类型。Request Headers中还可以包括Cookie的定义。例如： 
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0) 
Accept-Language: en-us 
Cookie: jsessionid=1001 

（3）Message Body 
如果HTTP Method是GET，那么Message Body为空。 
如果HTTP Method是POST，说明这个HTTP Request是submit一个HTML Form的结果， 
那么Message Body为HTML Form里面定义的Input属性。例如， 
user=guest 
password=guest 
jsessionid=1001 
主意，如果把HTML Form元素的Method属性改为GET。那么，Message Body为空，所有的Input属性都会加在URL的后面。你在浏览器的URL地址栏中会看到这些属性，类似于 
http://www.somesite/login.do?user=guest&password=guest&jsessionid=1001 

从理论上来说，这3个部分（Request URL，Cookie Header, Message Body）都可以用来存放Session ID。由于Message Body方法必须需要一个包含Session ID的HTML Form，所以这种方法不通用。 
一般用来实现Session的方法有两种： 
（1）URL重写。 
Web Server在返回Response的时候，检查页面中所有的URL，包括所有的连接，和HTML Form的Action属性，在这些URL后面加上“;jsessionid=XXX”。 
下一次，用户访问这个页面中的URL。jsessionid就会传回到Web Server。 
（2）Cookie。 
如果客户端支持Cookie，Web Server在返回Response的时候，在Response的Header部分，加入一个“set-cookie: jsessionid=XXXX”header属性，把jsessionid放在Cookie里传到客户端。 
客户端会把Cookie存放在本地文件里，下一次访问Web Server的时候，再把Cookie的信息放到HTTP Request的“Cookie”header属性里面，这样jsessionid就随着HTTP Request返回给Web Server。

=======================================================================

一个session就是一系列某用户和服务器间的通讯。服务器有能力分辨出不同的用户。一个session的建立是从一个用户向服务器发第一个请求开始，而以用户显式结束或session超时为结束。
其工作原理是这样的：
1.当一个用户向服务器发送第一个请求时，服务器为其建立一个session，并为此session创建一个标识号；
2.这个用户随后的所有请求都应包括这个标识号。服务器会校对这个标识号以判断请求属于哪个session。
这种机制不使用IP作为标识，是因为很多机器是通过代理服务器方式上网，没法区分每一台机器。
对于session标识号（sessionID），有两种方式实现：cookies和URL重写。

HttpSession的使用
我们来看看在API中对session是如何定义和操作的。
当需要为用户端建立一个session时，servlet容器就创建了一个HttpSession对象。其中存储了和本session相关的信息。所以，在一个servlet中有多少个不同用户连接，就会有多少个HttpSession对象。
使用的机理是：
1.从请求中提取HttpSession对象；
2.增加或删除HttpSession中的属性；
3.根据需要关闭HttpSession或使其失效。

在请求中有两个重载的方法用来获取HttpSession对象。
HttpSession getSession(boolean create)/getSession();作用是提取HttpSession对象，如果没有自动创建。

获取到HttpSession对象后，我们就需要使用HttpSession的某些方法去设置和更改某些参数了。如：
void setAttribute(String name, Object value);
Object getAttribute(String name);
void removeAttribute(String name);

在javax.servlet.http包里一共定义了四个session监听器接口和与之关联的两个session事件。分别是：
HttpSessionAttributeListener and HttpSessionBindingEvent;
HttpSessionBindingListener and HttpSessionBindingEvent;
HttpSessionListener and HttpSessionEvent;
HttpSessionActivationListener and HttpSessionEvent.

他们的继承关系是：
所有四个接口的父类是java.util.EventListener;
HttpSessionEvent扩展java.util.EventObject;
而HttpSessionBindingEvent又扩展了HttpSessionEvent。

以下分别详述：
HttpSessionAttributeListener
当session中的属性被添加，更改，删除时得到通知。这个接口上节讲过，主要看其它三个。

HttpSessionBindingListener
当一个实现了HttpSessionBindingListener的类被加入到HttpSession中（或从中移出）时，会产生HttpBindingEvent事件，而这些事件会被它本身接收到。
本接口定义了两个方法：
void valueBound(HttpSessionBindingEvent e);
void valueUnbound(HttpSessionBindingEvent e);
当多个实现了HttpSessionBindingListener的类被加入到HttpSession中时，各类的方法只对本类感兴趣，不会去理会其它类的加入。
即使是同一类的不同实例间，也是互不关心的（各扫门前雪）。

我们可以看到前两个接口都对HttpSessionBindingEvent事件做出反应，但机理不同。
HttpSessionAttributeListener是在web.xml中登记的，servlet容器仅创建一个实例，来为任何在session中增加属性的servlet服务。触发事件的对象是所有可以转换为Object的实例。
HttpSessionBindingListener不用在web.xml中登记，在每个servlet中用new创建实例，且仅对本实例向session中的加入（或移出）感兴趣。触发事件的对象仅仅是自己。

HttpSessionListener
对于session的创建和取消感兴趣。需要在web.xml中登记。
共有两个方法：
void sessionCreated(HttpSessionEvent se);
void sessionDestroyed(HttpSessionEvent se);
使用它我们可以容易的创建一个类来对session计数。
也许我们会简单的考虑使用sessionDestroyed方法来在session结束后做一些清理工作。但是，请注意，当这个方法被调用的时候，session已经结束了，你不能从中提取到任何信息了。因此，我们要另辟蹊径。
一种通常采用的方法是使用HttpSessionBindingListener接口。在session创建时增加一个属性，而在session结束前最 后一件事将这个属性删除，这样就会触发valueUnbound方法，所有对session的清理工作可以在这个方法中实现。

HttpSessionActivationListener
当session在分布式环境中跨JVM时，实现该接口的对象得到通知。共两个方法：
void sessionDidActivate(HttpSessionEvent se);
void sessionWillPassivate(HttpSessionEvent se);

1、HTTP协议本身是“连接-请求-应答-关闭连接”模式的，是一种无状态协议（HTTP只是一个传输协议）；
2、Cookie规范是为了给HTTP增加状态跟踪用的（如果要精确把握，建议仔细阅读一下相关的RFC），但不是唯一的手段；
3、所谓Session，指的是客户端和服务端之间的一段交互过程的状态信息（数据）；这个状态如何界定，生命期有多长，这是应用本身的事情；
4、由于B/S计算模型中计算是在服务器端完成的，客户端只有简单的显示逻辑，所以，Session数据对客户端应该是透明的不可理解的并且应该受控于服 务端；Session数据要么保存到服务端（HttpSession），要么在客户端和服务端之间传递（Cookie或url rewritting或Hidden input）；
5、由于HTTP本身的无状态性，服务端无法知道客户端相继发来的请求是来自一个客户的，所以，当使用服务端HttpSession存储会话数据的时候客户端的每个请求都应该包含一个session的标识(sid, jsessionid 等等)来告诉服务端；
6、会话数据保存在服务端（如HttpSession）的好处是减少了HTTP请求的长度，提高了网络传输效率；客户端session信息存储则相反；
7、客户端Session存储只有一个办法：cookie(url rewritting和hidden input因为无法做到持久化，不算，只能作为交换session id的方式，即a method of session tracking)，而服务端做法大致也是一个道理：容器有个session管理器（如tomcat的 org.apache.catalina.session包里面的类），提供session的生命周期和持久化管理并提供访问session数据的 api；
8、使用服务端还是客户端session存储要看应用的实际情况的。一般来说不要求用户注册登录的公共服务系统（如google）采用cookie做客户 端session存储（如google的用户偏好设置），而有用户管理的系统则使用服务端存储。原因很显然：无需用户登录的系统唯一能够标识用户的就是用 户的电脑，换一台机器就不知道谁是谁了，服务端session存储根本不管用；而有用户管理的系统则可以通过用户id来管理用户个人数据，从而提供任意复 杂的个性化服务；
9、客户端和服务端的session存储在性能、安全性、跨站能力、编程方便性等方面都有一定的区别，而且优劣并非绝对（譬如TheServerSide 号称不使用HttpSession，所以性能好，这很显然：一个具有上亿的访问用户的系统，要在服务端数据库中检索出用户的偏好信息显然是低效 的，Session管理器不管用什么数据结构和算法都要耗费大量内存和CPU时间；而用cookie，则根本不用检索和维护session数据，服务器可 以做成无状态的，当然高效）；
10、  所谓的“会话cookie”简单的说就是没有明确指明有效期的cookie，仅在浏览器当前进程生命期内有效，可以被后继的Set-Cookie操作清除掉。

当程序需要为某个客户端的请求创建一个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.

1、session在何时被创建
一个常见的误解是以为session在有客户端访问时就被创建，然而事实是直到某server端程序调用 HttpServletRequest.getSession(true)这样的语句时才被创建，注意如果JSP没有显示的使用 <% @page session="false"%> 关闭session，则JSP文件在编译成Servlet时将会自动加上这样一条语句 HttpSession session = HttpServletRequest.getSession(true);这也是JSP中隐含的 session对象的来历。由于session会消耗内存资源，因此，如果不打算使用session，应该在所有的JSP中关闭它。
2、存放在session中的对象必须是可序列化的吗
不是必需的。要求对象可序列化只是为了session能够在集群中被复制或者能够持久保存或者在必要时server能够暂时把session交换出内存。

3、如何才能正确的应付客户端禁止cookie的可能性
对所有的URL使用URL重写，包括超链接，form的action，和重定向的URL，具体做法参见:
http://e-docs.bea.com/wls/docs70/webapp/sessions.html#100770

Instead, use the HttpServletResponse.encodeURL() method, for example:

out.println("<a href=\""     + response.encodeURL("myshop/catalog.jsp")      + "\">catalog</a>");
Calling the encodeURL() method determines if the URL needs to be rewritten, and if so, it rewrites it by including the session ID in the URL. The session ID is appended to the URL and begins with a semicolon.

In addition to URLs that are returned as a response to WebLogic Server, also encode URLs that send redirects. For example:
if (session.isNew()) response.sendRedirect (response.encodeRedirectUrl(welcomeURL));

4、开两个浏览器窗口访问应用程序会使用同一个session还是不同的session
参见第三小节对cookie的讨论，对session来说是只认id不认人，因此不同的浏览器，不同的窗口打开方式以及不同的cookie存储方式都会对这个问题的答案有影响。