這裡用一個形象的比喻來解釋session的工作方式。假設Web Server是一個商場的存包處，HTTP Request是一個顧客，第一次來到存包處，管理員把顧客的物品存放在某一個櫃子裡面（這個櫃子就相當於Session），然後把一個號碼牌交給這個顧客，作為取包憑證（這個號碼牌就是Session ID）。顧客（HTTP Request）下一次來的時候，就要把號碼牌（Session ID）交給存包處（Web Server）的管理員。管理員根據號碼牌（Session ID）找到相應的櫃子（Session），根據顧客（HTTP Request）的請求，Web Server可以取出、更換、新增櫃子（Session

閱讀本文章之前的準備

閱讀本文章前，需要讀者對以下知識有所瞭解。否則，閱讀過程中會在相應的內容上遇到不同程度的問題。

• 懂得ASP/ASP.NET程式設計
• 瞭解ASP/ASP.NET的Session模型
• 瞭解ASP.NET Web應用程式模型
• 瞭解ASP.NET Web應用程式配置檔案Web.config的作用、意義及使用方法
• 瞭解Internet Information Services(以下簡稱IIS)的基本使用方法
• 瞭解如何在Microsoft SQL Server中建立一個數據庫。

Session模型簡介

Session 是什麼呢？簡單來說就是伺服器給客戶端的一個編號。當一臺WWW伺服器執行時，可能有若干個使用者瀏覽正在運正在這臺伺服器上的網站。當每個使用者首次與這臺 WWW伺服器建立連線時，他就與這個伺服器建立了一個Session，同時伺服器會自動為其分配一個SessionID，用以標識這個使用者的唯一身份。這個SessionID是由WWW伺服器隨機產生的一個由24個字元組成的字串，我們會在下面的實驗中見到它的實際樣子。

這個唯一的 SessionID是有很大的實際意義的。當一個使用者提交了表單時，瀏覽器會將使用者的SessionID自動附加在HTTP頭資訊中，（這是瀏覽器的自動功能，使用者不會察覺到），當伺服器處理完這個表單後，將結果返回給SessionID所對應的使用者。試想，如果沒有SessionID，當有兩個使用者同時進行註冊時，伺服器怎樣才能知道到底是哪個使用者提交了哪個表單呢。當然，SessionID還有很多其他的作用，我們會在後面提及到。

除了 SessionID，在每個Session中還包含很多其他資訊。但是對於編寫ASP或ASP.NET的程式與來說，最有用的還是可以通過訪問 ASP/ASP.NET的內建Session物件，為每個使用者儲存各自的資訊。例如我們想了解一下訪問我們網站的使用者瀏覽了幾個頁面，我們可能在使用者可能訪問到每個的頁面中加入：

通過以下這句話可以讓使用者得知自己瀏覽了幾個頁面：

可能有些有些讀者會問：這個看似像是陣列的Session(“..”)是哪裡來的？需要我定義嗎？實際上，這個Session物件是具有ASP解釋能力的的 WWW伺服器的內建物件。也就是說ASP的系統中已經給你定義好了這個物件，你只需要使用就行了。其中Session(“..”)中的..就好像變數名稱，Session(“..”)=$$$中的$$$就是變數的值了。你只需要寫上句話，在這個使用者的每個頁面中都可以訪問..變數中的值了。

其實ASP一共內建了7個物件，有Session、Application、Cookie、Response、Request、Server等。在其他的伺服器端指令碼語言如JSP、PHP等中也有其類似的物件，只是叫法或者使用方法上不太一樣。

ASP Session的功能的缺陷

目前ASP的開發人員都正在使用Session這一強大的功能，但是在他們使用的過程中卻發現了ASP Session有以下缺陷：

• 程序依賴性：ASP Session狀態存於IIS的程序中，也就是inetinfo.exe這個程式。所以當inetinfo.exe程序崩潰時，這些資訊也就丟失。另外，重起或者關閉IIS服務都會造成資訊的丟失。
• Session 狀態使用範圍的侷限性：剛一個使用者從一個網站訪問到另外一個網站時，這些Session資訊並不會隨之遷移過去。例如：新浪網站的WWW伺服器可能不止一個，一個使用者登入之後要去各個頻道瀏覽，但是每個頻道都在不同的伺服器上，如果想在這些WWW伺服器共享Session資訊怎麼辦呢？
• Cookie的依賴性：實際上客戶端的Session資訊是儲存與Cookie中的，如果客戶端完全禁用掉了Cookie功能，他也就不能享受到了Session提供的功能了。

鑑於ASP Session的以上缺陷，微軟的設計者們在設計開發 ASP.NET Session時進行了相應的改進，完全克服了以上缺陷，使得ASP.NET Session成為了一個更加強大的功能。

Web.config檔案簡介

