Tomcat Session总结及底层实现

忘是亡心i 2022-02-01 04:13 132阅读 0赞

# @Author      [风一样的码农][Link 1]   @HomePageUrl [http://www.cnblogs.com/chenpi/][Link 1]   @Copyright      [转载请注明出处，谢谢~][Link 1] #

# 阅读目录 #

什么是Session

Session的目的

实现机制

Tomcat中的session实现

第一次访问时新建session（此部分为原创）

session存在的问题

--------------------

# 什么是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，如下图：

![879896-20160426134020033-804000343.jpg][]

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

![879896-20160426134717939-589166478.jpg][]

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

![879896-20160426134352533-877696732.jpg][]

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

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

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

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

/**
         * @see HttpServlet#doGet(HttpServletRequest request, HttpServletResponse response)
         */
        protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
            
            if(request.getSession().getAttribute("count") == null){
                request.getSession().setAttribute("count", 0);
                response.getWriter().write(0+"");
            }else{
                int a = Integer.parseInt(request.getSession().getAttribute("count").toString());
                request.getSession().setAttribute("count", ++a);
                response.getWriter().write(a+"");
            }
    
            Cookie[] cookies = request.getCookies();
            StringBuffer sb = new StringBuffer();
            if(cookies!=null){
                for(Cookie cookie : cookies){
                    sb.append(cookie.getName()+":"+cookie.getValue()+",");
                }
                sb.deleteCharAt(sb.length()-1);
            }
    
            System.out.println("[第"+(++index)+"次访问]from client request, cookies:" + sb);
            System.out.println("[第"+(index)+"次访问]from server response, header-Set-Cookie:" + response.getHeader("Set-Cookie"));;
        }

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

![879896-20160426135934798-75879859.jpg][]

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

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

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

![879896-20160426141424220-312081427.jpg][]

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

![879896-20160426141554189-111225776.jpg][]

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

![879896-20160426142418330-1668278293.jpg][]

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

![879896-20160426143622220-1059986512.jpg][]

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

![879896-20160426143835236-955366271.jpg][]

# Tomcat中的session实现 #

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

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

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

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

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

## **服务器查找Session对象的方法** ##

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

protected Session doGetSession(boolean create) {
    
            // There cannot be a session if no context has been assigned yet
            Context context = getContext();
            if (context == null) {
                return (null);
            }
    
            // Return the current session if it exists and is valid
            if ((session != null) && !session.isValid()) {
                session = null;
            }
            if (session != null) {
                return (session);
            }
    
            // Return the requested session if it exists and is valid
            Manager manager = context.getManager();
            if (manager == null) {
                return null;        // Sessions are not supported
            }
            if (requestedSessionId != null) {
                try {
                    session = manager.findSession(requestedSessionId);
                } catch (IOException e) {
                    session = null;
                }
                if ((session != null) && !session.isValid()) {
                    session = null;
                }
                if (session != null) {
                    session.access();
                    return (session);
                }
            }
    
            // Create a new session if requested and the response is not committed
            if (!create) {
                return (null);
            }
            if ((context != null) && (response != null) &&
                context.getServletContext().getEffectiveSessionTrackingModes().
                        contains(SessionTrackingMode.COOKIE) &&
                response.getResponse().isCommitted()) {
                throw new IllegalStateException
                  (sm.getString("coyoteRequest.sessionCreateCommitted"));
            }
    
            // Re-use session IDs provided by the client in very limited
            // circumstances.
            String sessionId = getRequestedSessionId();
            if (requestedSessionSSL) {
                // If the session ID has been obtained from the SSL handshake then
                // use it.
            } else if (("/".equals(context.getSessionCookiePath())
                    && isRequestedSessionIdFromCookie())) {
                /* This is the common(ish) use case: using the same session ID with
                 * multiple web applications on the same host. Typically this is
                 * used by Portlet implementations. It only works if sessions are
                 * tracked via cookies. The cookie must have a path of "/" else it
                 * won't be provided to for requests to all web applications.
                 *
                 * Any session ID provided by the client should be for a session
                 * that already exists somewhere on the host. Check if the context
                 * is configured for this to be confirmed.
                 */
                if (context.getValidateClientProvidedNewSessionId()) {
                    boolean found = false;
                    for (Container container : getHost().findChildren()) {
                        Manager m = ((Context) container).getManager();
                        if (m != null) {
                            try {
                                if (m.findSession(sessionId) != null) {
                                    found = true;
                                    break;
                                }
                            } catch (IOException e) {
                                // Ignore. Problems with this manager will be
                                // handled elsewhere.
                            }
                        }
                    }
                    if (!found) {
                        sessionId = null;
                    }
                    sessionId = getRequestedSessionId();
                }
            } else {
                sessionId = null;
            }
            session = manager.createSession(sessionId);
    
            // Creating a new session cookie based on that session
            if ((session != null) && (getContext() != null)
                   && getContext().getServletContext().
                           getEffectiveSessionTrackingModes().contains(
                                   SessionTrackingMode.COOKIE)) {
                Cookie cookie =
                    ApplicationSessionCookieConfig.createSessionCookie(
                            context, session.getIdInternal(), isSecure());
    
                response.addSessionCookieInternal(cookie);
            }
    
            if (session == null) {
                return null;
            }
    
            session.access();
            return session;
        }

