Chinaunix首页 | 论坛 | 博客

活出自我

首页　| 　博文目录　| 　关于我

bjutslg

  • 博客访问： 1670425
  • 博文数量： 695
  • 博客积分： 0
  • 博客等级： 民兵
  • 技术积分： 4027
  • 用 户 组： 普通用户
  • 注册时间： 2013-11-20 21:22
文章分类

全部博文（695）

文章存档

2018年（18）

2017年（74）

2016年（170）

2015年（102）

2014年（276）

2013年（55）

我的朋友
最近访客
推荐博文
相关博文
Tomcat中的Session小结

分类： Java

2016-08-25 11:29:44

什么是Session

对Tomcat而言，Session是一块在服务器开辟的内存空间，其存储结构为ConcurrentHashMap；

Session的目的

Http协议是一种无状态协议，即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；

Session的主要目的就是为了弥补Http的无状态特性。简单的说，就是服务器可以利用session存储客户端在同一个会话期间的一些操作记录；

实现机制

先看两个问题，如下：

1、服务器如何判断客户端发送过来的请求是属于同一个会话？

答：用Session id区分，Session id相同的即认为是同一个会话，在Tomcat中Session id用JSESSIONID表示；

2、服务器、客户端如何获取Session id？Session id在其之间是如何传输的呢？

答：服务器第一次接收到请求时，开辟了一块Session空间（创建了Session对象），同时生成一个Session id，并通过响应头的Set-Cookie：“JSESSIONID=XXXXXXX”命令，向客户端发送要求设置cookie的响应；

客户端收到响应后，在本机客户端设置了一个JSESSIONID=XXXXXXX的cookie信息，该cookie的过期时间为浏览器会话结束；

接下来客户端每次向同一个网站发送请求时，请求头都会带上该cookie信息（包含Session id）；

然后，服务器通过读取请求头中的Cookie信息，获取名称为JSESSIONID的值，得到此次请求的Session id；

ps：服务器只会在客户端第一次请求响应的时候，在响应头上添加Set-Cookie：“JSESSIONID=XXXXXXX”信息，接下来在同一个会话的第二第三次响应头里，是不会添加Set-Cookie：“JSESSIONID=XXXXXXX”信息的；

而客户端是会在每次请求头的cookie中带上JSESSIONID信息；

举个例子：

以chrome浏览器为例，访问一个基于tomcat服务器的网站的时候，

浏览器第一次访问服务器，服务器会在响应头添加Set-Cookie：“JSESSIONID=XXXXXXX”信息，要求客户端设置cookie，如下图：

同时我们也可以在浏览器中找到其存储的sessionid信息，如下图

接下来，浏览器第二次、第三次...访问服务器，观察其请求头的cookie信息，可以看到JSESSIONID信息存储在cookie里，发送给服务器；且响应头里没有Set-Cookie信息，如下图：

只要浏览器未关闭，在访问同一个站点的时候，其请求头Cookie中的JSESSIONID都是同一个值，被服务器认为是同一个会话。

 再举个简单的例子加深印象，新建个Web工程，并写一个Servlet，在doGet中添加如下代码，主要做如下工作

首先，从session中获取key为count的值，累加，存入session，并打印；

然后，每次从请求中获取打印cookie信息，从响应中获取打印Header的Set-Cookie信息：

点击(此处)折叠或打开

  1. /**
  2.      * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
  3.      */
  4.     protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
  5.         
  6.         if(request.getSession().getAttribute("count") == null){
  7.             request.getSession().setAttribute("count", 0);
  8.             response.getWriter().write(0+"");
  9.         }else{
  10.             int a = Integer.parseInt(request.getSession().getAttribute("count").toString());
  11.             request.getSession().setAttribute("count", ++a);
  12.             response.getWriter().write(a+"");
  13.         }

  15.         Cookie[] cookies = request.getCookies();
  16.         StringBuffer sb = new StringBuffer();
  17.         if(cookies!=null){
  18.             for(Cookie cookie : cookies){
  19.                 sb.append(cookie.getName()+":"+cookie.getValue()+",");
  20.             }
  21.             sb.deleteCharAt(sb.length()-1);
  22.         }

  24.         System.out.println("[第"+(++index)+"次访问]from client request, cookies:" + sb);
  25.         System.out.println("[第"+(index)+"次访问]from server response, header-Set-Cookie:" + response.getHeader("Set-Cookie"));;
  26.     }


部署到tomcat后，连续访问该servlet，观察控制台输出，如下，客户端第一次访问服务器的时候，在服务端的响应头里添加了JSESSIONID信息，且接下来客户端的每次访问都会带上该JSESSIONID：