有的ASP.NET程式設計師說：Web.config檔案？我從來沒有聽說過啊，可是我寫的程式不是也能很正常的運轉嗎？是的，你說得沒錯，沒有 Web.config檔案程式是可以正常執行的。但是，如果你做了一個大型的網站，需要對整個網站做一些整體配置，例如整個網站的頁面使用何種語言編寫的、網站的安全認證模式、Session資訊儲存方式等，這時你就需要使用Web.config檔案了。雖然Web.config檔案中的某些選項是可以通過IIS配置的，但是如果在Web.config中也有相應的設定就會覆蓋掉IIS中的配置。而且，Web.config檔案的最大的便利之處就是可以在ASP.NET頁面中通過呼叫System.web名字空間訪問Web.config中的設定。

Web.config有兩種，分別是伺服器配置檔案和Web應用程式配置檔案，他們都名為Web.config。在這個配置檔案中會儲存當前IIS伺服器中網頁的使用哪種語言編寫的、應用程式安全認證模式、Session資訊儲存方式的一系列資訊。這些資訊是使用XML語法儲存的，如果想對其編輯，使用文字編輯器就行了。

其中伺服器配置檔案會對IIS伺服器下所有的站點中的所有應用程式起作用。在.NET Framework 1.0中，伺服器的Web.config檔案是存在：\WinNT\Microsoft.NET\Framework\v1.0.3705中的。

而 Web應用程式配置檔案Web.config則儲存在各個Web應用程式中。例如：當前網站的根目錄\Inetpub\wwwroot，而當前的Web應用程式為MyApplication，則Web應用程式根目錄就應為：\Inetpub\wwwroot\MyApplication。如果你的網站有且只有一個Web應用程式，一般說來應用程式的根目錄就是\Inetpub\wwwroot。如果想新增一個Web應用程式，在IIS中新增一個具有應用程式起始點的虛擬目錄就行了。這個目錄下的檔案及目錄將被視為一個Web應用程式。但是，這樣通過IIS新增Web應用程式是不會為你生成 Web.config檔案的。如果想建立一個帶有Web.config檔案的Web應用程式，需要使用Visual Studio.NET，新建一個Web應用程式專案。

Web應用程式的配置檔案Web.config是可選的，可有可無。如果沒有，每個Web應用程式會使用伺服器的Web.config配置檔案。如果有，則會覆蓋伺服器Web.config配置檔案中相應的值。

在ASP.NET中，Web.config修改儲存後會自動立刻成效，不用再像ASP中的配置檔案修改後需要重新啟動Web應用程式才能生效了。

Web.config檔案中的Session配置資訊

開啟某個應用程式的配置檔案Web.config後，我們會發現以下這段：

這一段就是配置應用程式是如何儲存Session資訊的了。我們以下的各種操作主要是針對這一段配置展開。讓我們先看看這一段配置中所包含的內容的意思。sessionState節點的語法是這樣的：

<sessionState mode="Off|InProc|StateServer|SQLServer"
                          cookieless="true|false"
                          timeout="number of minutes"
                          stateConnectionString="tcpip=server:port"
                          sqlConnectionString="sql connection string"
                          stateNetworkTimeout="number of seconds"
            />

必須有的屬性是

可選的屬性是：

ASP.NET中客戶端Session狀態的儲存

在我們上面的Session模型簡介中，大家可以發現Session狀態應該儲存在兩個地方，分別是客戶端和伺服器端。客戶端只負責儲存相應網站的 SessionID，而其他的Session資訊則儲存在伺服器端。在ASP中，客戶端的SessionID實際是以Cookie的形式儲存的。如果使用者在瀏覽器的設定中選擇了禁用Cookie，那末他也就無法享受Session的便利之處了，甚至造成不能訪問某些網站。為了解決以上問題，在 ASP.NET中客戶端的Session資訊儲存方式分為：Cookie和Cookieless兩種。

ASP.NET中，預設狀態下，在客戶端還是使用Cookie儲存Session資訊的。如果我們想在客戶端使用Cookieless的方式儲存Session資訊的方法如下：

找到當前Web應用程式的根目錄，開啟Web.Config檔案，找到如下段落：

這段話中的cookieless="false"改為：cookieless="true"，這樣，客戶端的Session資訊就不再使用Cookie儲存了，而是將其通過URL儲存。關閉當前的IE，開啟一個新IE，重新訪問剛才的Web應用程式，就會看到類似下面的樣子：

其中，http://localhost/MyTestApplication/(ulqsek45heu3ic2a5zgdl245)/default.aspx中黑體標出的就是客戶端的Session ID。注意，這段資訊是由IIS自動加上的，不會影響以前正常的連線。

ASP.NET中伺服器端Session狀態的儲存

準備工作

為了您能更好的體驗到實驗現象，您可以建立一個叫做SessionState.aspx的頁面，然後把以下這些程式碼新增到<body></body>中。

