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）。首先，在頁面上建立兩個按鈕。
在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("讀取簡單字符串失敗
");
}
else
{
string s=Session["SimpleString"].ToString();
Response.Write(s + "
");
}
if (Session["CustomClass"]==null)
{
Response.Write("讀取簡單自定義類失敗
");
}
else
{
MyUser user=Session["CustomClass"] as MyUser;
Response.Write(user.ToString()+"
");
}
}
在 每次讀取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節點中加入：
stateNetworkTimeout="20">
n stateConnectionString表示狀態服務器的通信地址（IP：服務端口號）。由於我們現在在本機進行測試，這里設置成本機地址127.0.0.1。狀態服務默認的監聽端口為42422。當然，您也可以通過修改注冊表來修改狀態服務的端口號。
n 1．在運行中輸入regedit啟動注冊表編輯器。
n 2．依次打開HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesaspnet_stateParameters節點，雙擊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:WINDOWSMicrosoft.NETFrameworkv2.0.50727aspnet_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節點。
為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 文件進行修改：
當然你也可以在程序中進行設置：
Session.Timeout = "30";
一旦Session超時，Session中的數據將被回收，如果再使用Session系統，將給你分配一個新的SessionID。本節一開始我們就介紹了可以在URL中存儲SessionID，現在請你配置Web.config文件，設置Session超時時間為1分鍾，SessionID在URl中存放。打開頁面后單擊“寫入Session”按鈕，過1分鍾再次單擊按鈕並觀察SessionID是否變化。
如圖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() + "
");
}
對於我們這個例子，輸出和圖12-1一樣。如果你僅僅為了監視Session，也可以通過trace來獲得詳細信息。在Web.config的system.Web節點中添加：
打開頁面后單擊“寫入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。