其实这里有一个问题，session劫持

只要用户知道JSESSIONID，该用户就可以获取到JSESSIONID对应的session内容，还是以上面这个例子为例，

我先用IE浏览器访问该站点，比如连续访问了5次，此时，session中的count值为：

查看该会话的Session id，为6A541281A79B24BC290ED3270CF15E32

接下来打开chrome控制台，将IE浏览器获取过来的JSESSIONID信息（“6A541281A79B24BC290ED3270CF15E32”）写入到cookie中，如下

接着删除其中的一个，只留下JSESSIONID为“6A541281A79B24BC290ED3270CF15E32”的cookie；

刷新页面，发现我们从session获取的count值已经变成6了，说明此次chrome浏览器的请求劫持了IE浏览器会话中的session，

Tomcat中的session实现

Tomcat中一个会话对应一个session，其实现类是StandardSession，查看源码，可以找到一个attributes成员属性，即存储session的数据结构，为ConcurrentHashMap，支持高并发的HashMap实现； 

    /** * The collection of user data attributes associated with this Session. */ protected Map attributes = new ConcurrentHashMap();

那么，tomcat中多个会话对应的session是由谁来维护的呢？ManagerBase类，查看其代码，可以发现其有一个sessions成员属性，存储着各个会话的session信息： 

    /** * The set of currently active Sessions for this Manager, keyed by
     * session identifier. */ protected Map sessions = new ConcurrentHashMap();

接下来，看一下几个重要的方法，

服务器查找Session对象的方法

客户端每次的请求，tomcat都会在HashMap中查找对应的key为JSESSIONID的Session对象是否存在，可以查看Request的doGetSession方法源码，如下源码：


点击(此处)折叠或打开

  1. protected Session doGetSession(boolean create) {

  3.         // There cannot be a session if no context has been assigned yet
  4.         Context context = getContext();
  5.         if (context == null) {
  6.             return (null);
  7.         }

  9.         // Return the current session if it exists and is valid
  10.         if ((session != null) && !session.isValid()) {
  11.             session = null;
  12.         }
  13.         if (session != null) {
  14.             return (session);
  15.         }

  17.         // Return the requested session if it exists and is valid
  18.         Manager manager = context.getManager();
  19.         if (manager == null) {
  20.             return null; // Sessions are not supported
  21.         }
  22.         if (requestedSessionId != null) {
  23.             try {
  24.                 session = manager.findSession(requestedSessionId);
  25.             } catch (IOException e) {
  26.                 session = null;
  27.             }
  28.             if ((session != null) && !session.isValid()) {
  29.                 session = null;
  30.             }
  31.             if (session != null) {
  32.                 session.access();
  33.                 return (session);
  34.             }
  35.         }

  37.         // Create a new session if requested and the response is not committed
  38.         if (!create) {
  39.             return (null);
  40.         }
  41.         if ((context != null) && (response != null) &&
  42.             context.getServletContext().getEffectiveSessionTrackingModes().
  43.                     contains(SessionTrackingMode.COOKIE) &&
  44.             response.getResponse().isCommitted()) {
  45.             throw new IllegalStateException
  46.               (sm.getString("coyoteRequest.sessionCreateCommitted"));
  47.         }

  49.         // Re-use session IDs provided by the client in very limited
  50.         // circumstances.
  51.         String sessionId = getRequestedSessionId();
  52.         if (requestedSessionSSL) {
  53.             // If the session ID has been obtained from the SSL handshake then
  54.             // use it.
  55.         } else if (("/".equals(context.getSessionCookiePath())
  56.                 && isRequestedSessionIdFromCookie())) {
  57.             /* This is the common(ish) use case: using the same session ID with
  58.              * multiple web applications on the same host. Typically this is
  59.              * used by Portlet implementations. It only works if sessions are
  60.              * tracked via cookies. The cookie must have a path of "/" else it
  61.              * won't be provided to for requests to all web applications.
  62.              *
  63.              * Any session ID provided by the client should be for a session
  64.              * that already exists somewhere on the host. Check if the context
  65.              * is configured for this to be confirmed.
  66.              */
  67.             if (context.getValidateClientProvidedNewSessionId()) {
  68.                 boolean found = false;
  69.                 for (Container container : getHost().findChildren()) {
  70.                     Manager m = ((Context) container).getManager();
  71.                     if (m != null) {
  72.                         try {
  73.                             if (m.findSession(sessionId) != null) {
  74.                                 found = true;
  75.                                 break;
  76.                             }
  77.                         } catch (IOException e) {
  78.                             // Ignore. Problems with this manager will be
  79.                             // handled elsewhere.
  80.                         }
  81.                     }
  82.                 }
  83.                 if (!found) {
  84.                     sessionId = null;
  85.                 }
  86.                 sessionId = getRequestedSessionId();
  87.             }
  88.         } else {
  89.             sessionId = null;
  90.         }
  91.         session = manager.createSession(sessionId);

  93.         // Creating a new session cookie based on that session
  94.         if ((session != null) && (getContext() != null)
  95.                && getContext().getServletContext().
  96.                        getEffectiveSessionTrackingModes().contains(
  97.                                SessionTrackingMode.COOKIE)) {
  98.             Cookie cookie =
  99.                 ApplicationSessionCookieConfig.createSessionCookie(
  100.                         context, session.getIdInternal(), isSecure());

  102.             response.addSessionCookieInternal(cookie);
  103.         }

  105.         if (session == null) {
  106.             return null;
  107.         }

  109.         session.access();
  110.         return session;
  111.     }


