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狀態服務一項，右鍵單擊服務選擇啟動。
n 如果你正式決定使用狀態服務儲存Session前，別忘記修改服務為自啟動（在作業系統重啟後服務能自己啟動）以免忘記啟動服務而造成網站Session不能使用，雙擊服務把服務的啟動型別設定為自動。
服務正常啟動後可以觀察工作管理員的程式頁，其中的aspnet_state.exe程式就是狀態服務程式。
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。