Tomcat 中的 Session 和 Cookie的爱恨情仇

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

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

[[265299]]

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

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

为了方便管理,服务器把整个过程称为会话,并抽象成一个 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 的请求它们头域的关键信息:

  1. // 设置 Cookie 
  2. HTTP/1.1 200 OK 
  3. Server: Apache-Coyote/1.1 
  4. Set-Cookie: JSESSIONID=56AE5B92C272EA4F5E0FBFEFE6936C91; Path=/examples 
  5. Date: Sun, 12 May 2019 01:40:35 GMT 
  6.  
  7. // 提交 Cookie 
  8. GET /examples/servlets/servlet/SessionExample HTTP/1.1 
  9. Host: localhost:8080 
  10. Cookie: JSESSIONID=56AE5B92C272EA4F5E0FBFEFE6936C91 

1.1 从 URL 重写路径

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

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

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

1.2 从 Cookie 头域

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

  1. CoyoteAdapter.service(Request, Response) 
  2. └─CoyoteAdapter.postParseRequest(Request, Request, Response, Response) 
  3.  └─CoyoteAdapter.parseSessionCookiesId(Request, Request) 
  4.   └─Cookies.getCookieCount() 
  5.    └─Cookies.processCookies(MimeHeaders) 
  6.     └─Cookies.processCookieHeader(byte[], intint

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

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

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

2. 生成会话 Cookie

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

  1. protected Session doGetSession(boolean create) { 
  2.   ... 
  3.   // 创建 Session 实例 
  4.   if (connector.getEmptySessionPath() && isRequestedSessionIdFromCookie()) { 
  5.     // 如果会话 ID 来自 cookie,请重用该 ID,如果来自 URL,请不要 
  6.     // 重用该会话ID,以防止可能的网络钓鱼
  7.     session = manager.createSession(getRequestedSessionId()); 
  8.   } else { 
  9.     session = manager.createSession(null); 
  10.   } 
  11.   // 基于该 Session 创建一个新的会话 cookie 
  12.   if ((session != null) && (getContext() != null
  13.        && getContext().getCookies()) { 
  14.     String scName = context.getSessionCookieName(); 
  15.     if (scName == null) { 
  16.       // 默认 JSESSIONID 
  17.       scName = Globals.SESSION_COOKIE_NAME; 
  18.     } 
  19.     // 新建 Cookie 
  20.     Cookie cookie = new Cookie(scName, session.getIdInternal()); 
  21.     // 设置 path domain secure 
  22.     configureSessionCookie(cookie); 
  23.     // 添加到响应头域 
  24.     response.addSessionCookieInternal(cookie, context.getUseHttpOnly()); 
  25.   } 
  26.   if (session != null) { 
  27.     session.access(); 
  28.     return (session); 
  29.   } else { 
  30.     return (null); 
  31.   } 

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

3. Session

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

 

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

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

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

3.1 创建 Session

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

  1. public Session createSession(String sessionId) { 
  2.   // 默认返回的是 new StandardSession(this) 实例 
  3.   Session session = createEmptySession(); 
  4.   // 初始化属性 
  5.   session.setNew(true); 
  6.   session.setValid(true); 
  7.   session.setCreationTime(System.currentTimeMillis()); 
  8.   // 设置会话有效时间,单位 秒,默认 30 分钟,为负值表示永不过期 
  9.   session.setMaxInactiveInterval(((Context) getContainer()).getSessionTimeout() * 60); 
  10.   if (sessionId == null) { 
  11.     // 生成一个会话 ID 
  12.     sessionId = generateSessionId(); 
  13.    
  14.   session.setId(sessionId); 
  15.   sessionCounter++; 
  16.  
  17.   SessionTiming timing = new SessionTiming(session.getCreationTime(), 0); 
  18.   synchronized (sessionCreationTiming) { 
  19.     sessionCreationTiming.add(timing); 
  20.     sessionCreationTiming.poll(); 
  21.   } 
  22.   return (session); 

关键就在于会话标识的生成,来看 Tomcat 的生成算法:

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

核心代码如下:

  1. protected String generateSessionId() { 
  2.   byte random[] = new byte[16]; 
  3.   String jvmRoute = getJvmRoute(); 
  4.   String result = null
  5.   // 将结果渲染为十六进制数字的字符串 
  6.   StringBuffer buffer = new StringBuffer(); 
  7.   do { 
  8.     int resultLenBytes = 0; 
  9.     if (result != null) { // 重复,重新生成 
  10.       buffer = new StringBuffer(); 
  11.       duplicates++; 
  12.     } 
  13.     // sessionIdLength 为 16 
  14.     while (resultLenBytes < this.sessionIdLength) { 
  15.       getRandomBytes(random);// 随机获取 16 个字节 
  16.       // 获取这16个字节的摘要,默认使用 MD5 
  17.       random = getDigest().digest(random); 
  18.       // 遍历这个字节数组,生成一个32位的十六进制字符串 
  19.       for (int j = 0; 
  20.       j < random.length && resultLenBytes < this.sessionIdLength; 
  21.       j++) { 
  22.         // 使用指定字节的高低4位分别生成一个十六进制字符 
  23.         byte b1 = (byte) ((random[j] & 0xf0) >> 4); 
  24.         byte b2 = (byte) (random[j] & 0x0f); 
  25.         // 转为十六进制数字字符 
  26.         if (b1 < 10) {buffer.append((char) ('0' + b1));} 
  27.         // 转为大写的十六进制字符 
  28.         else {buffer.append((char) ('A' + (b1 - 10)));} 
  29.          
  30.         if (b2 < 10) {buffer.append((char) ('0' + b2));} 
  31.         else {buffer.append((char) ('A' + (b2 - 10)));} 
  32.         resultLenBytes++; 
  33.       } 
  34.     } 
  35.     if (jvmRoute != null) {buffer.append('.').append(jvmRoute);} 
  36.     result = buffer.toString(); 
  37.   } while (sessions.containsKey(result)); 
  38.   return (result); 

3.2 Session 过期检查

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

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

  1. public boolean isValid() { 
  2.   ... 
  3.   // 是否检查是否活动,默认 false 
  4.   if (ACTIVITY_CHECK && accessCount.get() > 0) { 
  5.     return true
  6.   } 
  7.   // 检查时间是否过期 
  8.   if (maxInactiveInterval >= 0) {  
  9.     long timeNow = System.currentTimeMillis(); 
  10.     int timeIdle = (int) ((timeNow - thisAccessedTime) / 1000L); 
  11.     if (timeIdle >= maxInactiveInterval) { 
  12.       // 如果过期,执行一些内部处理 
  13.       // 主要是通知对过期事件感兴趣的 listeners 
  14.       expire(true); 
  15.     } 
  16.   } // 复数永不过期 
  17.   return (this.isValid); 

3.3 Session 持久化

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

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

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

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

  1. create table tomcat_sessions ( 
  2.   session_id     varchar(100) not null primary key
  3.   valid_session  char(1) not null-- 是否有效 
  4.   max_inactive   int not null,-- 有效时间 
  5.   last_access    bigint not null-- 访问时间 
  6.   app_name       varchar(255), -- 应用名,格式为 /Engine/Host/Context 
  7.   session_data   mediumblob, -- 二进制数据 
  8.   KEY kapp_name(app_name) 
  9. ); 

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

4. 小结

本文简单分析了 Tomcat 对 Session 的管理,当然了忽略的很多细节,有兴趣的可以深入源码,后续将会对 Tomcat 集群 Session 的实现进行分析。

 

责任编辑:武晓燕 来源: 顿悟源码
相关推荐

2022-09-02 12:13:22

TCPUDP场景

2022-05-13 09:47:28

Docker容器

2021-04-12 06:08:16

HiveSpark大数据

2020-11-24 10:13:20

测试开发管理

2024-08-07 08:22:27

2024-06-05 11:06:22

Go语言工具

2024-06-07 00:09:50

2014-08-18 09:31:15

2020-04-09 15:26:55

间谍软件NSOFacebook

2022-05-07 07:43:07

Redis存储系统数据库

2013-02-20 10:00:16

微软CodePlexGitHub

2021-06-16 06:48:06

接口微信

2024-03-11 09:37:01

模型图片编辑

2020-06-16 15:48:40

苹果英特尔芯片

2015-11-24 15:13:15

2015-11-05 09:55:40

SDNNFV

2020-05-27 14:07:21

蜂窝广域网局域物联网物联网

2023-10-24 09:07:14

CookieSessionHTTP

2023-10-27 08:23:10

CookieWeb存储

2010-05-06 15:24:35

Tomcat负载均衡
点赞
收藏

51CTO技术栈公众号