Server Load Balancer環境下的ASP會話管理(1)
最後更新:2017-02-28
來源:互聯網
上載者:User
建立互動式web 頁面時最大的挑戰之一是維持使用者的狀態,一個網站也許想記住你是誰、在n頁之前你點擊了什麼、在這最
後一次做了些什麼、現在馬上要向你顯示什麼。實現這些功能的途徑有許多,如查詢字串、提交表單或cookies,最強大
的一種是ASP的Session 對象。
原文出處:http://www.asptoday.com/articles/20000118.htm 當使用者第一次到達某網站,他/她被給予一個HTTP
cookie格式的SessionID (是一個唯讀屬性,
為每個使用者返回session 識別號)。然後伺服器可以在session 集合中跟蹤一整群的變數,通過
與使用者的session cookie相匹配來保持每個使用者有一個特定變數。只要使用者在伺服器上保持活躍,
session 變數就維持它的狀態。一個session 變數的預設有效時間是20分鐘,或者是每當使用者關閉
瀏覽器,這時無論session_OnEnd 部分是什麼內容,global.asa 檔案都運行。
以上陳述的關鍵是“在伺服器上保持啟用狀態”。每個session變數都在網路伺服器上設定,並保持在
本地記憶體中。所以,如果你在一個web 範圍內使用Server Load Balancer怎麼辦?(Server Load Balancer的介紹請見
msdn 文章 ‘ASP and Web Session Management’)。對真正的Server Load Balancer來說,每當居住於伺服器
上的使用者點擊一個串連時,它就改變伺服器的狀態,每當瀏覽一個新頁面時都潛在地丟失他們的
session 資訊。
如果你發現自己是在這樣的環境下編寫代碼--或者你懷疑你的網站最終是Server Load Balancer的--你有4種方法
來解決這個問題。
○ 完全不使用session 。
○ 使用臨時cookies 。
○ 購買第三方組件來處理session 管理。
○ 僅對web 範圍內的第一次點擊進行Server Load Balancer。
本文將討論這四種選擇,並解釋它們分別在何時何地最適用。
根本不使用sessions
顯然,饒過sessions 管理這個問題的一個途徑就是根本不使用sessions 變數。但是你仍然受困於
狀態保持的問題。你可以使用最簡單的方法跟蹤使用者,而不用寫客戶機。
一種不安全的方法是使用瀏覽器查詢字串,或用隱藏值進行表單置入,以使使用者保持活躍狀態。
這將允許你給他們一個使用者id,並將變數儲存在一個所有的web伺服器都能到達的地方。比如說
我保持了變數 ShipToZipCode、 TypeOfCustomer和 CustomerEmail。可以這樣寫:
< form action="/nextpage.asp" method="post" >
Item Number: < input type=text name="ItemNumber" >< br >
Quantity: < input type=text name="Quantity" >< br >
Unit Cost:< input type=text name="UnitCost" >< br >
< input type=hidden value="ABXXXKJR8JSDFI12KJIL2H75CX45X2" name="sessionid" >
< input type=submit value="post form" >
< /form >
然後,在 nextpage.asp上, 可以做以下工作:
Set conn=Server.CreateObject(ADODB.Connection)
Set SessionRS = conn.execute("Select ShipToZipCode, TypeOfCustomer, _ CustomerEmail from TblSession where
SessionID =" & request.form("sessionid"))
ShipToZipCode = SesssionRs("ShipToZipCode")
TypeOfCustomer = SesssionRs("TypeOfCustomer")
CustomerEmail = SesssionRs("CustomerEmail")
這樣通過將所有的"session" 資訊儲存在資料庫中,可以使這三個變數在每一頁上都保持活躍。確保
使用者id的值很難猜到,這很重要。當訪問第一頁時,將分配給使用者的sessionID 儲存為使用者名稱。當使用者
離開這一頁時可以考慮清除這個資料,有效地重建ASP session 對象。這可以手工完成,或者用
一個限時程式將數周以上的記錄刪除。
使用臨時Cookies
對於特別的非敏感性資料,直接向客戶機中寫入資訊是有意義的。比如說,如果我的網站只使用了一個
變數來跟蹤使用者的ZIP 碼來得到使用者在當地的交通記錄,那麼以HTTP cookie的形式將使用者的ZIP碼
寫入他們的機器應該不會產生什麼危害。因為你可以將cookie寫成瀏覽器關閉時失效,就可以使它們
模仿一個session 變數的功能,也可以使他們是持久的,好在使用者下一次訪問時記住他。
用Request 對象Cookie 的值可以為伺服器所用。請求Cookie 的值,然後將值帶進來。所以在我們上面
的例子中,可以這樣做:
ShipToZipCode = Request.Cookies("SessionCookie")("ShipToZipCode")
TypeOfCustomer = Request.Cookies("SessionCookie")("TypeOfCustomer")
CustomerEmail = Request.Cookies("SessionCookie")("CustomerEmail")
你不得不把這些放置在每個頁面的頂部,但是如果使用者把三個cookies 都設定了,那麼每一頁都可以
存取和使用這些使用者特定的變數。你還可以在一個cookie中設定三個變數,請看Ken Baumbach的文章
Cookie Basics with ASP,裡面有設定變數的更多資訊。
如果你認為使用者可能在瀏覽器上使Cookie 無效,這種方法就不適用。但是越來越多的網站要求使用
cookies,web 使用者也越來越熟練了。有可能相對很少的使用者會使cookies無效,但是這要在執行
這一方法之前進行考慮。
雖然上面的方法肯定能奏效,但是它們削弱了ASP的功能,因為它限制了其中一個關鍵組件--Session
對象的使用。要避免由Server Load Balancer導致的這種限制,繼續使用sessions的一種方法是購買一個第三方
組件,可以比IIS更好地處理Session。
在本文中,我不想比較各種第三方組件的優缺點。但是我聽說有一個組件工作得挺好,是SoftArtisans
提供的,叫做 SA-Session Pro。它使用NT檔案系統儲存使用者的資訊,整個網路範圍內的伺服器都可以
使用。其它第三方組件建立“session 引擎”把網路伺服器和session 管理器分離。這樣,每次使用者
都可以被重新導向到相同的session 引擎,同時也對伺服器本身的點擊進行Server Load Balancer。
另一個可選擇的第三方組件是Microsoft的成員伺服器。它與Microsoft的站台伺服器,它允許一個
網站處理狀態維護以外的問題。在Bill Pitzer的文章‘Moving your "Anonymous" visitors to
registered status using Site Server and Membership Directory Authentication’中有更多的
資訊。
由於ASP已經越來越成為企業級網路應用程式的選擇,而Server Load Balancer也成為這些應用程式成功的最大威脅,
在市場上會出現越來越多的第三方組件。ASP本身就是伺服器對象或ActiveX組件,就是可以處理這些
外掛程式的。