溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
前言
HTTP 是一種無狀態通信協議，每個請求之間相互獨立，服務器不能識別曾經來過的請求。而對于 Web 應用，它的活動都是依賴某個狀態的，比如用戶登錄，此時使用 HTTP 就需要它在一次登錄請求后，有為后續請求提供已登錄信息的能力。本文首發于公眾號頓悟源碼.
解決辦法就是使用 Cookie，它由服務器返回給瀏覽器，瀏覽器緩存并在每次請求時將 cookie 數據提交到服務器。Cookies 在請求中以明文傳輸，且大小限制 4KB，顯然把所有狀態數據保存在瀏覽器是不靠譜的，主流做法是：
為了方便管理，服務器把整個過程稱為會話，并抽象成一個 Session 類，用于識別和存儲有關該用戶的信息或狀態。
接下來，將通過會話標識符的解析和生成，Session 的創建、銷毀和持久化等問題，分析 Tomcat 的源碼實現，版本使用的是 6.0.53。
1. 解析會話標識符
Cookie 作為最常用的會話跟蹤機制，所有的 Servlet 容器都支持，Tomcat 也不例外，在 Tomcat 中，表示存儲會話標識符的 cookie 的標準名字是 JSESSIONID。
如果如果瀏覽器不支持 Cookie，也可以使用以下辦法，記錄標識符：
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 應用特定用戶的請求之間的狀態信息。相關類圖設計如下：
關鍵類或接口的作用如下：
本文不分析集群復制的原理，只分析單機 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 的生成算法：
核心代碼如下：
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 的實現進行分析。
總結
以上就是這篇文章的全部內容了，希望本文的內容對大家的學習或者工作具有一定的參考學習價值，謝謝大家對億速云的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