## 第一次访问时新建session（此部分为原创） ##

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

// Create a new session if requested and the response is not committed
            if (!create) {
                return null;
            }
            if (response != null
                    && context.getServletContext()
                            .getEffectiveSessionTrackingModes()
                            .contains(SessionTrackingMode.COOKIE)
                    && response.getResponse().isCommitted()) {
                throw new IllegalStateException(
                        sm.getString("coyoteRequest.sessionCreateCommitted"));
            }
    
            // Re-use session IDs provided by the client in very limited
            // circumstances.
            //默认为null
            String sessionId = getRequestedSessionId();
            if (requestedSessionSSL) {
                // If the session ID has been obtained from the SSL handshake then
                // use it.
            } else if (("/".equals(context.getSessionCookiePath())
                    && isRequestedSessionIdFromCookie())) {
                /* This is the common(ish) use case: using the same session ID with
                 * multiple web applications on the same host. Typically this is
                 * used by Portlet implementations. It only works if sessions are
                 * tracked via cookies. The cookie must have a path of "/" else it
                 * won't be provided for requests to all web applications.
                 *
                 * Any session ID provided by the client should be for a session
                 * that already exists somewhere on the host. Check if the context
                 * is configured for this to be confirmed.
                 */
                //此处是为了跨浏览器相同sessionID的访问
                if (context.getValidateClientProvidedNewSessionId()) {
                    boolean found = false;
                    for (Container container : getHost().findChildren()) {
                        Manager m = ((Context) container).getManager();
                        if (m != null) {
                            try {
                                if (m.findSession(sessionId) != null) {
                                    found = true;
                                    break;
                                }
                            } catch (IOException e) {
                                // Ignore. Problems with this manager will be
                                // handled elsewhere.
                            }
                        }
                    }
                    if (!found) {
                        sessionId = null;
                    }
                }
            } else {
                sessionId = null;
            }
    
            //调用创建session的方法，此时sessionID有两种情况，一种是新建session，sessionID为null
            //第二种比较少见，跨浏览器使用原来已存在的sessinID
            session = manager.createSession(sessionId);
    
            // Creating a new session cookie based on that session
            if ((session != null) && (getContext() != null)
                   && getContext().getServletContext().
                           getEffectiveSessionTrackingModes().contains(
                                   SessionTrackingMode.COOKIE)) {
                Cookie cookie =
                    ApplicationSessionCookieConfig.createSessionCookie(
                            context, session.getIdInternal(), isSecure());
                //response添加session cookie
                response.addSessionCookieInternal(cookie);
            }
    
            if (session == null) {
                return null;
            }
    
            session.access();
            return session;

我们进入createSession(sessionId)方法一探究竟，位于org.apache.catalina.session.ManagerBase中

//org.apache.catalina.session.ManagerBase 
    
    @Override
        public Session createSession(String sessionId) {
    
            if ((maxActiveSessions >= 0) &&
                    (getActiveSessions() >= maxActiveSessions)) {
                rejectedSessions++;
                throw new TooManyActiveSessionsException(
                        sm.getString("managerBase.createSession.ise"),
                        maxActiveSessions);
            }
    
            // Recycle or create a Session instance
            Session session = createEmptySession();
    
            // Initialize the properties of the new session and return it
            session.setNew(true);
            session.setValid(true);
            session.setCreationTime(System.currentTimeMillis());
            session.setMaxInactiveInterval(getContext().getSessionTimeout() * 60);
            String id = sessionId;
            if (id == null) {
                //注意一下这个方法，因为大部分时候传入这里的sessionId都是null，而不是夸浏览器使用相同sessionID的情况
                id = generateSessionId();
            }
            session.setId(id);
            sessionCounter++;
    
            SessionTiming timing = new SessionTiming(session.getCreationTime(), 0);
            synchronized (sessionCreationTiming) {
                sessionCreationTiming.add(timing);
                sessionCreationTiming.poll();
            }
            return session;
        }

**其中我们要注意一下生成generateSessionId()这个方法，**因为大部分时候传入这里的sessionId都是null，而不是夸浏览器使用相同sessionID的情况。让我们看看他是怎么生成sessionID的。这个方法同样在org.apache.catalina.session.ManagerBase中

//org.apache.catalina.session.ManagerBase
    
      /**
         * Generate and return a new session identifier.
         * @return a new session id
         */
        protected String generateSessionId() {
    
            String result = null;
    
            do {
                if (result != null) {
                    // Not thread-safe but if one of multiple increments is lost
                    // that is not a big deal since the fact that there was any
                    // duplicate is a much bigger issue.
                    duplicates++;
                }
    
                //SessionIdGenerator类实例方法
                result = sessionIdGenerator.generateSessionId();
    
            } while (sessions.containsKey(result));
    
            return result;
        }

