Tomcat 中的 Session 和 Cookie

古城微笑少年丶 2021-09-19 19:12 426阅读 0赞

HTTP 是一种**无状态**通信协议，每个请求之间相互独立，服务器不能识别**曾经来过**的请求。而对于 Web 应用，它的活动都是**依赖某个状态**的，比如用户登录，此时使用 HTTP 就需要它在一次登录请求后，有为后续请求提供已登录信息的能力。本文首发于公众号**顿悟源码**.

解决办法就是使用 **Cookie**，它由服务器返回给浏览器，浏览器缓存并在每次请求时将 cookie 数据提交到服务器。Cookies 在请求中以明文传输，且大小限制 4KB，显然把所有状态数据保存在浏览器是不靠谱的，主流做法是：

1.  浏览器发出第一个请求时，服务器为用户分配一个**唯一标识符**，返回并存入浏览器的 Cookies 中
2.  服务器内部维护一个全局的**请求状态库**，并使用生成的唯一标识符关联每个请求的状态信息
3.  浏览器后续发出的请求，都将唯一标识符提交给服务器，以便获取**之前**请求的状态信息

为了方便管理，服务器把整个过程称为**会话**，并抽象成一个 **Session** 类，用于识别和存储有关该用户的信息或状态。

接下来，将通过会话标识符的解析和生成，Session 的创建、销毁和持久化等问题，分析 Tomcat 的源码实现，版本使用的是 6.0.53。

## 1. 解析会话标识符 ##

Cookie 作为最常用的会话跟踪机制，所有的 Servlet 容器都支持，Tomcat 也不例外，在 Tomcat 中，表示存储会话标识符的 cookie 的标准名字是 **JSESSIONID**。

如果如果浏览器不支持 Cookie，也可以使用以下办法，记录标识符：

*  **URL 重写**: 作为**路径参数**包含到 url 中，如 /path;JSESSIONID=xxx
 *  **URL 请求参数**: 将会话唯一标识作为**查询参数**添加到页面所有链接中，如 /path?JSESSIONID=xxx
 *  **FORM 隐藏字段**: 表单中使用一个隐藏字段存储唯一值，随表单提交到服务器

Tomcat 就实现了从 URL 重写路径和 Cookie 中提取 JSESSIONID。在分析源码之前，首先看下设置 Cookie 的响应和带 Cookie 的请求它们头域的关键信息：

// 设置 Cookie
    HTTP/1.1 200 OK
    Server: Apache-Coyote/1.1
    Set-Cookie: JSESSIONID=56AE5B92C272EA4F5E0FBFEFE6936C91; Path=/examples
    Date: Sun, 12 May 2019 01:40:35 GMT
    
    // 提交 Cookie
    GET /examples/servlets/servlet/SessionExample HTTP/1.1
    Host: localhost:8080
    Cookie: JSESSIONID=56AE5B92C272EA4F5E0FBFEFE6936C91

### 1.1 从 URL 重写路径 ###

一个包含会话 ID 路径参数的 URL 如下：

http://localhost:8080/examples/SessionExample;JSESSIONID=1234;n=v/?x=x

简单来看就是查找匹配分号和最后一个斜线之间的 JSESSIONID，事实也是如此，只不过 Tomcat 操作的是字节，核心代码在 CoyoteAdapter.parsePathParameters() 方法，这里不在贴出。

### 1.2 从 Cookie 头域 ###

触发 Cookie 解析的方法调用如下：

CoyoteAdapter.service(Request, Response)
    └─CoyoteAdapter.postParseRequest(Request, Request, Response, Response)
     └─CoyoteAdapter.parseSessionCookiesId(Request, Request)
      └─Cookies.getCookieCount()
       └─Cookies.processCookies(MimeHeaders)
        └─Cookies.processCookieHeader(byte[], int, int)

这个 processCookieHeader 操作的是字节，解析看起来不直观，在 Tomcat 内部还有一个被标记废弃的使用字符串解析的方法，有助于理解，代码如下：

