關於 PHP 中 Session 的幾個問題

什麼是 Session

在 web 應用開發中，Session 被稱為會話。主要被用於儲存某個訪問者的資料。
由於 HTTP 無狀態的特點，服務端是不會記住用戶端的，對服務端來說，每一個請求都是全新的。
既然如此，那麼服務端怎麼知道是哪個訪問者在請求它呢？又如何將不同的資料對應上正確的訪問者？答案是，給訪問者一個唯一擷取 Session 中資料的身份標示。

打個比方：當我們去超市購物時，被保安告之我們是不能帶物品進去的，必須將物品寄放在超市的儲物箱中。我們把物品交給了他，他怎麼知道這些物品誰是誰的，於是他給了我們不同的鑰匙。當我們要取走我們的物品時，用唯一的鑰匙開啟對應的箱子即可。

就如同上面的比方一樣，可以將 Session 理解為存放我們資料的“箱子”，當然，這些“箱子”都在服務端那。伺服器給訪問者唯一的“鑰匙”，這個“鑰匙”被稱作 session_id。訪問者憑藉自己的 session_id，就能擷取到自己存在伺服器端的資料。

session_id 通過兩種方式傳給訪問者（用戶端）：URL 或 cookie。詳情參見：傳送會話ID

Session 和 Cookie 有什麼關係

Cookie 也是由於 HTTP 無狀態的特點而產生的技術。也被用於儲存訪問者的身份標示和一些資料。每次用戶端發起 HTTP 要求時，會將 Cookie 資料加到 HTTP header 中，提交給服務端。這樣服務端就可以根據 Cookie 的內容知道訪問者的資訊了。
可以說，Session 和 Cookie 做著相似的事情，只是 Session 是將資料儲存在服務端，通過用戶端提交來的 session_id 來擷取對應的資料；而 Cookie 是將資料儲存在用戶端，每次發起請求時將資料提交給服務端的。

上面提到，session_id 可以通過 URL 或 cookie 來傳遞，由於 URL 的方式比 cookie 的方式更加不安全且使用不方便，所以一般是採用 cookie 來傳遞 session_id。
服務端產生 session_id，通過 HTTP 報文發送給用戶端（比如瀏覽器），用戶端收到後按指示建立儲存著 session_id 的 cookie。cookie 是以 key/value 形式儲存的，看上去大概就這個樣子的：PHPSESSID=e4tqo2ajfbqqia9prm8t83b1f2。在 PHP 中，儲存 session_id 的 cookie 名稱預設叫作 PHPSESSID，這個名稱可以通過 php.ini 中 session.name 來修改，也可以通過函數 session_name() 來修改。

為什麼不推薦使用 PHP 內建的 files 型 Session 處理器

在 PHP 中，預設的 Session 處理器是 files，處理器可以使用者自己實現（參見：自訂會話管理器）。我知道的成熟的 Session 處理器還有很多：Redis、Memcached、MongoDB……
為什麼不推薦使用 PHP 內建的 files 類型處理器，PHP 官方手冊中給出過這樣一段 Note：

無論是通過調用函數 session_start() 手動開啟會話， 還是使用配置項 session.auto_start 自動開啟會話， 對於基於檔案的會話資料儲存（PHP 的預設行為）而言， 在會話開始的時候都會給會話資料檔案加鎖， 直到 PHP 指令碼執行完畢或者顯式調用 session_write_close() 來儲存會話資料。 在此期間，其他指令碼不可以訪問同一個會話資料檔案。

上述引用參見：Session 的基本用法

為了證明這段話，我們建立一下 2 個檔案：
檔案：session1.php

php

檔案：session2.php

php

在同一個瀏覽器中，先訪問 http://127.0.0.1/session1.php，然後在當前瀏覽器新的標籤頁立刻訪問 http://127.0.0.1/session2.php。實驗發現，session1.php 等了 5 秒鐘才有輸出，而 session2.php 也等到了將近 5 秒才有輸出。而單獨訪問 session2.php 是秒開的。在一個瀏覽器中訪問 session1.php，然後立刻在另外一個瀏覽器中訪問 session2.php。結果是 session1.php 等待 5 秒鐘有輸出，而 session2.php 是秒開的。

分析一下造成這個現象的原因：上面例子中，預設使用 Cookie 來傳遞 session_id，而且 Cookie 的範圍是相同。這樣，在同一個瀏覽器中訪問這 2 個地址，提交給伺服器的 session_id 就是相同的（這樣才能標記訪問者，這是我們期望的效果）。當訪問 session1.php 時，PHP 根據提交的 session_id，在伺服器儲存 Session 檔案的路徑（預設為 /tmp，通過 php.ini 中的 session.save_path 或者函數 session_save_path() 來修改）中找到了對應的 Session 檔案，並對其加鎖。如果不顯式調用 session_write_close()，那麼直到當前 PHP 指令碼執行完畢才會釋放檔案鎖。如果在指令碼中有比較耗時的操作（比如例子中的 sleep(5)），那麼另一個持有相同 session_id 的請求由於檔案被鎖，所以只能被迫等待，於是就發生了請求阻塞的情況。

既然如此，在使用完 Session 後，立刻顯示調用 session_write_close() 是不是就解決問題了哩？比如上面例子中，在 sleep(5) 前面調用 session_write_close()。
確實，這樣 session2.php 就不會被 session1.php 所阻塞。但是，顯示調用了 session_write_close() 就意味著將資料寫到檔案中並結束當前會話。那麼，在後面代碼中要使用 Session 時，必須重新調用 session_start()。

例如：

php

官方給出的方案：

