Servlet/JSP中的Session
通过上述的讲解，读者应该对session有了一个大体的认识，但是具体到某种动态页面技术，又是怎么实现session的呢？下面笔者将结合session的生命周期（lifecycle），从源代码的层次来具体分析一下在servlet/jsp技术中，session是怎么实现的。代码部分以tomcat6.0.20作为参考。
创建
在我问过的一些从事java web开发的人中，对于session的创建时机大都这么回答：当我请求某个页面的时候，session就被创建了。这句话其实很含糊，因为要创建session请求的发送是必不可少的，但是无论何种请求都会创建session吗？错。我们来看一个例子。
众所周知，jsp技术是servlet技术的反转，在开发阶段，我们看到的是jsp页面，但真正到运行时阶段，jsp页面是会被“翻译”为servlet类来执行的，例如我们有如下jsp页面：
| <%@ page language="java" pageEncoding="ISO-8859-1" session="true"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>index.jsp</title> </head> <body> This is index.jsp page. <br> </body> </html> |
在我们初次请求该页面后，在对应的work目录可以找到该页面对应的java类，考虑到篇幅的原因，在此只摘录比较重要的一部分，有兴趣的读者可以亲自试一下：
| ...... response.setContentType("text/html;charset=ISO-8859-1"); pageContext = _jspxFactory.getPageContext(this, request, response, null, true, 8192, true); _jspx_page_context = pageContext; application = pageContext.getServletContext(); config = pageContext.getServletConfig(); session = pageContext.getSession(); out = pageContext.getOut(); _jspx_out = out;
out.write("\r\n"); out.write("<!DOCTYPE HTML PUBLIC \"-//W3C//DTD HTML 4.01 Transitional//EN\">\r\n"); out.write("<html>\r\n"); ...... |
可以看到有一句显式创建session的语句，它是怎么来的呢？我们再看一下对应的jsp页面，在jsp的page指令中加入了session="true"，意思是在该页面启用session，其实作为动态技术，这个参数是默认为true的，这很合理，在此显示写出来只是做一下强调。很显然二者有着必然的联系。笔者在jsp/servlet的翻译器（org.apache.jasper.compiler）的源码中找到了相关证据：
| ...... if (pageInfo.isSession()) out.printil("session = pageContext.getSession();"); out.printil("out = pageContext.getOut();"); out.printil("_jspx_out = out;"); ...... |
上面的代码片段的意思是如果页面中定义了session="true"，就在生成的servlet源码中加入session的获取语句。这只能够说明session创建的条件，显然还不能说明session是如何创建的，本着逐本溯源的精神，我们继续往下探索。
有过servlet开发经验的应该记得我们是通过HttpServletRequest的getSession方法来获取当前的session对象的：
| public HttpSession getSession(boolean create); public HttpSession getSession(); |
二者的区别只是无参的getSession将create默认设置为true而已。即：
| public HttpSession getSession() { return (getSession(true)); } |
那么这个参数到底意味着什么呢？通过层层跟踪，笔者终于理清了其中的脉络，由于函数之间的关系比较复杂，如果想更详细地了解内部机制，建议去独立阅读tomcat相关部分的源代码。这里我将其中的大致流程叙述一下：
1. 用户请求某jsp页面，该页面设置了session="true"；
2. Servlet/jsp容器将其翻译为servlet，并加载、执行该servlet；
3. Servlet/jsp容器在封装HttpServletRequest对象时根据cookie或者url中是否存在jsessionid来决定是绑定当前的session到HttpRequest还是创建新的session对象（在请求解析阶段发现并记录jsessionid，在Request对象创建阶段将session绑定）；
4. 程序按需操作session，存取数据；
5. 如果是新创建的session，在结果响应时，容器会加入Set-cookie头，以提醒浏览器要保持该会话（或者采用URL重写方式将新的链接呈现给用户）。
通过上面的叙述读者应该了解了session是何时创建的，这里再从servlet这个层面总结一下：当用户请求的servlet调用了getSession方法时，都会获取session，至于是否创建新的session取决于当前request是否已绑定session。当客户端在请求中加入了jsessionid标识而servlet容器根据此标识查找到了对应的session对象时，会将此session绑定到此次请求的request对象，客户端请求中不带jsessionid或者此jsessionid对应的session已过期失效时，session的绑定无法完成，此时必须创建新的session。同时发送Set-cookie头通知客户端开始保持新的会话。
保持
理解了session的创建，就很好理解会话是如何在客户端和服务端之间保持的了。当首次创建了session后，客户端会在后续的请求中将session的标识符带到服务端，服务端程序只要在需要session的时候调用getSession，服务端就可以将对应的session绑定到当前请求，从而实现状态的保持。当然这需要客户端的支持，如果禁用了cookie而又不采用url重写的话，session是无法保持的。
如果几次请求之间有一个servlet未调用getSession（或者干脆请求一个静态页面）会不会使得会话中断呢？这个不会发生的，因为客户端只会将合法的cookie值传送给服务端，至于服务端拿cookie做什么事它是不会关心的，当然也无法关心。Session建立之后，客户端会一直将session的标识符传送到服务器，无论请求的页面是动态的、静态的，甚至是一副图片。
销毁
此处谈到的销毁是指会话的废弃，至于存储会话信息的数据结构是回收被重用还是直接释放内存我们并不关心。Session的销毁有两种情况：超时和手动销毁。
由于HTTP协议的无状态性，服务端无法得知一个session对象何时将再次被使用，可能用户开启了一个session之后再也没有后续的访问，而且session的保持是需要消耗一定的服务端开销的，因此不可能一味地创建session而不去回收无用的session。这里就引入了一个超时机制。Tomcat中的超时在web.xml里做如下配置：
| <session-config> <session-timeout>30</session-timeout> </session-config> |
上述配置是指session在30分钟没有被再次使用就将其销毁。Tomcat是怎么计算这个30分钟的呢？原来在getSession之后，都要调用它的access方法，修改lastAccessedTime，在销毁session的时候就是判断当前时间和这个lastAccessedTime的差值。
手动销毁是指直接调用其invalidate方法，此方法实际上是调用expire方法来手动将其设置为超时。
当用户手动请求了session的销毁时，客户端是无法知道服务端的session已经被销毁的，它依然会发送先前的session标识符到服务端。而此时如果再次请求了某个调用了getSession的servlet，服务端是无法根据先前的session标识符找到相应的session对象的，这是又要重新创建新的session，分配新的标识符，并告知服务端更新session标识符开始保持新的会话。
Session的数据结构
在servlet/jsp中，容器是用何种数据结构来存储session相关的变量的呢？我们猜测一下，首先它必须被同步操作，因为在多线程环境下session是线程间共享的，而web服务器一般情况下都是多线程的（为了提高性能还会用到池技术）；其次，这个数据结构必须容易操作，最好是传统的键值对的存取方式。
那么我们先具体到单个session对象，它除了存储自身的相关信息，比如id之外，tomcat的session还提供给程序员一个用以存储其他信息的接口（在类org.apache.catalina.session. StandardSession里）：
| public void setAttribute(String name, Object value, boolean notify) |
在这里可以追踪到它到底使用了何种数据：
| protected Map attributes = new ConcurrentHashMap(); |
这就很明确了，原来tomcat使用了一个ConcurrentHashMap对象存储数据，这是java的concurrent包里的一个类。它刚好满足了我们所猜测的两点需求：同步与易操作性。
那么tomcat又是用什么数据结构来存储所有的session对象呢？果然还是ConcurrentHashMap（在管理session的org.apache.catalina.session. ManagerBase类里）：
| protected Map<String, Session> sessions = new ConcurrentHashMap<String, Session>(); |
具体原因就不必多说了。至于其他web服务器的具体实现也应该考虑到这两点。
Session Hijack
Session hijack即会话劫持是一种比较严重的安全威胁，也是一种广泛存在的威胁，在session技术中，客户端和服务端通过传送session的标识符来维护会话，但这个标识符很容易就能被嗅探到，从而被其他人利用，这属于一种中间人攻击。
本部分通过一个实例来说明何为会话劫持，通过这个实例，读者其实更能理解session的本质。
首先，我编写了如下页面：
| <%@ page language="java" pageEncoding="ISO-8859-1" session="true"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title>index.jsp</title> </head> <body> This is index.jsp page. <br> <% Object o = session.getAttribute("counter"); if (o == null) { session.setAttribute("counter", 1); } else { Integer i = Integer.parseInt(o.toString()); session.setAttribute("counter", i + 1); } out.println(session.getAttribute("counter")); %> <a href="<%=response.encodeRedirectURL("index.jsp")%>">index</a> </body> </html> |
页面的功能是在session中放置一个计数器，第一次访问该页面，这个计数器的值初始化为1，以后每一次访问这个页面计数器都加1。计数器的值会被打印到页面。另外，为了比较简单地模拟，笔者禁用了客户端（采用firefox3.0）的cookie，转而改用URL重写方式，因为直接复制链接要比伪造cookie方便多了。
下面，打开firefox访问该页面，我们看到了计数器的值为1：
（图三）
然后点击index链接来刷新计数器，注意不要刷新当前页，因为我们没用采用cookie的方式，只能在url后面带上jsessionid，而此时地址栏里的url是无法带上jsessionid的。如图四，我把计数器刷新到了20。
（图四）
下面是最关键的，复制firefox地址栏里的地址（笔者看到的是http://localhost:8080/sessio
n/index.jsp;jsessionid=1380D9F60BCE9C30C3A7CBF59454D0A5），然后打开另一个浏览器，此处不必将其cookie禁用。这里我打开了苹果的safari3浏览器，然后将地址粘贴到其地址栏里，回车后如下图：
（图五）
很奇怪吧，计数器直接到了21。这个例子笔者是在同一台计算机上做的，不过即使换用两台来做，其结果也是一样的。此时如果交替点击两个浏览器里的index链接你会发现他们其实操纵的是同一个计数器。其实不必惊讶，此处safari盗用了firefox和tomcat之间的维持会话的钥匙，即jsessionid，这属于session hijack的一种。在tomcat看来，safari交给了它一个jsessionid，由于HTTP协议的无状态性，它无法得知这个jsessionid是从firefox那里“劫持”来的，它依然会去查找对应的session，并执行相关计算。而此时firefox也无法得知自己的保持会话已经被“劫持”。
结语
到这里，读者应该对session有了更多的更深层次的了解，不过由于笔者的水平以及视野有限，文中也不乏表述欠妥之处，通篇更多地描述了在servlet/jsp中的session机制，但其他开发平台的机制也都万变不离其宗。只要认真思考，你会发现其实这里林林总总之间，总有一些因果关系存在。在软件规模日益增大的背景下，我们更多的时候接触到的是框架、组件，程序员的双眼被蒙蔽了，在这些框架、组件不断产生以及版本的不断更新中，其实有很多相对不变的东西，那就是规范、协议、模式、算法等等，真正令一个人得到提高的还是那些底层的支撑技术。平时多多思考的话，你就能把类似的探索转化为印证。做技术犹如解牛，知筋知骨方能游刃有余。
21万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
