Tomcat 中的 Session 和 Cookie

wskwbog發表於2019-05-13
TomcatSessionCookie

HTTP 是一種無狀態通訊協議，每個請求之間相互獨立，伺服器不能識別曾經來過的請求。而對於 Web 應用，它的活動都是依賴某個狀態的，比如使用者登入，此時使用 HTTP 就需要它在一次登入請求後，有為後續請求提供已登入資訊的能力。本文首發於公眾號頓悟原始碼.

解決辦法就是使用 Cookie，它由伺服器返回給瀏覽器，瀏覽器快取並在每次請求時將 cookie 資料提交到伺服器。Cookies 在請求中以明文傳輸，且大小限制 4KB，顯然把所有狀態資料儲存在瀏覽器是不靠譜的，主流做法是：

  1. 瀏覽器發出第一個請求時，伺服器為使用者分配一個唯一識別符號，返回並存入瀏覽器的 Cookies 中
  2. 伺服器內部維護一個全域性的請求狀態庫，並使用生成的唯一識別符號關聯每個請求的狀態資訊
  3. 瀏覽器後續發出的請求，都將唯一識別符號提交給伺服器，以便獲取之前請求的狀態資訊

為了方便管理，伺服器把整個過程稱為會話，並抽象成一個 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() 方法，這裡不在貼出。

觸發 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 物件關聯。

與會話相關的 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 應用特定使用者的請求之間的狀態資訊。相關類圖設計如下：

Tomcat session 類圖

關鍵類或介面的作用如下：

  • 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 的生成演算法：

  1. 隨機獲取 16 個位元組
  2. 使用 MD5 加密這些位元組，再次得到一個 16 位元組的陣列
  3. 遍歷新的位元組陣列，使用每個位元組的高低4位分別生成一個十六進位制字元
  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 的實現進行分析。如有疑問，歡迎留言交流。

相關文章