文章來源: http://blog.csdn.net/wizard1/article/details/2451349
Session又稱爲會話狀態,是Web系統中最常用的狀態,用於維護和當前瀏覽器實例相關的一些信息。舉個例子來說,我們可以把已登錄用戶的用戶名放在Session中,這樣就能通過判斷Session中的某個Key來判斷用戶是否登錄,如果登錄的話用戶名又是多少。
我們知 道,Session對於每一個客戶端(或者說瀏覽器實例)是“人手一份”,用戶首次與Web服務器建立連接的時候,服務器會給用戶分發一個 SessionID作爲標識。SessionID是一個由24個字符組成的隨機字符串。用戶每次提交頁面,瀏覽器都會把這個SessionID包含在 HTTP頭中提交給Web服務器,這樣Web服務器就能區分當前請求頁面的是哪一個客戶端。那麼,ASP.NET 2.0提供了哪些存儲SessionID的模式呢:
· Cookie(默認)。如果客戶端禁止了Cookie的使用,Session也將失效。
· URL。Cookie是否開啓不影響Session使用,缺點是不能再使用絕對鏈接了。
前面說了SessionID可以存儲在客戶端的Cookie或者URL中,那麼Session真正的內容存儲在哪裏呢?ASP.NET 2.0對於Session內容的存儲也提供了多種模式。
· InProc(默認)。Session存儲在IIS進程中(Web服務器內存)。
· StateServer。Session存儲在獨立的Windows服務進程中(可以不是Web服務器)。
· SqlServer。Session存儲在SqlServer數據庫的表中(SqlServer服務器)。
雖然 InProc模式的Session直接存儲在Web服務器IIS進程中,速度比較快,但是每次重新啓動IIS都會導致Session丟失。利用後兩種模式,我們就完全可以把Session從Web服務器中獨立出來,從而減輕Web服務器的壓力,同時減少Session丟失的概率。
因此,SessionID存儲在客戶端(可以是Cookie或者URL),其他都存儲在服務端(可以是IIS進程、獨立的Windows服務進程或者SQL Server數據庫中)。
12.3.2 Session的使用
讓我們先來實踐一下如何使用Session,進而回答第二個問題:Session存儲的類型限制。Session不需要進行任何配置就可以使用(默認是InProc模式並且依賴Cookie)。首先,在頁面上建立兩個按鈕。
<asp:Button ID="btn_WriteSession" runat="server"Text="寫入Session" />
<asp:Button ID="btn_ReadSession" runat="server" Text="讀取Session" />
在btn_WriteSession按鈕的Click事件處理方法中,寫入兩個Session,一個是簡單的字符串,另外一個是自定義的類。
protected void btn_WriteSession_Click(object sender, EventArgs e)
{
Session["SimpleString"] = "編程快樂";
MyUser user = new MyUser();
user.sUserName = "小朱";
user.iAage = 24;
Session["CustomClass"] = user;
}
Session的使用非常簡單,直接對某個Key的Session進行賦值即可。自定義類MyUser如下:
class MyUser
{
public string sUserName;
public int iAage;
public override string ToString()
{
return string.Format("姓名:{0},年齡:{1}", sUserName, iAage);
}
}
在這裏,我們覆寫了ToString()方法直接返回實例的一些信息。然後,雙擊btn_ReadSession按鈕來實現從Session中讀取數據的代碼:
protected void btn_ReadSession_Click(object sender, EventArgs e)
{
if (Session["SimpleString"]==null)
{
Response.Write("讀取簡單字符串失敗<br/>");
}
else
{
string s=Session["SimpleString"].ToString();
Response.Write(s + "<br/>");
}
if (Session["CustomClass"]==null)
{
Response.Write("讀取簡單自定義類失敗<br/>");
}
else
{
MyUser user=Session["CustomClass"] as MyUser;
Response.Write(user.ToString()+"<br/>");
}
}
在每次讀取Session的值以前請務必先判斷Session是否爲空,否則很有可能出現“未將對象引用設置到對象的實例”的異常。我們看到,從Session 中讀出的數據都是object類型的,我們需要進行類型轉化後才能使用。打開頁面,先單擊寫入Session按鈕,再單擊讀取Session按鈕,頁面輸出如 圖12-1所示。
12.3.3 把Session存儲在獨立的進程中
由此看來,Session能存儲任意對象,是這樣嗎?現在得出這個結論還太早了一點,因爲我們並沒有實踐過StateServer和SqlServer模式的Session。要把Session存儲在Windows服務進程中需要進行以下幾個步驟。
n 第1步是打開狀態服務。依次打開“控制面板”→“管理工具”→“服務”命令,找到ASP.NET狀態服務一項,右鍵單擊服務選擇啓動,如圖12-2所示。
圖12-2 啓動ASP.NET狀態服務
n 如果你正式決定使用狀態服務存儲Session前,別忘記修改服務爲自啓動(在操作系統重啓後服務能自己啓動)以免忘記啓動服務而造成網站Session不能使用,如圖12-3所示,雙擊服務把服務的啓動類型設置爲自動。
圖12-3 修改服務啓動類型爲自動
服務正常啓動後可以觀察任務管理器的進程頁,其中的aspnet_state.exe進程就是狀態服務進程,如圖12-4所示。
圖12-4 觀察任務管理器的進程頁
n 第2步,在system.web節點中加入:
<sessionState mode="StateServer" stateConnectionString="tcpip=127.0.0.1:42424"
stateNetworkTimeout="20"></sessionState>
n stateConnectionString表示狀態服務器的通信地址(IP:服務端口號)。由於我們現在在本機進行測試,這裏設置成本機地址127.0.0.1。狀態服務默認的監聽端口爲42422。當然,您也可以通過修改註冊表來修改狀態服務的端口號。
n 1.在運行中輸入regedit啓動註冊表編輯器。
n 2.依次打開HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/aspnet_state/Parameters節點,雙擊Port選項,如圖12-5所示。
選擇基數爲十進制,然後輸入一個端口號即可。stateNetworkTimeout屬性表示從狀態服務器請求Session數據最長的時間,默認爲10秒,如果網絡連接不是很好,請把這個數字適當設置得大一點。
n 第3步打開頁面,單擊“寫入Session”按鈕,系統會報錯,如圖12-6所示。
圖12-5 修改狀態服務端口號 圖12-6 向StateServer默認的Session中寫入自定義類出錯
提示已經說得很清楚了,只有把對象標註爲可序列化後才能在服務中進行存儲。什麼是序列化呢?序列化是指將對象實例的狀態存儲到存儲媒體的過程。在此過程中,先將對象的公共字段和私有字段以及類的名稱轉換爲字節流,然後再把字節流寫入數據流。在隨後對對象進行反序列化時,將創建出與原對象完全相同的副本。要使一個類可序列化,最簡單的方法是使用 Serializable 屬性對它進行標記。
[Serializable]
class MyUser
{
public string sUserName;
public int iAage;
public override string ToString()
{
return string.Format("姓名:{0},年齡:{1}", sUserName, iAage);
}
}
n 第4步現在重新打開頁面進行測試,得到的結果和使用InProc模式是一樣的。
12.3.4 把Session存儲在數據庫中
要把Session存儲在SqlServer中,基本上也是這麼幾個步驟。
n 1.在命令行窗口輸入cmd並在命令行中運行如下命令。
C:/WINDOWS/Microsoft.NET/Framework/v2.0.50727/aspnet_regsql.exe -S ./SqlExpress -E –ssadd
其中 C:/Windows用你自己Windows的目錄代替,v2.0.50727用你安裝的2.0框架的版本號代替。-S指定SqlServer服務器地址,-E表示採用信任連接,-ssadd表示爲SqlServer服務器添加狀態服務的支持。操作結束後,你可以使用IDE的服務器資源管理器連接 SqlExpress數據庫,可以看到多了一個ASPState數據庫,但是奇怪的是數據庫中沒有任何表卻有很多存儲過程,如圖12-7所示。
其實,所有Session的數據都存放在了tempdb數據庫內,如圖12-8所示。
圖12-7 使用服務器資源管理器瀏覽ASPState數據庫 圖12-8 存放Session數據的tempdb數據庫
其實,aspnet_regsql.exe有一個-sstype參數可以用來指定Session的內容和操作的存儲過程存放的表。由於篇幅關係,在這裏就不詳細介紹了,讀者可以使用aspnet_regsql.exe/?來瀏覽程序詳細的使用方式。
n 2.打開Web.config文件,修改前面建立的sessionState節點。
<sessionState mode="SQLServer" sqlConnectionString="server=(local)/SQLEXPRESS;
Trusted_Connection=True" sqlCommandTimeout="60"></sessionState>
爲sqlConnectionString 屬性指定以前一直用的連接字符串,唯一不同的是不需要再指定數據表的名字了。sqlCommandTimeout屬性表示允許執行Sql命令最長的時間,默認爲30秒,可以根據自己的需要適當調整這個數字。最後,重新打開頁面進行測試,得到的結果和使用InProc模式是一樣的(同樣你需要確保在自定義類前標註了[Serializable]),不過我們能感到速度有些慢了,畢竟數據是從數據庫中進行讀取或保存的,而且在使用前還需要經過序列化和反序列化操作。
因此Session能存儲的類型爲: 對於InProc模式是一切類型,而對於StateServer和SqlServer模式是一切可以序列化的類型。
12.3.5 Session的使用範圍與大小限制
那麼, 會話狀態使用的範圍和大小限制又是怎麼樣的呢?我們可以分析一下圖12-8,系統使用兩個表來存儲Session的狀態。其中有一個 ASPStateTempApplication表,用來存儲Session所在的應用程序,一定程度上反映了Session是不能跨應用程序的。舉例來說,我們在計算機上建立了兩個網站,同時都使用Session[“UserName”]來保存登錄的用戶名,一個網站的用戶登錄後,另一個網站直接訪問 Session[“UserName”]是取不到任何值的。那麼,Session是否可以跨用戶呢?通過前面的分析我們知道,肯定是不行的, Session通過SessionID來區分用戶,一般來說SessionID是不可能出現重複的現象,也就是說Session一般是不會“串號”的。既然頁面每次提交的時候都會附加上當前用戶的SessionID,那麼Session應該是可以跨頁面的,也就是說一個網站中所有的頁面都使用同一份 Session。你可以自己來做個試驗,請讀者打開剛纔那個頁面,然後按Ctrl+N組合鍵再打開第二個同樣的頁面,單擊第一個頁面中的“寫入 Session”按鈕,單擊第二個頁面中的“讀取Session”按鈕,可以發現Session的值被正確讀出了。第三個問題的答案有了。
· Session狀態使用的範圍:使用同一個客戶端(瀏覽器實例)訪問同一個應用程序的所有頁面。
我們再來做一個試驗,看看Session的容量有多大,在測試以前請修改Web.config,把Session設置爲StateServer模式。然後,把寫入Session的代碼修改成如下(別忘記using System.Data.SqlCient):
DataSet ds = new DataSet();
using (SqlConnection conn = new SqlConnection(@"server=(local)/SQLEXPRESS;database=Forum;
Trusted_Connection=True"))
{
SqlDataAdapter da = new SqlDataAdapter("select * from tbUser;select * from tbBoard;
select * from tbTopic;", conn);
da.Fill(ds);
}
ArrayList al = new ArrayList();
for(int i = 0;i<10000000;i++)
al.Add(ds);
Session["LargeData"] = al;
我們把包含三個表的DataSet重複加入ArrayList中1000萬次。由於這些表幾乎每個表只有幾條記錄,這樣可以模擬大數據量的情況。啓動頁面,單擊“寫入Session”按鈕後可以發現,Windows服務進程一下子佔用了多達70MB的內存,如圖12-9所示。
圖12-9 把大量數據存放到Session中
Session 對於網站和用戶是獨立的,試想一下,如果服務器上有兩個網站,每個網站的在線人數是100人,那麼佔用內存就要14G。是不是很恐怖的數字?因此,雖然 Session的大小沒有限制,但是我們千萬不能濫用Session。筆者推薦你在Session中存儲少於100K的數據。
· 如果你使用InProc模式的Session,存儲過多的數據會導致IIS進程被回收,引發Session不斷丟失。
· 如果你使用StateServer存儲Session,那麼數據在存入Session以前需要進行序列化,序列化會消耗大量的CPU資源。
· 如果你使用SqlServer模式的Session,數據不但要序列化而且還是存儲在磁盤上,更不適合存儲大量數據。
12.3.6 Session的生命週期
在瞭解了Session中存儲的數據無大小限制後,我們可能要更多地關心Session的生命週期了。我們已經知道,Session是在用戶第一次訪問網站的時候創建的,那麼Session是什麼時候銷燬的呢?Session使用一種平滑超時的技術來控制何時銷燬Session。默認情況下,Session 的超時時間(Timeout)是20分鐘,用戶保持連續20分鐘不訪問網站,則Session被收回,如果在這20分鐘內用戶又訪問了一次頁面,那麼20 分鐘就重新計時了,也就是說,這個超時是連續不訪問的超時時間,而不是第一次訪問後20分鐘必過時。這個超時時間同樣也可以通過調整Web.config 文件進行修改:
<sessionState timeout="30"></sessionState>
當然你也可以在程序中進行設置:
Session.Timeout = "30";
一旦Session超時,Session中的數據將被回收,如果再使用Session系統,將給你分配一個新的SessionID。本節一開始我們就介紹了可以在URL中存儲SessionID,現在請你配置Web.config文件,設置Session超時時間爲1分鐘,SessionID在URl中存放。打開頁面後單擊“寫入Session”按鈕,過1分鐘再次單擊按鈕並觀察SessionID是否變化。
<sessionState timeout="1" cookieless="true"></sessionState>
如圖12-10所示,SessionID的確發生了變化。
圖12-10 超時後SessionID發生變化
不過,你可別太相信Session的Timeout屬性,如果你把它設置爲24小時,則很難相信24小時之後用戶的Session還在。Session是否存在,不僅僅依賴於Timeout屬性,以下的情況都可能引起Session丟失(所謂丟失就是在超時以前原來的Session無效)。
· bin目錄中的文件被改寫。asp.net有一種機制,爲了保證dll重新編譯之後,系統正常運行,它會重新啓動一次網站進程,這時就會導致 Session丟失,所以如果有access數據庫位於bin目錄,或者有其他文件被系統改寫,就會導致Session丟失。
· SessionID丟失或者無效。如果你在URL中存儲SessionID,但是使用了絕對地址重定向網站導致URL中的SessionID丟失,那麼原來的Session將失效。如果你在Cookie中存儲SessionID,那麼客戶端禁用Cookie或者Cookie達到了IE中Cookie數量的限制(每個域20個),那麼Session將無效。
· 如果使用InProc的Session,那麼IIS重啓將會丟失Session。同理,如果使用StateServer的Session,服務器重新啓動Session也會丟失。
一般來說,如果在IIS中存儲Session而且Session的Timeout設置得比較長,再加上Session中存儲大量的數據,非常容易發生Session丟失的問題。
最後, Session的安全性怎麼樣呢?我們知道,Session中只有SessionID是存儲在客戶端的,並且在頁面每次提交的過程中加入HTTP頭髮送給服務器。SessionID只是一個識別符,沒有任何內容,真正的內容是存儲在服務器上的。總的來說安全性還是可以的,不過筆者建議你不要使用 cookieless和SqlServer模式的Session。把SessionID暴露在URL中,把內容存儲在數據庫中可能會發生攻擊隱患。
12.3.7 遍歷與銷燬Session
Session雖然很方便,但是要用好Session還需要自己不斷實踐,根據自己網站的特點靈活使用各種模式的Session。關於使用程序訪問Session,筆者還想補充兩點。
· 如何遍歷當前的Session集合。
System.Collections.IEnumerator SessionEnum = Session.Keys.GetEnumerator();
while (SessionEnum.MoveNext())
{
Response.Write(Session[SessionEnum.Current.ToString()].ToString() + "<br/>");
}
對於我們這個例子,輸出和圖12-1一樣。如果你僅僅爲了監視Session,也可以通過trace來獲得詳細信息。在Web.config的system.Web節點中添加:
<trace enabled="true" pageOutput="true"/>
打開頁面後單擊“寫入Session”按鈕,頁面顯示如圖12-11所示。
圖12-11 使用trace觀察會話狀態
· 如何立刻讓Session失效。比如用戶退出系統後,Session中保存的所有數據全部失效,可以使用以下代碼來讓Session失效。
Session.Abandon();
12.3.8 Session的常見問題與總結
Session的基本知識就介紹到這裏,現在再回頭看第一節中的幾個問題,你是否都能回答了呢?爲了強化大家的概念,筆者就三種模式的Session進行了一個比較(假設都使用Cookie來存儲SessionID)。
表12.1 三種模式的Session比較
|
InProc |
StateServer |
SQLServer |
存儲物理位置 |
IIS進程(內存) |
Windows服務進程(內存) |
SQLServer數據庫(磁盤) |
存儲類型限制 |
無限制 |
可以序列化的類型 |
可以序列化的類型 |
存儲大小限制 |
無限制 |
||
使用範圍 |
當前請求上下文,對於每個用戶獨立 |
||
生命週期 |
第一次訪問網站的時候創建Session超時後銷燬 |
||
優點 |
性能比較高 |
Session不依賴Web服務器,不容易丟失 |
|
缺點 |
容易丟失 |
序列化與反序列化消耗CPU資源 |
序列化與反序列化消耗CPU資源,從磁盤讀取Session比較慢 |
使用原則 |
不要存放大量數據 |
在使用Session的過程中你可能還會遇到很多奇怪的問題,結束本節之前筆者列出了幾條常見的FAQ,供大家參考:
· 爲什麼每次請求的SessionID都不相同?
n 可能是沒有在Session裏面保存任何信息引起的,即程序中任何地方都沒有使用Session。只有在Session中保存了內容後,Session纔會和瀏覽器進行關聯,此時的SessionID將不會再變化。
· 爲什麼當我設置cookieless爲true後,在重定向的時候會丟失Session?
n 當使用cookieless時,你必須使用相對路徑替換程序中的絕對路徑,如果使用絕對路徑,ASP.NET將無法在URL中保存SessionID。
· 有辦法知道應用程序的Session在運行時佔用了多少內存嗎?
n 沒有辦法,你可以通過察IIS進程(InProc模式)或者aspnet_state進程(StateServer模式)大致估計。
· 有沒有可能知道整個網站使用Session的用戶列表?
n 對於InProc模式和StateServer模式很難,對於SqlServer模式你可以查詢存儲Session的表進行嘗試。
· 當頁面中設了frameset,發現在每個frame中顯示頁面的SessionID在第一次請求時都不相同,爲什麼?
n 原因是你的frameset是放在一個HTML頁面上而不是ASPX頁面。在一般情況下,如果frameset是aspx頁面,當你請求頁面時,它首先將請求發送到Web服務器,此時已經獲得了SessionID,接着瀏覽器會分別請求Frame中的其他頁面,這樣所有頁面的SessionID就是一樣的,就是FrameSet頁面的SessionID。然而如果你使用HTML頁面做FrameSet頁面,第一個請求將是HTML頁面,當該頁面從服務器上返回時並沒有任何Session產生,接着瀏覽器會請求Frame裏面的頁面,這樣,這些頁面都會產生自己的SessionID,所以在這種情況下就可能出現這種問題。當你重新刷新頁面時,SessionID就會一樣,並且是最後一個請求頁面的SessionID。