可以看到这里面考虑到了高并发情况下，通过while循环检测防止产生相同的sessionID。而产生sessionID的方法又交给了sessionIdGenerator.generateSessionId()方法，让我们继续进入一探究竟（马上要看到庐山真面目啦?）。

//org.apache.catalina.util.SessionIdGeneratorBase
    
    /**
         * Generate and return a new session identifier.
         */
        @Override
        public String generateSessionId() {
            //jvmRoute默认为null
            return generateSessionId(jvmRoute);
        }

在org.apache.catalina.util.SessionIdGeneratorBase类中，generateSessionId()，方法调用generateSessionId(jvmRoute)方法，jvmRoute属性默认为null。

看了一堆调用之后我们来到了真的的生成sessionId的地方,位于org.apache.catalina.util.StandardSessionIdGenerator类中的generateSessionId(String route)方法，这个类继承自上面?的类

package org.apache.catalina.util;
    
    public class StandardSessionIdGenerator extends SessionIdGeneratorBase {
    
        @Override
        public String generateSessionId(String route) {
    
            byte random[] = new byte[16];
            int sessionIdLength = getSessionIdLength();
    
            // Render the result as a String of hexadecimal digits
            // Start with enough space for sessionIdLength and medium route size
            StringBuilder buffer = new StringBuilder(2 * sessionIdLength + 20);
    
            int resultLenBytes = 0;
    
            while (resultLenBytes < sessionIdLength) {
    
                //生成SecureRandom并保存在属性randoms队列当中
                getRandomBytes(random);
                for (int j = 0;
                j < random.length && resultLenBytes < sessionIdLength;
                j++) {
                    byte b1 = (byte) ((random[j] & 0xf0) >> 4);
                    byte b2 = (byte) (random[j] & 0x0f);
                    if (b1 < 10)
                        buffer.append((char) ('0' + b1));
                    else
                        buffer.append((char) ('A' + (b1 - 10)));
                    if (b2 < 10)
                        buffer.append((char) ('0' + b2));
                    else
                        buffer.append((char) ('A' + (b2 - 10)));
                    resultLenBytes++;
                }
            }
    
            if (route != null && route.length() > 0) {
                buffer.append('.').append(route);
            } else {
                String jvmRoute = getJvmRoute();
                if (jvmRoute != null && jvmRoute.length() > 0) {
                    buffer.append('.').append(jvmRoute);
                }
            }
    
            return buffer.toString();
        }
    }

这里他主要做的事情首先是在getRandomBytes(byte\[16\])方法中生成SecureRandom实例，并保存在属性randoms队列当中，同时初始化这个长度为16的byte数组。至于SecureRandom的作用是提供一个加密的强随机数生成器(RNG)，大概使用方法是

SecureRandom random = new SecureRandom();        
    byte bytes[] = new byte[20];         
    random.nextBytes(bytes);

其实最有意思的是后面这个for循环，因为现在生成的bytes数组如果按照字符打印出来大概是第一行的样子

![20190513155420550.png][]

通过for循环确保他们是字母和数字组合，好了首次创建session的大概过程就是这样子。

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

if (requestedSessionId != null) {
                try {
                    session = manager.findSession(requestedSessionId);
                } catch (IOException e) {
                    session = null;
                }
                if ((session != null) && !session.isValid()) {
                    session = null;
                }
                if (session != null) {
                    session.access();
                    return (session);
                }
            }

## **在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也是可以的；

[Link 1]: http://www.cnblogs.com/chenpi/
[879896-20160426134020033-804000343.jpg]: /images/20220201/4265edaf4f774262aeaa9c5212280afc.png
[879896-20160426134717939-589166478.jpg]: /images/20220201/7249082aa6b348c88421f1cee8666be6.png
[879896-20160426134352533-877696732.jpg]: /images/20220201/82bd01d2386d4c2aafbf00a233b132f7.png
[879896-20160426135934798-75879859.jpg]: /images/20220201/4fc8ce0892ed4fd2a5ec974536cfbc50.png
[879896-20160426141424220-312081427.jpg]: /images/20220201/fe7b6fe6479a459e88b93ec7a3116690.png
[879896-20160426141554189-111225776.jpg]: /images/20220201/06138580fa5f4e879b8f22070dfc5d23.png
[879896-20160426142418330-1668278293.jpg]: /images/20220201/68b43928edc447ce9afdab55a3c05f64.png
[879896-20160426143622220-1059986512.jpg]: /images/20220201/70d2789b820f4f498ca8e98d70cd6410.png
[879896-20160426143835236-955366271.jpg]: /images/20220201/00adf99ab1d54e88bbb9584944ce78a4.png
[20190513155420550.png]: /images/20220201/eac7739e737940d38f574208fe67ce76.png