這個SessionState.aspx的頁面可以用來測試在當前的伺服器上是否丟失了Session資訊。

將伺服器Session資訊儲存在程序中

讓我們來回到Web.config檔案的剛才那段段落中：

當mode的值是InProc時，說明伺服器正在使用這種模式。

這種方式和以前ASP中的模式一樣，就是伺服器將Session資訊儲存在IIS程序中。當IIS關閉、重起後，這些資訊都會丟失。但是這種模式也有自己最大好處，就是效能最高。應為所有的Session資訊都儲存在了IIS的程序中，所以IIS能夠很快的訪問到這些資訊，這種模式的效能比程序外儲存 Session資訊或是在SQL Server中儲存Session資訊都要快上很多。這種模式也是ASP.NET的預設方式。

好了，現在讓我們做個試驗。開啟剛才的SessionState.aspx頁面，隨便輸入一些字元，使其儲存在Session中。然後，讓我們讓IIS重起。注意，並不是使當前的站點停止再開始，而是在IIS中本機的機器名的節點上點選滑鼠右鍵，選擇重新啟動IIS。(想當初使用NT4時，重新啟動IIS必須要重新啟動計算機才行，微軟真是@#$%^&)返回到SessionState.aspx頁面中，檢查剛才的Session資訊，發現資訊已經丟失了。

將伺服器Session資訊儲存在程序外

首先，讓我們來開啟管理工具->服務，找到名為：ASP.NET State Service的服務，啟動它。實際上，這個服務就是啟動一個要儲存Session資訊的程序。啟動這個服務後，你可以從Windows工作管理員 ->程序中看到一個名為aspnet_state.exe的程序，這個就是我們儲存Session資訊的程序。

然後，回到Web.config檔案中上述的段落中，將mode的值改為StateServer。儲存檔案後的重新開啟一個IE，開啟SessionState.aspx頁面，儲存一些資訊到Session中。這時，讓我們重起IIS，再回到SessionState.aspx頁面中檢視剛才的Session資訊，發現沒有丟失。

實際上，這種將Session資訊儲存在程序外的方式不光指可以將資訊儲存在本機的程序外，還可以將Session資訊儲存在其他的伺服器的程序中。這時，不光需要將mode的值改為StateServer，還需要在stateConnectionString中配置相應的引數。例如你的計算你是192.168.0.1，你想把Session儲存在IP為192.168.0.2的計算機的程序中，就需要設定成這樣：stateConnectionString="tcpip=192.168.0.2:42424"。當然，不要忘記在192.168.0.2的計算機中裝上.NET Framework，並且啟動ASP.NET State Services服務。

將伺服器Session資訊儲存在SQL Server中

首先，還是讓我們來做一些準備工作。啟動SQL Server和SQL Server代理服務。在SQL Server中執行一個叫做InstallSqlState.sql的指令碼檔案。這個指令碼檔案將在SQL Server中建立一個用來專門儲存Session資訊的資料庫，及一個維護Session資訊資料庫的SQL Server代理作業。我們可以在以下路徑中找到那個檔案：

然後開啟查詢分析器，連線到SQL Server伺服器，開啟剛才的那個檔案並且執行。稍等片刻，資料庫及作業就建立好了。這時，你可以開啟企業管理器，看到新增了一個叫ASPState的資料庫。但是這個資料庫中只是些儲存過程，沒有使用者表。實際上Session資訊是儲存在了tempdb資料庫的 ASPStateTempSessions表中的，另外一個ASPStateTempApplications表儲存了ASP中Application物件資訊。這兩個表也是剛才的那個指令碼建立的。另外檢視管理->SQL Server代理->作業，發現也多了一個叫做ASPState_Job_DeleteExpiredSessions的作業，這個作業實際上就是每分鐘去ASPStateTempSessions表中刪除過期的Session資訊的。

接著，我們返回到Web.config檔案，修改mode的值改為SQLServer。注意，還要同時修改sqlConnectionString的值，格式為：sqlConnectionString="data source=localhost; Integrated Security=SSPI;"，其中data source是指SQL Server伺服器的IP地址，如果SQL Server與IIS是一臺機子，寫127.0.0.1就行了。Integrated Security=SSPI的意思是使用Windows整合身份驗證，這樣，訪問資料庫將以ASP.NET的身份進行，通過如此配置，能夠獲得比使用 userid=sa;password=口令的SQL Server驗證方式更好的安全性。當然，如果SQL Server運行於另一臺計算機上，你可能會需要通過Active Directory域的方式來維護兩邊驗證的一致性。

同樣，讓我們做個試驗。向SessionState.aspx中新增Session資訊，這時發現Session資訊已經存在SQL Server中了，即使你重起計算機，剛才的Session資訊也不會丟失。現在，你已經完全看見了Session資訊到底是什麼樣子的了，而且又是儲存在SQL Server中的，能幹什麼就看你的發揮了，哈哈。