前言
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"htmlcode">
// 设置 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/"htmlcode">
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 的实现进行分析。
总结
以上就是这篇文章的全部内容了，希望本文的内容对大家的学习或者工作具有一定的参考学习价值，谢谢大家对的支持。
免责声明：本站文章均来自网站采集或用户投稿，网站不提供任何软件下载或自行开发的软件！ 如有用户或公司发现本站内容信息存在侵权行为，请邮件告知！ 858582#qq.com
《魔兽世界》大逃杀！60人新游玩模式《强袭风暴》3月21日上线
暴雪近日发布了《魔兽世界》10.2.6 更新内容，新游玩模式《强袭风暴》即将于3月21 日在亚服上线，届时玩家将前往阿拉希高地展开一场 60 人大逃杀对战。
艾泽拉斯的冒险者已经征服了艾泽拉斯的大地及遥远的彼岸。他们在对抗世界上最致命的敌人时展现出过人的手腕，并且成功阻止终结宇宙等级的威胁。当他们在为即将于《魔兽世界》资料片《地心之战》中来袭的萨拉塔斯势力做战斗准备时，他们还需要在熟悉的阿拉希高地面对一个全新的敌人──那就是彼此。在《巨龙崛起》10.2.6 更新的《强袭风暴》中，玩家将会进入一个全新的海盗主题大逃杀式限时活动，其中包含极高的风险和史诗级的奖励。
《强袭风暴》不是普通的战场，作为一个独立于主游戏之外的活动，玩家可以用大逃杀的风格来体验《魔兽世界》，不分职业、不分装备（除了你在赛局中捡到的），光是技巧和战略的强弱之分就能决定出谁才是能坚持到最后的赢家。本次活动将会开放单人和双人模式，玩家在加入海盗主题的预赛大厅区域前，可以从强袭风暴角色画面新增好友。游玩游戏将可以累计名望轨迹，《巨龙崛起》和《魔兽世界：巫妖王之怒 经典版》的玩家都可以获得奖励。