Session詳解 |
作者:郎雲鵬 來自:dev2dev |
作者:郎雲鵬(dev2dev ID: hippiewolf) 摘要:雖然session機制在web應用程序中被採用已經很長時間了,但是仍然有很多人不清楚session機制的本質,以至不能正確的應用這一技術。本文將詳細討論session的工作機制並且對在Java web application中應用session機制時常見的問題作出解答。 目錄: 一、術語session session,中文經常翻譯爲會話,其本來的含義是指有始有終的一系列動作/消息,比如打電話時從拿起電話撥號到掛斷電話這中間的一系列過程可以稱之爲一個session。有時候我們可以看到這樣的話“在一個瀏覽器會話期間,...”,這裏的會話一詞用的就是其本義,是指從一個瀏覽器窗口打開到關閉這個期間①。最混亂的是“用戶(客戶端)在一次會話期間”這樣一句話,它可能指用戶的一系列動作(一般情況下是同某個具體目的相關的一系列動作,比如從登錄到選購商品到結賬登出這樣一個網上購物的過程,有時候也被稱爲一個transaction),然而有時候也可能僅僅是指一次連接,也有可能是指含義 ①,其中的差別只能靠上下文來推斷②。 然而當session一詞與網絡協議相關聯時,它又往往隱含了“面向連接”和/或“保持狀態”這樣兩個含義,“面向連接”指的是在通信雙方在通信之前要先建立一個通信的渠道,比如打電話,直到對方接了電話通信才能開始,與此相對的是寫信,在你把信發出去的時候你並不能確認對方的地址是否正確,通信渠道不一定能建立,但對發信人來說,通信已經開始了。“保持狀態”則是指通信的一方能夠把一系列的消息關聯起來,使得消息之間可以互相依賴,比如一個服務員能夠認出再次光臨的老顧客並且記得上次這個顧客還欠店裏一塊錢。這一類的例子有“一個TCP session”或者“一個POP3 session”③。 而到了web服務器蓬勃發展的時代,session在web開發語境下的語義又有了新的擴展,它的含義是指一類用來在客戶端與服務器之間保持狀態的解決方案④。有時候session也用來指這種解決方案的存儲結構,如“把xxx保存在session裏”⑤。由於各種用於web開發的語言在一定程度上都提供了對這種解決方案的支持,所以在某種特定語言的語境下,session也被用來指代該語言的解決方案,比如經常把Java裏提供的 javax.servlet.http.HttpSession簡稱爲session⑥。 鑑於這種混亂已不可改變,本文中session一詞的運用也會根據上下文有不同的含義,請大家注意分辨。 二、HTTP協議與狀態保持 然而聰明(或者貪心?)的人們很快發現如果能夠提供一些按需生成的動態信息會使web變得更加有用,就像給有線電視加上點播功能一樣。這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等客戶端行爲,另一方面在服務器端則出現了CGI規範以響應客戶端的動態請求,作爲傳輸載體的HTTP協議也添加了文件上載、cookie這些特性。其中cookie的作用就是爲了解決HTTP協議無狀態的缺陷所作出的努力。至於後來出現的session機制則是又一種在客戶端與服務器之間保持狀態的解決方案。 讓我們用幾個例子來描述一下cookie和session機制之間的區別與聯繫。筆者曾經常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠,然而一次性消費5杯咖啡的機會微乎其微,這時就需要某種方式來紀錄某位顧客的消費數量。想象一下其實也無外乎下面的幾種方案: 由於HTTP協議是無狀態的,而出於種種考慮也不希望使之成爲有狀態的,因此,後面兩種方案就成爲現實的選擇。具體來說cookie機制採用的是在客戶端保持狀態的方案,而session機制採用的是在服務器端保持狀態的方案。同時我們也看到,由於採用服務器端保持狀態的方案在客戶端也需要保存一個標識,所以session機制可能需要藉助於cookie機制來達到保存標識的目的,但實際上它還有其他選擇。 三、理解cookie機制 正統的cookie分發是通過擴展HTTP協議來實現的,服務器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也可以生成cookie。 而cookie的使用是由瀏覽器按照一定的原則在後臺自動發送給服務器的。瀏覽器檢查所有存儲的cookie,如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置,則把該cookie附在請求資源的HTTP請求頭上發送給服務器。意思是麥當勞的會員卡只能在麥當勞的店裏出示,如果某家分店還發行了自己的會員卡,那麼進這家店的時候除了要出示麥當勞的會員卡,還要出示這家店的會員卡。 cookie的內容主要包括:名字,值,過期時間,路徑和域。 存儲在硬盤上的cookie可以在不同的瀏覽器進程間共享,比如兩個IE窗口。而對於保存在內存裏的cookie,不同的瀏覽器有不同的處理方式。對於IE,在一個打開的窗口上按Ctrl-N(或者從文件菜單)打開的窗口可以與原窗口共享,而使用其他方式新開的IE進程則不能共享已經打開的窗口的內存cookie;對於Mozilla Firefox0.8,所有的進程和標籤頁都可以共享同樣的cookie。一般來說是用javascript的window.open打開的窗口會與原窗口共享內存cookie。瀏覽器對於會話cookie的這種只認cookie不認人的處理方式經常給採用session機制的web應用程序開發者造成很大的困擾。 下面就是一個goolge設置cookie的響應頭的例子
四、理解session機制 當程序需要爲某個客戶端的請求創建一個session的時候,服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲session id,如果已包含一個session id則說明以前已經爲此客戶端創建過session,服務器就按照session id把這個session檢索出來使用(如果檢索不到,可能會新建一個),如果客戶端請求不包含session id,則爲此客戶端創建一個session並且生成一個與此session相關聯的session id,session id的值應該是一個既不會重複,又不容易被找到規律以仿造的字符串,這個session id將被在本次響應中返回給客戶端保存。 保存這個session id的方式可以採用cookie,這樣在交互過程中瀏覽器可以自動的按照規則把這個標識發揮給服務器。一般這個cookie的名字都是類似於 SEEESIONID,而。比如weblogic對於web應用程序生成的cookie,JSESSIONID= ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764,它的名字就是 JSESSIONID。 由於cookie可以被人爲的禁止,必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞迴服務器。經常被使用的一種技術叫做URL重寫,就是把session id直接附加在URL路徑的後面,附加方式也有兩種,一種是作爲URL路徑的附加信息,表現形式爲http://...../xxx; jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 另一種技術叫做表單隱藏字段。就是服務器會自動修改表單,添加一個隱藏字段,以便在表單提交時能夠把session id傳遞迴服務器。比如下面的表單 在談論session機制的時候,常常聽到這樣一種誤解“只要關閉瀏覽器,session就消失了”。其實可以想象一下會員卡的例子,除非顧客主動對店家提出銷卡,否則店家絕對不會輕易刪除顧客的資料。對session來說也是一樣的,除非程序通知服務器刪除一個session,否則服務器會一直保留,程序一般都是在用戶做log off的時候發個指令去刪除session。然而瀏覽器從來不會主動在關閉之前通知服務器它將要關閉,因此服務器根本不會有機會知道瀏覽器已經關閉,之所以會有這種錯覺,是大部分session機制都使用會話cookie來保存session id,而關閉瀏覽器後這個session id就消失了,再次連接服務器時也就無法找到原來的session。如果服務器設置的cookie被保存到硬盤上,或者使用某種手段改寫瀏覽器發出的 HTTP請求頭,把原來的session id發送給服務器,則再次打開瀏覽器仍然能夠找到原來的session。 恰恰是由於關閉瀏覽器不會導致session被刪除,迫使服務器爲seesion設置了一個失效時間,當距離客戶端上一次使用session的時間超過這個失效時間時,服務器就可以認爲客戶端已經停止了活動,纔會把session刪除以節省存儲空間。 五、理解javax.servlet.http.HttpSession 首先,Weblogic Server提供了一系列的參數來控制它的HttpSession的實現,包括使用cookie的開關選項,使用URL重寫的開關選項,session持久化的設置,session失效時間的設置,以及針對cookie的各種設置,比如設置cookie的名字、路徑、域,cookie的生存時間等。 一般情況下,session都是存儲在內存裏,當服務器進程被停止或者重啓的時候,內存裏的session也會被清空,如果設置了session的持久化特性,服務器就會把session保存到硬盤上,當服務器進程重新啓動或這些信息將能夠被再次使用,Weblogic Server支持的持久性方式包括文件、數據庫、客戶端cookie保存和複製。 複製嚴格說來不算持久化保存,因爲session實際上還是保存在內存裏,不過同樣的信息被複制到各個cluster內的服務器進程中,這樣即使某個服務器進程停止工作也仍然可以從其他進程中取得session。 cookie生存時間的設置則會影響瀏覽器生成的cookie是否是一個會話cookie。默認是使用會話cookie。有興趣的可以用它來試驗我們在第四節裏提到的那個誤解。 cookie的路徑對於web應用程序來說是一個非常重要的選項,Weblogic Server對這個選項的默認處理方式使得它與其他服務器有明顯的區別。後面我們會專題討論。 關於session的設置參考[5] http://e-docs.bea.com/wls/docs70/webapp/weblogic_xml.html#1036869 六、HttpSession常見問題
由於session會消耗內存資源,因此,如果不打算使用session,應該在所有的JSP中關閉它。 2、session何時被刪除 3、如何做到在瀏覽器關閉時刪除session 4、有個HttpSessionListener是怎麼回事 5、存放在session中的對象必須是可序列化的嗎 6、如何才能正確的應付客戶端禁止cookie的可能性 7、開兩個瀏覽器窗口訪問應用程序會使用同一個session還是不同的session 8、如何防止用戶打開兩個瀏覽器窗口操作導致的session混亂 9、爲什麼在Weblogic Server中改變session的值後要重新調用一次session.setValue 10、爲什麼session不見了 七、跨應用程序的session共享 然而按照Servlet規範,session的作用範圍應該僅僅限於當前應用程序下,不同的應用程序之間是不能夠互相訪問對方的session的。各個應用服務器從實際效果上都遵守了這一規範,但是實現的細節卻可能各有不同,因此解決跨應用程序session共享的方法也各不相同。 首先來看一下Tomcat是如何實現web應用程序之間session的隔離的,從Tomcat設置的cookie路徑來看,它對不同的應用程序設置的cookie路徑是不同的,這樣不同的應用程序所用的session id是不同的,因此即使在同一個瀏覽器窗口裏訪問不同的應用程序,發送給服務器的session id也可以是不同的。 根據這個特性,我們可以推測Tomcat中session的內存結構大致如下。 筆者以前用過的iPlanet也採用的是同樣的方式,估計SunONE與iPlanet之間不會有太大的差別。對於這種方式的服務器,解決的思路很簡單,實際實行起來也不難。要麼讓所有的應用程序共享一個session id,要麼讓應用程序能夠獲得其他應用程序的session id。 iPlanet中有一種很簡單的方法來實現共享一個session id,那就是把各個應用程序的cookie路徑都設爲/(實際上應該是/NASApp,對於應用程序來講它的作用相當於根)。 需要注意的是,操作共享的session應該遵循一些編程約定,比如在session attribute名字的前面加上應用程序的前綴,使得setAttribute("name", "neo")變成setAttribute("app1.name", "neo"),以防止命名空間衝突,導致互相覆蓋。
我們再看一下Weblogic Server是如何處理session的。 從截屏畫面上可以看到Weblogic Server對所有的應用程序設置的cookie的路徑都是/,這是不是意味着在Weblogic Server中默認的就可以共享session了呢?然而一個小實驗即可證明即使不同的應用程序使用的是同一個session,各個應用程序仍然只能訪問自己所設置的那些屬性。這說明Weblogic Server中的session的內存結構可能如下 對於這樣一種結構,在session機制本身上來解決session共享的問題應該是不可能的了。除了藉助於第三方的力量,比如使用文件、數據庫、 JMS或者客戶端cookie,URL參數或者隱藏字段等手段,還有一種較爲方便的做法,就是把一個應用程序的session放到 ServletContext中,這樣另外一個應用程序就可以從ServletContext中取得前一個應用程序的引用。示例代碼如下, 應用程序A 應用程序B 值得注意的是這種用法不可移植,因爲根據ServletContext的JavaDoc,應用服務器可以處於安全的原因對於context.getContext("/appA");返回空值,以上做法在Weblogic Server 8.1中通過。 那麼Weblogic Server爲什麼要把所有的應用程序的cookie路徑都設爲/呢?原來是爲了SSO,凡是共享這個session的應用程序都可以共享認證的信息。一個簡單的實驗就可以證明這一點,修改首先登錄的那個應用程序的描述符weblogic.xml,把cookie路徑修改爲/appA訪問另外一個應用程序會重新要求登錄,即使是反過來,先訪問cookie路徑爲/的應用程序,再訪問修改過路徑的這個,雖然不再提示登錄,但是登錄的用戶信息也會丟失。注意做這個實驗時認證方式應該使用FORM,因爲瀏覽器和web服務器對basic認證方式有其他的處理方式,第二次請求的認證不是通過session來實現的。具體請參看[7] secion 14.8 Authorization,你可以修改所附的示例程序來做這些試驗。 八、總結 |
Session詳解
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.