PHP之Session有效期間

該文章轉自：

http://www.ihacklog.com/

本文發表在《程式員》雜誌第10期

PHP沉思錄之五：Session有效期間問題
左輕侯
2008.9.07

 

 

Session處理是所有的Web應用都必須面對的問題。PHP中對session有效期間的處理，和其他的解決方案有著很大的不同，這是和PHP的工作機制相關的。

在傳統的client/server應用中，對於session失效的情況，可以交給網路通訊協定自己來處理。無論是client端主動關閉串連，還 是因為網路異常而導致的串連中斷，server端都能夠得到通知，觸發串連中斷的事件。只要編程響應這一事件，執行指定的操作即可。但對於web應用來 說，情況卻完全不一樣。HTTP協議本身是無狀態的，也就是說，每當client/server完成一次請求/響應的過程後，串連就會被斷開。在中斷連線 以後，server並不知道client是否繼續“線上”，還會繼續發送下一次請求。換句話說，無論client端的使用者已經關閉了瀏覽器視窗，還是使用者 僅僅在閱讀當前網頁並準備在下一秒鐘繼續瀏覽，或者使用者因為Windows崩潰/停電/硬碟壞掉/網線被拔/地球爆炸而徹底無法再發送下一個請 求，server都一無所知。（在HTTP 1.1中，瀏覽器可以通過keep-alive參數，來通知server不要在響應請求後主動中斷連線，從而實現物理上的長串連。但是，這隻是為了提高網 絡傳輸的效能而採取的措施，HTTP在邏輯上仍然是無狀態的。）因此，只能通過某種類比的方式來判斷當前session是否有效。如果某個session 在超過一段時間後沒有對server端發出請求，server都會判斷使用者已經“離線”，當前session失效，並觸發串連中斷的事件。要做到這一 點，server需要運行一個後台線程，定時掃描所有的session資訊，判斷session是否已經逾時。
PHP處理session的原理也不例外，但是在具體的實現方式上，卻與眾不同。這是因為，由於PHP的工作機制，它並沒有一個後台線程，來定 時地掃描session資訊並判斷其是否失效。它的解決之道是，當一個有效請求發生時，PHP會根據某個機率，來決定是否調用一個GC（Garbage Collector）。GC的工作，就是掃描所有的session資訊，用目前時間減去session的最後修改時間（modified date），同配置參數（configuration option）session.gc_maxlifetime的值進行比較，如果存留時間已經超過gc_maxlifetime，就把該session刪 除。這是很容易理解的，因為如果每次請求都要調用GC代碼，那麼PHP的效率就會低得令人吃不消了。這個機率取決於配置參數 session.gc_probability/session.gc_divisor的值（可以通過php.ini或者ini_set()函數來修 改）。預設情況下，session.gc_probability = 1，session.gc_divisor=100，也就是說有1%的可能性會啟動GC。

這三個參數，session.gc_maxlifetime/session.gc_probability /session.gc_divisor都可以通過php.ini或者ini_set()函數來修改。但要記得，如果使用ini_set()函數的話，必 須在每一個頁面的開始處都調用ini_set()。
這又導致了另外一個問題，gc_maxlifetime只能保證session生存的最短時間，並不能夠儲存在超過這一時間之後 session資訊立即會得到刪除。因為GC是按機率啟動的，可能在某一個長時間內都沒有被啟動，那麼大量的session在超過 gc_maxlifetime以後仍然會有效。當然，發生這種情況的機率很小，但是如果你的應用對session的失效期要求很精確的話，這會導致很嚴重 的問題。解決這個問題的一個方法是，把session.gc_probability/session.gc_divisor的機率提高，如果提到 100%，就會徹底解決這個問題，但顯然會對效能造成嚴重的影響。另一個方法是放棄PHP的GC，自己在代碼中判斷當前session的存留時間，如果超 出了 gc_maxlifetime，就清空當前session。
PHP中的session有效期間預設是1440秒（24分鐘），也就是說，用戶端超過24分鐘沒有重新整理，當前session就會失效。要修改這個預設值，正確的解決辦法是修改配置參數session.gc_maxlifetime。

