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_idvarchar(100) not null primary key, valid_sessionchar(1) not null, -- 是否有效 max_inactiveint not null,-- 最大有效時間 last_accessbigint not null, -- 最後訪問時間 app_namevarchar(255), -- 應用名,格式為 /Engine/Host/Context session_datamediumblob, -- 二進位制資料 KEY kapp_name(app_name) );
注意:需要把資料庫驅動程式的 jar 檔案,放到 $CATALINA_HOME/lib 目錄中,以便讓 Tomcat 內部的類載入器可見。
4. 小結
本文簡單分析了 Tomcat 對 Session 的管理,當然了忽略了很多細節,有興趣的可以深入原始碼,後續將會對 Tomcat 叢集 Session 的實現進行分析。如有疑問,歡迎留言交流。