private void processCookieHeader(  String cookieString ){
      // 多个 cookie 值以逗号分割
      StringTokenizer tok = new StringTokenizer(cookieString, ";", false);
      while (tok.hasMoreTokens()) {
        String token = tok.nextToken();
        // 获取等号的位置
        int i = token.indexOf("=");
        if (i > -1) {
          // 获取name 和 value 并去除空格
          String name = token.substring(0, i).trim();
          String value = token.substring(i+1, token.length()).trim();
          // RFC 2109 and bug 去除两头的双引号 "
          value=stripQuote( value );
          // 从内部 cookie 缓存池中获取一个 ServerCookie 对象
          ServerCookie cookie = addCookie();
          // 设置 name 和 value
          cookie.getName().setString(name);
          cookie.getValue().setString(value);
        } else {
          // we have a bad cookie.... just let it go
        }
      }
    }

解析完毕，接下来就是在 parseSessionCookiesId 方法遍历并尝试匹配名称为 JSESSIONID 的 Cookie，如果存在，则将其值设为 Request 的 requestedSessionId，与内部的一个 Session 对象关联。

## 2. 生成会话 Cookie ##

与会话相关的 Cookie 是 Tomcat 内部自己生成的，当在 Servlet 中使用 Request.getSession() 获取会话对象时，就会触发执行，核心代码：

protected Session doGetSession(boolean create) {
      ...
      // 创建 Session 实例
      if (connector.getEmptySessionPath() && isRequestedSessionIdFromCookie()) {
        // 如果会话 ID 来自 cookie，请重用该 ID，如果来自 URL，请不要
        // 重用该会话ID，以防止可能的网络钓鱼攻击
        session = manager.createSession(getRequestedSessionId());
      } else {
        session = manager.createSession(null);
      }
      // 基于该 Session 创建一个新的会话 cookie
      if ((session != null) && (getContext() != null)
           && getContext().getCookies()) {
        String scName = context.getSessionCookieName();
        if (scName == null) {
          // 默认 JSESSIONID
          scName = Globals.SESSION_COOKIE_NAME;
        }
        // 新建 Cookie
        Cookie cookie = new Cookie(scName, session.getIdInternal());
        // 设置 path domain secure
        configureSessionCookie(cookie);
        // 添加到响应头域
        response.addSessionCookieInternal(cookie, context.getUseHttpOnly());
      }
      if (session != null) {
        session.access();
        return (session);
      } else {
        return (null);
      }
    }

添加到响应头域，就是根据 Cookie 对象，生成如开始描述的格式那样。

## 3. Session ##

Session 是 Tomcat 内部的一个接口，是 HttpSession 的外观类，用于维护 web 应用特定用户的请求之间的状态信息。相关类图设计如下：

![Tomcat session 类图][Tomcat session]

关键类或接口的作用如下：

*  **Manager** - 管理 Session 池，不同的实现提供特定的功能，如持久化和分布式
 *  **ManagerBase** - 实现了一些基本功能，如 Session 池，唯一ID生成算法，便于继承扩展
 *  **StandardManager** - 标准实现，可在此组件重新启动时提供简单的会话持久性（例如，当整个服务器关闭并重新启动时，或重新加载特定Web应用程序时）
 *  **PersistentManagerBase** - 提供多种不同的持久化存储管理方式，如文件和数据库
 *  **Store** - 提供持久化存储和加载会话和用户信息
 *  **ClusterManager** - 集群 session 管理接口，负责会话的复制方式
 *  **DeltaManager** - 将会话数据增量复制到集群中的所有成员
 *  **BackupManager** - 将数据只复制到一个备份节点，集群中所有成员可看到这个节点

本文不分析集群复制的原理，只分析单机 Session 的管理。

### 3.1 创建 Session ###

在 Servlet 中首次使用 Request.getSession() 获取会话对象时，会创建一个 StandardSession 实例：