對於大量使用 Ajax 或者並發請求的網站而言，這可能是一個嚴重的問題。 解決這個問題最簡單的做法是如果修改了會話中的變數， 那麼應該儘快調用 session_write_close() 來儲存會話資料並釋放檔案鎖。 還有一種選擇就是使用支援並行作業的會話儲存管理器來替代檔案會話儲存管理器。

我推薦的方式是使用 Redis 作為 Session 的處理器。

拓展閱讀：

為什麼不能用 memcached 儲存 Session

如何使用 Redis 作為 PHP Session handler

Session 資料是什麼時候被刪除的

這是一道經常被面試官問起的問題。

先看看官方手冊中的說明：

session.gc_maxlifetime 指定過了多少秒之後資料就會被視為"垃圾"並被清除。 垃圾搜集可能會在 session 啟動的時候開始（ 取決於 session.gc_probability 和 session.gc_divisor）。 session.gc_probability 與 session.gc_divisor 合起來用來管理 gc（garbage collection 記憶體回收）進程啟動的機率。此機率用 gc_probability/gc_divisor 計算得來。例如 1/100 意味著在每個請求中有 1% 的機率啟動 gc 進程。session.gc_probability 預設為 1，session.gc_divisor 預設為 100。

繼續用我上面那個不太恰當的比方吧：如果我們把物品放在超市的儲物箱中而不取走，過了很久（比如一個月），那麼保安就要清理這些儲物箱中的物品了。當然並不是超到期限了保安就一定會來清理，也許他懶，又或者他壓根就沒有想起來這件事情。

再看看兩段手冊的引用：

如果使用預設的基於檔案的會話處理器，則檔案系統必須保持跟蹤訪問時間（atime）。Windows FAT 檔案系統不行，因此如果必須使用 FAT 檔案系統或者其他不能跟蹤 atime 的檔案系統，那就不得不想別的辦法來處理會話資料的記憶體回收。自 PHP 4.2.3 起用 mtime（修改時間）來代替了 atime。因此對於不能跟蹤 atime 的檔案系統也沒問題了。

GC 的運行時機並不是精準的，帶有一定的或然性，所以這個設定項並不能確保舊的會話資料被刪除。某些會話儲存處理模組不使用此設定項。

對於這種刪除機制，我是存疑的。

比如 gc_probability/gc_divisor 設定得比較大，或者網站的請求量比較大，那麼 GC 進程啟動就會比較頻繁。
還有，GC 進程啟動後都需要遍曆 Session 檔案清單，對比檔案的修改時間和服務端的目前時間，判斷檔案是否到期而決定是否刪除檔案。
這也是我覺得不應該使用 PHP 內建的 files 型 Session 處理器的原因。而 Redis 或 Memcached 天生就支援 key/value 到期機制的，用於作為會話處理器很合適。或者自己實現一個基於檔案的處理器，當根據 session_id 擷取對應的單個 Session 檔案時判斷檔案是否到期。

為什麼重啟瀏覽器後 Session 資料就取不到了

session.cookie_lifetime 以秒數指定了發送到瀏覽器的 cookie 的生命週期。值為 0 表示"直到關閉瀏覽器"。預設為 0。

其實，並不是 Session 資料被刪除（也有可能是，機率比較小，參見上一節）。只是關閉瀏覽器時，儲存 session_id 的 Cookie 沒有了。也就是你弄丟了開啟超市儲物箱的鑰匙（session_id）。

同理，瀏覽器 Cookie 被手動清除或者其他軟體清除也會造成這個結果。

為什麼瀏覽器開著，我很久沒有操作就被登出了

這個是稱為“防呆”，為了保護使用者賬戶安全的。

這個小節放進來，是因為這個功能的實現可能和 Session 的刪除機制有關（之所以說是可能，是因為這個功能不一定要借住 Session 實現，用 Cookie 也同樣可以實現）。
說簡單一點，就是長時間沒有操作，服務端的 Session 檔案到期被刪除了。

一個有意思的事情

在我實驗的過程中，發現了小有意思的事情：我把 GC 啟動的機率設定為 100%。如果只有一個訪問者請求，該訪問者即使過了很久（超過了到期時間）後才發起第二次請求，那麼 Session 資料也還是存在的（'session.save_path' 目錄下面的 Session 檔案存在）。是的，明明就超過了到期時間，卻沒有被 GC 刪除。這時，我用另外一個瀏覽器訪問時（相對於另一個訪問者），這次請求產生了新的 Session 檔案，而上一個瀏覽器請求產生的那個 Session 檔案終於沒有了（之前那個 Session 檔案在 'session.save_path' 目錄下面的消失了）。

還有，發現 Session 檔案被刪除後，再次請求，還是會產生和之前檔案名稱相同的 Session 檔案（因為瀏覽器並沒有關閉，再次請求發送的 session_id 是相同的，所以重建的 Session 檔案的檔案名稱還是一樣的）。但是，我不理解的是：這個重新出現的檔案的建立時間竟然是第一次的那個建立時間，難道它是從資源回收筒中回來的？（確實，我做這個實驗時是在 window 下進行的）

我猜測的原因是這樣：當啟動會話後，PHP 根據 session_id 找到並開啟了對應的 Session 檔案，然後才啟動 GC 進程。GC 進程就只檢查除了當前這個 Session 檔案外的其他檔案，發現到期的就幹掉。所有，即使當前這個 Session 檔案已經到期了，GC 也沒有刪除它。

我認為這個不合理的。

由於發生這種情況影響也不大（畢竟線上請求很多，當前請求的到期檔案被其他請求喚起的 GC 幹掉的可能性是比較大的） + 我沒有信心去看 PHP 原始碼 + 我並不線上上使用 PHP 內建的 files 型 Session 處理器。所以，這個問題我就沒有深入研究了。請諒解。

php

拓展閱讀：

如何設定一個嚴格 30 分鐘到期的 Session

