摘要:服務器給訪問者唯一的鑰匙,這個鑰匙被稱作。與合起來用來管理垃圾回收進程啟動的概率。例如意味著在每個請求中有的概率啟動進程。值為表示直到關閉瀏覽器。過期時間設置為秒啟動概率設置為
什么是 Session
在 web 應用開發(fā)中,Session 被稱為會話。主要被用于保存某個訪問者的數(shù)據(jù)。
由于 HTTP 無狀態(tài)的特點,服務端是不會記住客戶端的,對服務端來說,每一個請求都是全新的。
既然如此,那么服務端怎么知道是哪個訪問者在請求它呢?又如何將不同的數(shù)據(jù)對應上正確的訪問者?答案是,給訪問者一個唯一獲取 Session 中數(shù)據(jù)的身份標示。
打個比方:當我們?nèi)コ匈徫飼r,被保安告之我們是不能帶物品進去的,必須將物品寄放在超市的儲物箱中。我們把物品交給了他,他怎么知道這些物品誰是誰的,于是他給了我們不同的鑰匙。當我們要取走我們的物品時,用唯一的鑰匙打開對應的箱子即可。
就如同上面的比方一樣,可以將 Session 理解為存放我們數(shù)據(jù)的“箱子”,當然,這些“箱子”都在服務端那。服務器給訪問者唯一的“鑰匙”,這個“鑰匙”被稱作 session_id。訪問者憑借自己的 session_id,就能獲取到自己存在服務器端的數(shù)據(jù)。
session_id 通過兩種方式傳給訪問者(客戶端):URL 或 cookie。詳情參見:傳送會話ID
Session 和 Cookie 有什么關系
Cookie 也是由于 HTTP 無狀態(tài)的特點而產(chǎn)生的技術。也被用于保存訪問者的身份標示和一些數(shù)據(jù)。每次客戶端發(fā)起 HTTP 請求時,會將 Cookie 數(shù)據(jù)加到 HTTP header 中,提交給服務端。這樣服務端就可以根據(jù) Cookie 的內(nèi)容知道訪問者的信息了。 可以說,Session 和 Cookie 做著相似的事情,只是 Session 是將數(shù)據(jù)保存在服務端,通過客戶端提交來的 session_id 來獲取對應的數(shù)據(jù);而 Cookie 是將數(shù)據(jù)保存在客戶端,每次發(fā)起請求時將數(shù)據(jù)提交給服務端的。
上面提到,session_id 可以通過 URL 或 cookie 來傳遞,由于 URL 的方式比 cookie 的方式更加不安全且使用不方便,所以一般是采用 cookie 來傳遞 session_id。
服務端生成 session_id,通過 HTTP 報文發(fā)送給客戶端(比如瀏覽器),客戶端收到后按指示創(chuàng)建保存著 session_id 的 cookie。cookie 是以 key/value 形式保存的,看上去大概就這個樣子的:PHPSESSID=e4tqo2ajfbqqia9prm8t83b1f2。在 PHP 中,保存 session_id 的 cookie 名稱默認叫作 PHPSESSID,這個名稱可以通過 php.ini 中 session.name 來修改,也可以通過函數(shù) session_name() 來修改。
為什么不推薦使用 PHP 自帶的 files 型 Session 處理器
在 PHP 中,默認的 Session 處理器是 files,處理器可以用戶自己實現(xiàn)(參見:自定義會話管理器)。我知道的成熟的 Session 處理器還有很多:Redis、Memcached、MongoDB……
為什么不推薦使用 PHP 自帶的 files 類型處理器,PHP 官方手冊中給出過這樣一段 Note:
無論是通過調(diào)用函數(shù) session_start() 手動開啟會話, 還是使用配置項 session.auto_start 自動開啟會話, 對于基于文件的會話數(shù)據(jù)保存(PHP 的默認行為)而言, 在會話開始的時候都會給會話數(shù)據(jù)文件加鎖, 直到 PHP 腳本執(zhí)行完畢或者顯式調(diào)用 session_write_close() 來保存會話數(shù)據(jù)。 在此期間,其他腳本不可以訪問同一個會話數(shù)據(jù)文件。
上述引用參見:Session 的基本用法
為了證明這段話,我們創(chuàng)建一下 2 個文件: 文件:session1.php
session_start();
sleep(5);
var_dump($_SESSION);
?>
文件:session2.php
session_start();
var_dump($_SESSION);
?>
在同一個瀏覽器中,先訪問 http://127.0.0.1/session1.php,然后在當前瀏覽器新的標簽頁立刻訪問 http://127.0.0.1/session2.php。實驗發(fā)現(xiàn),session1.php 等了 5 秒鐘才有輸出,而 session2.php 也等到了將近 5 秒才有輸出。而多帶帶訪問 session2.php 是秒開的。在一個瀏覽器中訪問 session1.php,然后立刻在另外一個瀏覽器中訪問 session2.php。結果是 session1.php 等待 5 秒鐘有輸出,而 session2.php 是秒開的。
分析一下造成這個現(xiàn)象的原因:上面例子中,默認使用 Cookie 來傳遞 session_id,而且 Cookie 的作用域是相同。這樣,在同一個瀏覽器中訪問這 2 個地址,提交給服務器的 session_id 就是相同的(這樣才能標記訪問者,這是我們期望的效果)。當訪問 session1.php 時,PHP 根據(jù)提交的 session_id,在服務器保存 Session 文件的路徑(默認為 /tmp,通過 php.ini 中的 session.save_path 或者函數(shù) session_save_path() 來修改)中找到了對應的 Session 文件,并對其加鎖。如果不顯式調(diào)用 session_write_close(),那么直到當前 PHP 腳本執(zhí)行完畢才會釋放文件鎖。如果在腳本中有比較耗時的操作(比如例子中的 sleep(5)),那么另一個持有相同 session_id 的請求由于文件被鎖,所以只能被迫等待,于是就發(fā)生了請求阻塞的情況。
既然如此,在使用完 Session 后,立刻顯示調(diào)用 session_write_close() 是不是就解決問題了哩?比如上面例子中,在 sleep(5) 前面調(diào)用 session_write_close()。
確實,這樣 session2.php 就不會被 session1.php 所阻塞。但是,顯示調(diào)用了 session_write_close() 就意味著將數(shù)據(jù)寫到文件中并結束當前會話。那么,在后面代碼中要使用 Session 時,必須重新調(diào)用 session_start()。
例如:
session_start();
$_SESSION["name"] = "Jing";
var_dump($_SESSION);
session_write_close();
sleep(5);
session_start();
$_SESSION["name"] = "Mr.Jing";
var_dump($_SESSION);
?>
官方給出的方案:
對于大量使用 Ajax 或者并發(fā)請求的網(wǎng)站而言,這可能是一個嚴重的問題。 解決這個問題最簡單的做法是如果修改了會話中的變量, 那么應該盡快調(diào)用 session_write_close() 來保存會話數(shù)據(jù)并釋放文件鎖。 還有一種選擇就是使用支持并發(fā)操作的會話保存管理器來替代文件會話保存管理器。
我推薦的方式是使用 Redis 作為 Session 的處理器。
拓展閱讀:
為什么不能用 memcached 存儲 Session
如何使用 Redis 作為 PHP Session handler
Session 數(shù)據(jù)是什么時候被刪除的
這是一道經(jīng)常被面試官問起的問題。
先看看官方手冊中的說明:
session.gc_maxlifetime 指定過了多少秒之后數(shù)據(jù)就會被視為"垃圾"并被清除。 垃圾搜集可能會在 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。
繼續(xù)用我上面那個不太恰當?shù)谋确桨桑喝绻覀儼盐锲贩旁诔械膬ξ锵渲卸蝗∽撸^了很久(比如一個月),那么保安就要清理這些儲物箱中的物品了。當然并不是超過期限了保安就一定會來清理,也許他懶,又或者他壓根就沒有想起來這件事情。
再看看兩段手冊的引用:
如果使用默認的基于文件的會話處理器,則文件系統(tǒng)必須保持跟蹤訪問時間(atime)。Windows FAT 文件系統(tǒng)不行,因此如果必須使用 FAT 文件系統(tǒng)或者其他不能跟蹤 atime 的文件系統(tǒng),那就不得不想別的辦法來處理會話數(shù)據(jù)的垃圾回收。自 PHP 4.2.3 起用 mtime(修改時間)來代替了 atime。因此對于不能跟蹤 atime 的文件系統(tǒng)也沒問題了。 GC 的運行時機并不是精準的,帶有一定的或然性,所以這個設置項并不能確保舊的會話數(shù)據(jù)被刪除。某些會話存儲處理模塊不使用此設置項。
對于這種刪除機制,我是存疑的。
比如 gc_probability/gc_divisor 設置得比較大,或者網(wǎng)站的請求量比較大,那么 GC 進程啟動就會比較頻繁。
還有,GC 進程啟動后都需要遍歷 Session 文件列表,對比文件的修改時間和服務端的當前時間,判斷文件是否過期而決定是否刪除文件。
這也是我覺得不應該使用 PHP 自帶的 files 型 Session 處理器的原因。而 Redis 或 Memcached 天生就支持 key/value 過期機制的,用于作為會話處理器很合適。或者自己實現(xiàn)一個基于文件的處理器,當根據(jù) session_id 獲取對應的單個 Session 文件時判斷文件是否過期。
為什么重啟瀏覽器后 Session 數(shù)據(jù)就取不到了
session.cookie_lifetime 以秒數(shù)指定了發(fā)送到瀏覽器的 cookie 的生命周期。值為 0 表示"直到關閉瀏覽器"。默認為 0。
其實,并不是 Session 數(shù)據(jù)被刪除(也有可能是,概率比較小,參見上一節(jié))。只是關閉瀏覽器時,保存 session_id 的 Cookie 沒有了。也就是你弄丟了打開超市儲物箱的鑰匙(session_id)。
同理,瀏覽器 Cookie 被手動清除或者其他軟件清除也會造成這個結果。
為什么瀏覽器開著,我很久沒有操作就被登出了
這個是稱為“防呆”,為了保護用戶賬戶安全的。
這個小節(jié)放進來,是因為這個功能的實現(xiàn)可能和 Session 的刪除機制有關(之所以說是可能,是因為這個功能不一定要借住 Session 實現(xiàn),用 Cookie 也同樣可以實現(xiàn))。 說簡單一點,就是長時間沒有操作,服務端的 Session 文件過期被刪除了。
一個有意思的事情
在我試驗的過程中,發(fā)現(xiàn)了小有意思的事情:我把 GC 啟動的概率設置為 100%。如果只有一個訪問者請求,該訪問者即使過了很久(超過了過期時間)后才發(fā)起第二次請求,那么 Session 數(shù)據(jù)也還是存在的("session.save_path" 目錄下面的 Session 文件存在)。是的,明明就超過了過期時間,卻沒有被 GC 刪除。這時,我用另外一個瀏覽器訪問時(相對于另一個訪問者),這次請求生成了新的 Session 文件,而上一個瀏覽器請求生成的那個 Session 文件終于沒有了(之前那個 Session 文件在 "session.save_path" 目錄下面的消失了)。
還有,發(fā)現(xiàn) Session 文件被刪除后,再次請求,還是會生成和之前文件名相同的 Session 文件(因為瀏覽器并沒有關閉,再次請求發(fā)送的 session_id 是相同的,所以重新生成的 Session 文件的文件名還是一樣的)。但是,我不理解的是:這個重新出現(xiàn)的文件的創(chuàng)建時間竟然是第一次的那個創(chuàng)建時間,難道它是從回收站中回來的?(確實,我做這個試驗時是在 window 下進行的)
我猜測的原因是這樣:當啟動會話后,PHP 根據(jù) session_id 找到并打開了對應的 Session 文件,然后才啟動 GC 進程。GC 進程就只檢查除了當前這個 Session 文件外的其他文件,發(fā)現(xiàn)過期的就干掉。所有,即使當前這個 Session 文件已經(jīng)過期了,GC 也沒有刪除它。
我認為這個不合理的。
由于發(fā)生這種情況影響也不大(畢竟線上請求很多,當前請求的過期文件被其他請求喚起的 GC 干掉的可能性是比較大的) + 我沒有信心去看 PHP 源代碼 + 我并不在線上使用 PHP 自帶的 files 型 Session 處理器。所以,這個問題我就沒有深入研究了。請諒解。
// 過期時間設置為 30 秒
ini_set("session.gc_maxlifetime", "30");
// GC 啟動概率設置為 100%
ini_set("session.gc_probability", "100");
ini_set("session.gc_divisor", "100");
session_start();
$_SESSION["name"] = "Jing";
var_dump($_SESSION);
?>
文章版權歸作者所有,未經(jīng)允許請勿轉載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/22759.html
摘要:需要修改以下三個地方修改安裝擴展修改的如果是也有需要修改相關的配置配置文件影響配置項有要將保存到,,必須要配置的。配置完以后,可能不生效。通過會看到配置里有兩個值,,。受配置文件配置影響受的影響。它們的配置優(yōu)先級比高,會覆蓋中的配置。 需要修改以下三個地方:1、修改php.ini2、安裝phpredis擴展3、修改apache的php.conf4、如果是php-fpm也有需要修改相關的...
摘要:主要被用于保存某個訪問者的數(shù)據(jù)。服務器給訪問者唯一的鑰匙,這個鑰匙被稱作。例如官方給出的方案對于大量使用或者并發(fā)請求的網(wǎng)站而言,這可能是一個嚴重的問題。例如意味著在每個請求中有的概率啟動進程。因此對于不能跟蹤的文件系統(tǒng)也沒問題了。 什么是 Session 在 web 應用開發(fā)中,Session 被稱為會話。主要被用于保存某個訪問者的數(shù)據(jù)。 由于 HTTP 無狀態(tài)的特點,服務端是不會記...
摘要:文章轉自介紹這個頁面的目的是為了幫助那些配置和運行它的服務器的人確保它的安全性。下面你將找到有關文件的正確配置信息。最后,查看文檔以獲得關于配置文件中每個值的參考。 showImg(https://segmentfault.com/img/remote/1460000018821916?w=1520&h=550); 文章轉自:https://learnku.com/php/t/2697...
摘要:一下大多是網(wǎng)上的資料,自己只是整理了下,如果有錯誤希望能指出,感謝中的相關配置先看下中的相關配置的解釋。啟用此設定可以防止有關通過傳遞會話的攻擊。值為表示直到關閉瀏覽器。例如意味著在每個請求中有的概率啟動進程。 對于session的了解,之前一直沒有仔細研究過,最近遇到了一些問題,需要解決session配置問題,就順便查看了些資料。一下大多是網(wǎng)上的資料,自己只是整理了下,如果有錯誤希望...
閱讀 713·2023-04-25 17:54
閱讀 2972·2021-11-18 10:02
閱讀 1132·2021-09-28 09:35
閱讀 649·2021-09-22 15:18
閱讀 2847·2021-09-03 10:49
閱讀 3051·2021-08-10 09:42
閱讀 2573·2019-08-29 16:24
閱讀 1255·2019-08-29 15:08