public Session createSession(String sessionId) {
      // 默认返回的是 new StandardSession(this) 实例
      Session session = createEmptySession();
      // 初始化属性
      session.setNew(true);
      session.setValid(true);
      session.setCreationTime(System.currentTimeMillis());
      // 设置会话有效时间，单位 秒，默认 30 分钟，为负值表示永不过期
      session.setMaxInactiveInterval(((Context) getContainer()).getSessionTimeout() * 60);
      if (sessionId == null) {
        // 生成一个会话 ID
        sessionId = generateSessionId();
      
      session.setId(sessionId);
      sessionCounter++;
    
      SessionTiming timing = new SessionTiming(session.getCreationTime(), 0);
      synchronized (sessionCreationTiming) {
        sessionCreationTiming.add(timing);
        sessionCreationTiming.poll();
      }
      return (session);
    }

关键就在于会话唯一标识的生成，来看 Tomcat 的**生成算法**：

1.  随机获取 16 个字节
2.  使用 MD5 加密这些字节，再次得到一个 16 字节的数组
3.  遍历新的字节数组，使用每个字节的高低4位分别生成一个十六进制字符
4.  最后得到一个 32 位的十六进制字符串

核心代码如下：

protected String generateSessionId() {
      byte random[] = new byte[16];
      String jvmRoute = getJvmRoute();
      String result = null;
      // 将结果渲染为十六进制数字的字符串
      StringBuffer buffer = new StringBuffer();
      do {
        int resultLenBytes = 0;
        if (result != null) { // 重复，重新生成
          buffer = new StringBuffer();
          duplicates++;
        }
        // sessionIdLength 为 16
        while (resultLenBytes < this.sessionIdLength) {
          getRandomBytes(random);// 随机获取 16 个字节
          // 获取这16个字节的摘要，默认使用 MD5
          random = getDigest().digest(random);
          // 遍历这个字节数组，最后生成一个32位的十六进制字符串
          for (int j = 0;
          j < random.length && resultLenBytes < this.sessionIdLength;
          j++) {
            // 使用指定字节的高低4位分别生成一个十六进制字符
            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 (jvmRoute != null) {buffer.append('.').append(jvmRoute);}
        result = buffer.toString();
      } while (sessions.containsKey(result));
      return (result);
    }

### 3.2 Session 过期检查 ###

一个 Web 应用对应一个会话管理器，也就是说 StandardContext 内部有一个 Manager 实例。每个容器组件都会启动一个后台线程，周期的调用自身以及内部组件的 backgroundProcess() 方法，Manager 后台处理就是检查 Session 是否过期。

检查的逻辑是，获取所有 session 使用它的 isValid 判断是否过期，代码如下：

public boolean isValid() {
      ...
      // 是否检查是否活动，默认 false
      if (ACTIVITY_CHECK && accessCount.get() > 0) {
        return true;
      }
      // 检查时间是否过期
      if (maxInactiveInterval >= 0) { 
        long timeNow = System.currentTimeMillis();
        int timeIdle = (int) ((timeNow - thisAccessedTime) / 1000L);
        if (timeIdle >= maxInactiveInterval) {
          // 如果过期，执行一些内部处理
          // 主要是通知对过期事件感兴趣的 listeners
          expire(true);
        }
      } // 复数永不过期
      return (this.isValid);
    }

### 3.3 Session 持久化 ###

持久化就是把内存中活动的 Session 对象，序列化到文件，或者存储到一个数据库中。如果会话管理组件符合并启用了持久化功能，那么就会在它生命周期事件 stop 方法中执行存储；在 start 方法中执行加载。

**持久化到文件**，StandardManager 也提供了持久化到文件的功能，它会把 session 池中活动的会话全部写入到`CATALINA_HOME/work/Catalina/<host>/<webapp>/SESSIONS.ser`文件中，代码在它的 doUnload 方法中。

FileStore 也提供了持久化到文件的功能，与 StandardManager 的区别是，它会把每个会话写入到单个文件中，以 <id>.session 命名。

**持久化到数据库**，分别把 session 相关数据存储到一个表中，包括序列化后的二进制数据，表字段信息如下:

create table tomcat_sessions (
      session_id     varchar(100) not null primary key,
      valid_session  char(1) not null, -- 是否有效
      max_inactive   int not null,-- 最大有效时间
      last_access    bigint not null, -- 最后访问时间
      app_name       varchar(255), -- 应用名，格式为 /Engine/Host/Context
      session_data   mediumblob, -- 二进制数据
      KEY kapp_name(app_name)
    );

注意：需要把数据库驱动程序的 jar 文件，放到 $CATALINA\_HOME/lib 目录中，以便让 Tomcat 内部的类加载器可见。

## 4. 小结 ##

本文简单分析了 Tomcat 对 Session 的管理，当然了忽略了很多细节，有兴趣的可以深入源码，后续将会对 Tomcat 集群 Session 的实现进行分析。如有疑问，欢迎留言交流。

如果你对编程感兴趣或者想往编程方向发展，可以关注微信公众号【筑梦编程】，大家一起交流讨论！小编也会每天定时更新既有趣又有用的编程知识！

[Tomcat session]: /images/20210812/d1930e34c3e64af68af06dd020af5f96.png