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 的实现进行分析. 如有疑问, 欢迎留言交流.
来源: https://www.cnblogs.com/wskwbog/p/10846998.html