我曾經在網上搜尋過這個問題的解決方式，找到的結果千奇百怪。有的說要設定“session_life_time”，據我知所，PHP中沒有這個 參數。有的說要調用session_set_cookie_params，或者設定session.cookie_lifetime，這僅僅用於設定 client端cookie的存留時間，換言之，只當client端cookie的存留時間小於server端的session生存期時，修改這個值才有 效，並且最長不能超過server端的session生存期，原因很簡單，當server端的session已經失效時，client端cookie的生 存時間再長也是沒有意義的。還有的說要調用 session_cache_expire，這個參數用於通知瀏覽器和proxy，當前頁面的內容應該被緩衝多長時間，和session的生存期並沒有直 接關係。
聽起來，這種解決方案很完美。但是，當你在實際中嘗試修改session.gc_maxlifetime的值的時候，你很可能會發現，這個參數基本不起作用，session有效期間仍然保持24分鐘的預設值。甚至可能出現，在開發環境下工作正常，在伺服器上卻無效！
為了徹底解決這個問題，需要對PHP的工作細節進行進一步的分析。
在預設情況下，PHP 中的session資訊會以文字檔的形式，被儲存在系統的臨時檔案目錄中。這個路徑由配置參數session.save_path指定。在Linux 下，這一路徑通常為/tmp，在 Windows下通常為C:/Windows/Temp。當伺服器上有多個PHP應用時，它們會把自己的session檔案都儲存在同一個目錄中（因為它 們使用同一個session.save_path參數）。同樣地，這些PHP應用也會按一定機率啟動GC，掃描所有的session檔案。

問題在於，GC在工作時，並不會區分不同網站的session。舉例言之，網站A的gc_maxlifetime設定為2小時，網站B的 gc_maxlifetime設定為預設的24分鐘。當網站B的GC啟動時，它會掃描公用的臨時檔案目錄，把所有超過24分鐘的session檔案全部刪 除掉，而不管它們來自於網站A或B。這樣，網站A的gc_maxlifetime設定就形同虛設了。
找到問題所在，解決起來就很簡單了。在頁面的開始處調用session_save_path()函數，它能夠修改 session.save_path參數，把儲存session的目錄指向一個專用的目錄，例如/tmp/myapp/。這 樣，gc_maxlifetime參數就工作正常了。
使用公用的session.save_path還會導致安全性問題，因為這意味著，同一台伺服器上的其它PHP程式也可以讀取你的網站的 session檔案，這可能被用於駭客攻擊。另一個問題是效率：在一個繁忙的網站中，可能存在成千上萬個session檔案，而把許多不同網站的 session檔案都放在同一個目錄下，無論是對單個檔案的讀寫，還是遍曆所有檔案進行GC，都無疑會導致效能的降低。因此，如果你的PHP應用和別的 PHP應用運行在同一台伺服器上的話，強烈建議你使用自己的session.save_path。
嚴格地來說，這算是PHP的一個bug。當PHP在進行GC時，它應該區別來自不同網站的session檔案，並應用不同的gc_maxlifetime值。目前，最新的PHP 5.2.X仍然存在這個問題。

上文說到，在一個繁忙的網站中，可能存在成千上萬個session檔案，即使區分了不同網站的session.save_path目錄，單個網站的session檔案數目仍然可能導致效率問題。為瞭解決這一問題，可行的幾種方法有：

•  如果PHP運行在Linux系統下，使用ReiserFS檔案系統取代預設的ext2/ext3檔案系統。ReiserFS對於大量小檔案的存取效能，比ext2/ext3有極大的提高。
•  將session.save_path指向一個記憶體路徑。這意味著，session檔案的讀寫只在記憶體中進行，而不執行磁碟操作。session.save_path接受一個額外的N參數，用於指定目錄的級數。例如，“5;/tmp” 將導致建立類似這樣的session檔案：/tmp/4/b/1/e/3 /sess_4b1e384ad74619bd212e236e52a5a174If。具體的說明，請參見：http://cn.php.net/manual/en/session.configuration.php#ini.session.save-path
• 終極的解決方案，是放棄PHP的session處理機制，自己編碼接管所有的session處理操作，通過 session_set_save_handler()函數來實現。通過自己接管session處理，可以將所有的session儲存在專門的資料庫（往 往使用記憶體表）中，從而徹底解決session檔案帶來的問題，並且可以方便地實現session的共用和複製。這也是大型的PHP應用一般會使用的方 式。關於session_set_save_handler()函數的使用，網上和相關圖書都有詳細的說明，這裡不再贅述。值得一提的是，即使在這種方式 下，啟動GC的機率仍然取決於session.gc_probability/session.gc_divisor。