Tomcat 中的 Session 和 Cookie

時間 2019-12-09

原文原文鏈接

HTTP 是一種無狀態通訊協議，每一個請求之間相互獨立，服務器不能識別曾經來過的請求。而對於 Web 應用，它的活動都是依賴某個狀態的，好比用戶登陸，此時使用 HTTP 就須要它在一次登陸請求後，有爲後續請求提供已登陸信息的能力。本文首發於公衆號頓悟源碼.java

解決辦法就是使用 Cookie，它由服務器返回給瀏覽器，瀏覽器緩存並在每次請求時將 cookie 數據提交到服務器。Cookies 在請求中以明文傳輸，且大小限制 4KB，顯然把全部狀態數據保存在瀏覽器是不靠譜的，主流作法是：web

瀏覽器發出第一個請求時，服務器爲用戶分配一個惟一標識符，返回並存入瀏覽器的 Cookies 中
服務器內部維護一個全局的請求狀態庫，並使用生成的惟一標識符關聯每一個請求的狀態信息
瀏覽器後續發出的請求，都將惟一標識符提交給服務器，以便獲取以前請求的狀態信息

爲了方便管理，服務器把整個過程稱爲會話，並抽象成一個 Session 類，用於識別和存儲有關該用戶的信息或狀態。算法

接下來，將經過會話標識符的解析和生成，Session 的建立、銷燬和持久化等問題，分析 Tomcat 的源碼實現，版本使用的是 6.0.53。sql

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() 方法，這裏不在貼出。tomcat

觸發 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 應用特定用戶的請求之間的狀態信息。相關類圖設計以下：

關鍵類或接口的做用以下：

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 內部的類加載器可見。