|
HTTP是一種無狀態(tài)協(xié)議。當(dāng)客戶機向服務(wù)器發(fā)送一個請求時，服務(wù)器并不知道這是客戶機的第1個還是第42個請求。這對ASP開發(fā)來說無異帶來了比較嚴(yán)重的問題，因為經(jīng)常有必要給特定的客戶機關(guān)聯(lián)服務(wù)器方變量。比方說，網(wǎng)站在向我發(fā)送我訂購的Jethro Tull CD同時向其他人發(fā)送Barry Manilow CD就是因為這一關(guān)聯(lián)的重要作用。ASP通過稱為會話ID的唯一的客戶標(biāo)識符處理這種關(guān)聯(lián)關(guān)系，當(dāng)客戶在開始他或她的瀏覽器會話時就會被分配這種會話ID。
現(xiàn)在讓我們看看傳統(tǒng)的ASP和現(xiàn)代的ASP.NET圍繞會話ID的使用而存在的一些問題。然后，我們討論下運行多個Web服務(wù)器時的會話問題。
什么是會話ID
會話ID是一種唯一標(biāo)識當(dāng)前訪問服務(wù)器的客戶的只讀值。在經(jīng)典的ASP環(huán)境下，會話ID是按照順序方式被分配的，也就是說，會話ID 706616433之后跟著會話 ID 706616434等等。傳統(tǒng)的ASP會話ID以加密的、非持久存在的cookie形式保存在客戶機上。例如，會話ID 706616434就可能作為cookie ASPSESSIONIDGQQGQGCS=JHMBOBKCBINEHLPKJHOPABBE保存在客戶機上。
ASP.NET下的會話ID有所變化。在使用 ASP.NET 時，會話ID是由URL合法ASCII字符組成的一個120位字符串。根據(jù)微軟文檔的說明，產(chǎn)生會話 ID 值采用了保證其唯一性的算法，從而避免出現(xiàn)兩個客戶試圖采用同一ID時出現(xiàn)的會話沖突。另外，會話ID的隨機性使得確定現(xiàn)有會話的ID變得非常困難從而帶來了額外的安全性。同傳統(tǒng)ASP一樣，ASP.NET的會話ID通常也作為非持久保存的cookie存儲在客戶機上。這種cookie的格式同傳統(tǒng)ASP相比稍有變化，例如，asp.net_sessionid=jhmbobkcbinehlpkjhopabbe。
除了維持狀態(tài)的傳統(tǒng)型的、非持久保存的cookie的方法之外，ASP.NET還支持一種不采用cookie的會話狀態(tài)維持模式。在啟用無cookie模式的情況下，ASP.NET在發(fā)送回客戶機的URL中嵌入會話ID。這樣就為使用不支持cookie或禁用cookie瀏覽器的客戶提供了會話狀態(tài)堅持�？紤]到利用cookie跟蹤客戶信息的舉動，我們有理由對無Cookie模式保持高度的關(guān)注。
如何使用會話ID
客戶每發(fā)出一個請求，包含加密會話ID的cookie在存在的情況下即被發(fā)送給服務(wù)器。服務(wù)器隨后確定cookie所關(guān)聯(lián)的會話ID并恢復(fù)關(guān)聯(lián)該客戶的所有會話變量。如果cookie不存在就會生成一個新的會話ID，同時加密的會話ID cookie則被發(fā)送給客戶機。這樣就能讓ASP跟蹤訪問網(wǎng)站的單個客戶了。同時，以上機制還促使ASP建立服務(wù)器方會話變量同單一會話的關(guān)聯(lián)關(guān)系。會話變量則被劃分為兩種類型：
內(nèi)容集合
靜態(tài)對象（StaticObject）集合
ASP和ASP.NET下的內(nèi)容集合（Contents Collection）會話變量都根據(jù)會話ID關(guān)聯(lián)特定的客戶。這些變量其實就是一個聯(lián)合數(shù)組，類似于Visual Basic的集合（Collection）對象。會話變量的原理完全一樣；唯一的本質(zhì)差別是它們同一個特定會話相聯(lián)系。而集合對象則可以通過唯一鍵保存和檢索任何類型的數(shù)組成員。
靜態(tài)對象（StaticObject）集合包含了會話范圍內(nèi)、用GLOBAL.ASA的<OBJECT>標(biāo)簽添加到應(yīng)用程序中所有對象。同內(nèi)容集合一樣，StaticObject集合也是一個聯(lián)合數(shù)組，其訪問方式也相同。不過，StaticObject集合僅僅包含了用<OBJECT>實例化的對象而并不包含那些用Server.CreateObject方法實例化的對象。
一個客戶就只有一個會話ID嗎
對單一Web服務(wù)器而言，維護狀態(tài)在任何情況下都是自動的�？蛻裟艿玫蕉抑荒艿玫轿ㄒ坏囊粋�會話ID，而且，只要網(wǎng)站上客戶保持在活動狀態(tài)，會話信息就會受到服務(wù)器的維持。然而，如果Web服務(wù)器超過一個，或者單獨的應(yīng)用程序位于某一虛擬目錄下而該目錄又駐留在其他應(yīng)用程序的虛擬目錄下時，維持狀態(tài)就變得更復(fù)雜了。
在分配會話ID時，每個服務(wù)器都是獨立進行操作的。因為這一緣故，Web服務(wù)器A就并不知道Web服務(wù)器B已經(jīng)把會話ID 706616434分配給了某一客戶。因此，如果Web服務(wù)器A收到具有會話ID 706616434的客戶請求，這一請求會被當(dāng)作會話超時進行處理，Web服務(wù)器A隨即分配一個新的會話ID。在發(fā)生這種情況時，客戶在Web服務(wù)器B上就失去了自己的狀態(tài)，而且在可能發(fā)生重復(fù)操作的情況下必須從頭開始。避免出現(xiàn)這一問題方法之一就是保證客戶的所有請求都被發(fā)送給了同一服務(wù)器。
在虛擬目錄下運行應(yīng)用程序是實現(xiàn)同一Web服務(wù)器上隔離運行多個應(yīng)用程序的方法之一。但是你得記住，當(dāng)某一個應(yīng)用程序調(diào)用另一應(yīng)用程序時就會產(chǎn)生新的會話ID。這樣就會丟棄第1個會話 ID及其關(guān)聯(lián)存儲的所有會話變量。取決于應(yīng)用程序的具體情況，狀態(tài)的丟失可能并不成為問題，但在調(diào)試會話時對此問題必須有足夠的認識。
小結(jié)
ASP足以應(yīng)對創(chuàng)建持久的Web應(yīng)用程序所面臨的最大挑戰(zhàn)??維護狀態(tài)。ASP的狀態(tài)維護機制令開發(fā)者無須創(chuàng)造自己專有的狀態(tài)維護機制就能開發(fā)出滿意的應(yīng)用程序。使用ASP、事先周密計劃再加上努力的工作就可能創(chuàng)建出穩(wěn)固的持久性應(yīng)用程序。
| 
