會話跟蹤是一種靈活、輕便的機制，它使Web上的狀態程式設計變為可能。
HTTP是“無狀態”協議：客戶程式每次讀取 Web 頁面，都開啟到 Web 伺服器的單獨的連線，並且，伺服器也不自動維護客戶的上下文資訊。即使那些支援持續性 HTTP 連線的伺服器，儘管多個客戶請求連續發生且間隔很短時它們會保持 socket 開啟，但是，它們也沒有提供維護上下文資訊的內建支援。上下文的缺失引起許多困難。例如，線上商店的客戶向他們的購物車中加入商品時，伺服器如何知道購物車中己有何種物品呢？類似地，在客戶決定結賬時，伺服器如何能確定之前建立的購物車中哪個屬於此客戶呢？這些問題雖然看起來十分簡單，但是由於 HTTP 的不足，解答它們卻異常複雜困難。對於這個問題，存在 3 種典型的解決方案：
Cookie（結合session使用）
可以使用 cookie 儲存購物會話的 ID；在後續連線中，取出當前的會話 ID，並使用這個 ID 從伺服器上的查詢表（lookup table）中提取出會話的相關資訊。 以這種方式使用 cookie 是一種絕佳的解決方案，也是在處理會話時最常使用的方式。但是，sevlet 中最好有一種高階的 API 來處理所有這些任務，以及下面這些冗長乏味的任務：從眾多的其他cookie中（畢竟可能會存在許多cookie）提取出儲存會話識別符號的 cookie；確定空閒會話什麼時候過期，並回收它們；將散列表與每個請求關聯起來；生成惟一的會話識別符號。
URL 重寫
採用這種方式時，客戶程式在每個URL的尾部新增一些額外資料。這些資料標識當前的會話，伺服器將這個識別符號與它儲存的使用者相關資料關聯起來。 URL重寫是比較不錯的會話跟蹤解決方案，即使瀏覽器不支援 cookie 或在使用者禁用 cookie 的情況下，這種方案也能夠工作。URL 重寫具有 cookie 所具有的同樣缺點，也就是說，伺服器端程式要做許多簡單但是冗長乏味的處理任務。即使有高層的 API 可以處理大部分的細節，仍須十分小心每個引用你的站點的 URL ，以及那些返回給使用者的 URL。即使通過間接手段，比如伺服器重定向中的 Location 欄位，都要新增額外的資訊。這種限制意味著，在你的站點上不能有任何靜態 HTML 頁面（至少靜態頁面中不能有任何連結到站點動態頁面的連結）。因此，每個頁面都必須使用 servlet 或 JSP 動態生成。即使所有的頁面都動態生成，如果使用者離開了會話並通過書籤或連結再次回來，會話的資訊也會丟失，因為儲存下來的連結含有錯誤的標識資訊。
隱藏的表單域
HTML 表單中可以含有如下的條目：<input type="hidden" name="session" value="a1234">
這個條目的意思是：在提交表單時，要將指定的名稱和值自動包括在 GET 或 POST 資料中。這個隱藏域可以用來儲存有關會話的資訊，但它的主要缺點是：僅當每個頁面都是由表單提交而動態生成時，才能使用這種方法。單擊常規的超文字連結並不產生表單提交，因此隱藏的表單域不能支援通常的會話跟蹤，只能用於一系列特定的操作中，比如線上商店的結賬過程。