先看doGetSession方法中的如下代码，这个一般是第一次访问的情况，即创建session对象，session的创建是调用了ManagerBase的createSession方法来实现的; 另外，注意response.addSessionCookieInternal方法，该方法的功能就是上面提到的往响应头写入“Set-Cookie”信息；最后，还要调用session.access方法记录下该session的最后访问时间，因为session是可以设置过期时间的；

 

点击(此处)折叠或打开

  1. session = manager.createSession(sessionId);

  3.         // Creating a new session cookie based on that session
  4.         if ((session != null) && (getContext() != null)
  5.                && getContext().getServletContext().
  6.                        getEffectiveSessionTrackingModes().contains(
  7.                                SessionTrackingMode.COOKIE)) {
  8.             Cookie cookie =
  9.                 ApplicationSessionCookieConfig.createSessionCookie(
  10.                         context, session.getIdInternal(), isSecure());

  12.             response.addSessionCookieInternal(cookie);
  13.         }

  15.         if (session == null) {
  16.             return null;
  17.         }

  19.         session.access();
  20.         return session;
再看doGetSession方法中的如下代码，这个一般是第二次以后访问的情况，通过ManagerBase的findSession方法查找session，其实就是利用map的key从ConcurrentHashMap中拿取对应的value，这里的key即requestedSessionId，也即JSESSIONID，同时还要调用session.access方法，记录下该session的最后访问时间；

点击(此处)折叠或打开

  1. if (requestedSessionId != null) {
  2.             try {
  3.                 session = manager.findSession(requestedSessionId);
  4.             } catch (IOException e) {
  5.                 session = null;
  6.             }
  7.             if ((session != null) && !session.isValid()) {
  8.                 session = null;
  9.             }
  10.             if (session != null) {
  11.                 session.access();
  12.                 return (session);
  13.             }
  14.         }

在session对象中查找和设置key-value的方法

这个我们一般调用getAttribute/setAttribute方法：

getAttribute方法很简单，就是根据key从map中获取value；

setAttribute方法稍微复杂点，除了设置key-value外，如果添加了一些事件监听 （HttpSessionAttributeListener）的话，还要通知执行，如beforeSessionAttributeReplaced， afterSessionAttributeReplaced， beforeSessionAttributeAdded、 afterSessionAttributeAdded。。。

session存在的问题

  • 安全性，session劫持，这个前面已经举过例子了；
  • 增加服务器压力，因为session是直接存储在服务器的内存中的；
  • 如果存在多台服务器的话，还存在session同步问题，当然如果只有一台tomcat服务器的话，也就没有session同步的事情了，然而现 在一般的应用都会用到多台tomcat服务器，通过负载均衡，同一个会话有可能会被分配到不同的tomcat服务器，因此很可能出现session不一致 问题；解决session同步问题，实际上主要是保证能够抽离出一块共享空间存放session信息，且这块空间不同的tomcat服务器都可以访问到； 一般这块共享的空间可以是数据库，或者某台服务器的内存空间，甚至硬盘空间，或者客户端的cookie也是可以的；
  • http://www.cnblogs.com/chenpi/p/5434537.html#_label0
阅读(600) | 评论(0) | 转发(0) |
0

上一篇：服务器端session的实现机制

下一篇： Tomcat的Session管理

给主人留下些什么吧！~~
关于我们 | 关于IT168 | 联系方式 | 广告合作 | 法律声明 | 免费注册

Copyright 2001-2010 ChinaUnix.net All Rights Reserved 北京皓辰网域网络信息技术有限公司. 版权所有

感谢所有关心和支持过ChinaUnix的朋友们

16024965号-6