Tomcat中的Session与Cookie深入讲解
前言
http 是一种无状态通信协议,每个请求之间相互独立,服务器不能识别曾经来过的请求。而对于 web 应用,它的活动都是依赖某个状态的,比如用户登录,此时使用 http 就需要它在一次登录请求后,有为后续请求提供已登录信息的能力。本文首发于公众号顿悟源码.
解决办法就是使用 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 的请求它们头域的关键信息:
// 设置 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 应用特定用户的请求之间的状态信息。相关类图设计如下:
关键类或接口的作用如下:
- 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 的生成算法:
- 随机获取 16 个字节
- 使用 md5 加密这些字节,再次得到一个 16 字节的数组
- 遍历新的字节数组,使用每个字节的高低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 的实现进行分析。
总结
以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作具有一定的参考学习价值,谢谢大家对的支持。
上一篇: Nginx防御DDOS攻击的配置方法教程