session详解文档格式.docx

session详解文档格式.docx

《session详解文档格式.docx》由会员分享，可在线阅读，更多相关《session详解文档格式.docx（12页珍藏版）》请在冰豆网上搜索。

“保持狀態”則是指通信的一方能夠把一系列的消息關聯起來，使得消息之間可以互相依賴，比如一個服務員能夠認出再次光臨的老顧客並且記得上次這個顧客還欠店裏一塊錢。

這一類的例子有“一個TCPsession”或者“一個POP3session”③。

而到了web伺服器蓬勃發展的時代，session在web開發語境下的語義又有了新的擴展，它的含義是指一類用來在用戶端與伺服器之間保持狀態的解決方案④。

有時候session也用來指這種解決方案的存儲結構，如“把xxx保存在session裏”⑤。

由於各種用於web開發的語言在一定程度上都提供了對這種解決方案的支持，所以在某種特定語言的語境下，session也被用來指代該語言的解決方案，比如經常把Java裏提供的javax.servlet.http.HttpSession簡稱為session⑥。

鑒於這種混亂已不可改變，本文中session一詞的運用也會根據上下文有不同的含義，請大家注意分辨。

在本文中，使用中文“流覽器會話期間”來表達含義①，使用“session機制”來表達含義④，使用“session”表達含義⑤，使用具體的“HttpSession”來表達含義⑥

2、HTTP協定與狀態保持

HTTP協定本身是無狀態的，這與HTTP協定本來的目的是相符的，用戶端只需要簡單的向伺服器請求下載某些檔，無論是用戶端還是伺服器都沒有必要紀錄彼此過去的行為，每一次請求之間都是獨立的，好比一個顧客和一個自動售貨機或者一個普通的（非會員制）大賣場之間的關係一樣。

然而聰明（或者貪心？

）的人們很快發現如果能夠提供一些按需生成的動態資訊會使web變得更加有用，就像給有線電視加上點播功能一樣。

這種需求一方面迫使HTML逐步添加了表單、腳本、DOM等用戶端行為，另一方面在伺服器端則出現了CGI規範以回應用戶端的動態請求，作為傳輸載體的HTTP協議也添加了檔上載、cookie這些特性。

其中cookie的作用就是為了解決HTTP協定無狀態的缺陷所作出的努力。

至於後來出現的session機制則是又一種在用戶端與伺服器之間保持狀態的解決方案。

讓我們用幾個例子來描述一下cookie和session機制之間的區別與聯繫。

筆者曾經常去的一家咖啡店有喝5杯咖啡免費贈一杯咖啡的優惠，然而一次性消費5杯咖啡的機會微乎其微，這時就需要某種方式來紀錄某位元顧客的消費數量。

想像一下其實也無外乎下面的幾種方案：

1、該店的店員很厲害，能記住每位顧客的消費數量，只要顧客一走進咖啡店，店員就知道該怎麼對待了。

這種做法就是協定本身支援狀態。

2、發給顧客一張卡片，上面記錄著消費的數量，一般還有個有效期限。

每次消費時，如果顧客出示這張卡片，則此次消費就會與以前或以後的消費相聯繫起來。

這種做法就是在用戶端保持狀態。

3、發給顧客一張會員卡，除了卡號之外什麼資訊也不紀錄，每次消費時，如果顧客出示該卡片，則店員在店裏的紀錄本上找到這個卡號對應的紀錄添加一些消費資訊。

這種做法就是在伺服器端保持狀態。

由於HTTP協定是無狀態的，而出於種種考慮也不希望使之成為有狀態的，因此，後面兩種方案就成為現實的選擇。

具體來說cookie機制採用的是在用戶端保持狀態的方案，而session機制採用的是在伺服器端保持狀態的方案。

同時我們也看到，由於採用伺服器端保持狀態的方案在用戶端也需要保存一個標識，所以session機制可能需要借助於cookie機制來達到保存標識的目的，但實際上它還有其他選擇。

3、理解cookie機制

cookie機制的基本原理就如上面的例子一樣簡單，但是還有幾個問題需要解決：

“會員卡”如何分發；

“會員卡”的內容；

以及客戶如何使用“會員卡”。

正統的cookie分發是通過擴展HTTP協定來實現的，伺服器通過在HTTP的回應頭中加上一行特殊的指示以提示流覽器按照指示生成相應的cookie。

然而純粹的用戶端腳本如JavaScript或者VBScript也可以生成cookie。

而cookie的使用是由流覽器按照一定的原則在後臺自動發送給伺服器的。

流覽器檢查所有存儲的cookie，如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給伺服器。

意思是麥當勞的會員卡只能在麥當勞的店裏出示，如果某家分店還發行了自己的會員卡，那麼進這家店的時候除了要出示麥當勞的會員卡，還要出示這家店的會員卡。

cookie的內容主要包括：

名字，值，過期時間，路徑和域（Domain）。

其中域（Domain）可以指定某一個域比如，相當於總店招牌，比如寶潔公司，也可以指定一個域下的具體某台機器比如或者，可以用飄柔來做比。

路徑就是跟在功能變數名稱後面的URL路徑，比如/或者/foo等等，可以用某飄柔專櫃做比。

路徑與域合在一起就構成了cookie的作用範圍。

如果不設置過期時間，則表示這個cookie的生命期為流覽器會話期間，只要關閉流覽器窗口，cookie就消失了。

這種生命期為流覽器會話期的cookie被稱為會話cookie。

會話cookie一般不存儲在硬碟上而是保存在記憶體裏，當然這種行為並不是規範規定的。

如果設置了過期時間，流覽器就會把cookie保存到硬碟上，關閉後再次打開流覽器，這些cookie仍然有效直到超過設定的過期時間。

存儲在硬碟上的cookie可以在不同的流覽器進程間共用，比如兩個IE視窗。

而對於保存在記憶體裏的cookie，不同的流覽器有不同的處理方式。

對於IE，在一個打開的視窗上按Ctrl-N（或者從檔功能表）打開的視窗可以與原視窗共用，而使用其他方式新開的IE進程則不能共用已經打開的視窗的記憶體cookie；

對於MozillaFirefox0.8，所有的進程和標籤頁都可以共用同樣的cookie。

一般來說是用javascript的window.open打開的視窗會與原視窗共用記憶體cookie。

流覽器對於會話cookie的這種只認cookie不認人的處理方式經常給採用session機制的web應用程式開發者造成很大的困擾。

下面就是一個goolge設置cookie的響應頭的例子

HTTP/1.1302Found

Location:

Set-Cookie:

PREF=ID=0565f77e132de138:

NW=1:

TM=1098082649:

LM=1098082649:

S=KaeaCFPo49RiA_d8;

expires=Sun,17-Jan-203819:

14:

07GMT;

path=/;

domain=

Content-Type:

text/html

這是使用HTTPLook這個HTTPSniffer軟體來俘獲的HTTP通訊紀錄的一部分

流覽器在再次訪問goolge的資源時自動向外發送cookie

使用Firefox可以很容易的觀察現有的cookie的值

使用HTTPLook配合Firefox可以很容易的理解cookie的工作原理。

IE也可以設置在接受cookie前詢問

這是一個詢問接受cookie的對話方塊。

4、理解session機制

session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構（也可能就是使用散列表）來保存資訊。

當程式需要為某個用戶端的請求創建一個session的時候，伺服器首先檢查這個用戶端的請求裏是否已包含了一個session標識-稱為sessionid，如果已包含一個sessionid則說明以前已經為此用戶端創建過session，伺服器就按照sessionid把這個session檢索出來使用（如果檢索不到，可能會新建一個），如果用戶端請求不包含sessionid，則為此用戶端創建一個session並且生成一個與此session相關聯的sessionid，sessionid的值應該是一個既不會重複，又不容易被找到規律以仿造的字串，這個sessionid將被在本次回應中返回給用戶端保存。

保存這個sessionid的方式可以採用cookie，這樣在交互過程中流覽器可以自動的按照規則把這個標識發揮給伺服器。

一般這個cookie的名字都是類似於SEEESIONID，而。

比如weblogic對於web應用程式生成的cookie，JSESSIONID=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!

-145788764，它的名字就是JSESSIONID。

由於cookie可以被人為的禁止，必須有其他機制以便在cookie被禁止時仍然能夠把sessionid傳遞回伺服器。

經常被使用的一種技術叫做URL重寫，就是把sessionid直接附加在URL路徑的後面，附加方式也有兩種，一種是作為URL路徑的附加資訊，表現形式為http:

//...../xxx;

jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!

-145788764

另一種是作為查詢字串附加在URL後面，表現形式為http:

//...../xxx?

這兩種方式對於用戶來說是沒有區別的，只是伺服器在解析的時候處理的方式不同，採用第一種方式也有利於把sessionid的資訊和正常程式參數區分開來。

為了在整個交互過程中始終保持狀態，就必須在每個用戶端可能請求的路徑後面都包含這個sessionid。

另一種技術叫做表單隱藏欄位。

就是伺服器會自動修改表單，添加一個隱藏欄位，以便在表單提交時能夠把sessionid傳遞回伺服器。

比如下麵的表單

<

formname="

testform"

action="

/xxx"

>

inputtype="

text"

/form>

在被傳遞給用戶端之前將被改寫成

hidden"

name="

jsessionid"

value="

ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!

-145788764"

這種技術現在已較少應用，筆者接觸過的很古老的iPlanet6（SunONE應用伺服器的前身）就使用了這種技術。

實際上這種技術可以簡單的用對action應用URL重寫來代替。

在談論session機制的時候，常常聽到這樣一種誤解“只要關閉流覽器，session就消失了”。

其實可以想像一下會員卡的例子，除非顧客主動對店家提出銷卡，否則店家絕對不會輕易刪除顧客的資料。

對session來說也是一樣的，除非程式通知伺服器刪除一個session，否則伺服器會一直保留，程式一般都是在用戶做logoff的時候發個指令去刪除session。

然而流覽器從來不會主動在關閉之前通知伺服器它將要關閉，因此伺服器根本不會有機會知道流覽器已經關閉，之所以會有這種錯覺，是大部分session機制都使用會話cookie來保存sessionid，而關閉流覽器後這個sessionid就消失了，再次連接伺服器時也就無法找到原來的session。

如果伺服器設置的cookie被保存到硬碟上，或者使用某種手段改寫流覽器發出的HTTP請求頭，把原來的sessionid發送給伺服器，則再次打開流覽器仍然能夠找到原來的session。

恰恰是由於關閉流覽器不會導致session被刪除，迫使伺服器為seesion設置了一個失效時間，當距離用戶端上一次使用session的時間超過這個失效時間時，伺服器就可以認為用戶端已經停止了活動，才會把session刪除以節省存儲空間。

5、理解javax.servlet.http.HttpSession

HttpSession是Java平臺對session機制的實現規範，因為它僅僅是個介面，具體到每個web應用伺服器的提供商，除了對規範支援之外，仍然會有一些規範裏沒有規定的細微差異。

這裏我們以BEA的WeblogicServer8.1作為例子來演示。

首先，WeblogicServer提供了一系列的參數來控制它的HttpSession的實現，包括使用cookie的開關選項，使用URL重寫的開關選項，session持久化的設置，session失效時間的設置，以及針對cookie的各種設置，比如設置cookie的名字、路徑、域，cookie的生存時間等。

一般情況下，session都是存儲在記憶體裏，當伺服器進程被停止或者重啟的時候，記憶體裏的session也會被清空，如果設置了session的持久化特性，伺服器就會把session保存到硬碟上，當伺服器進程重新啟動或這些資訊將能夠被再次使用，WeblogicServer支援的持久性方式包括檔、資料庫、用戶端cookie保存和複製。

複製嚴格說來不算持久化保存，因為session實際上還是保存在記憶體裏，不過同樣的資訊被複製到各個cluster內的伺服器進程中，這樣即使某個伺服器進程停止工作也仍然可以從其他進程中取得session。

cookie生存時間的設置則會影響流覽器生成的cookie是否是一個會話cookie。

默認是使用會話cookie。

有興趣的可以用它來試驗我們在第四節裏提到的那個誤解。

cookie的路徑對於web應用程式來說是一個非常重要的選項，WeblogicServer對這個選項的默認處理方式使得它與其他伺服器有明顯的區別。

後面我們會專題討論。

關於session的設置參考[5]http:

//e-

6、HttpSession常見問題

（在本小節中session的含義為⑤和⑥的混合）

1、session在何時被創建

一個常見的誤解是以為session在有用戶端訪問時就被創建，然而事實是直到某server端程式調用HttpServletRequest.getSession（true）這樣的語句時才被創建，注意如果JSP沒有顯示的使用<

%@pagesession="

false"

%>

關閉session，則JSP檔在編譯成Servlet時將會自動加上這樣一條語句HttpSessionsession=HttpServletRequest.getSession（true）;

這也是JSP中隱含的session物件的來歷。

由於session會消耗記憶體資源，因此，如果不打算使用session，應該在所有的JSP中關閉它。

2、session何時被刪除

綜合前面的討論，session在下列情況下被刪除

a.程式調用HttpSession.invalidate（）;

b.距離上一次收到用戶端發送的sessionid時間間隔超過了session的超時設置;

c.伺服器進程被停止（非持久session）

3、如何做到在流覽器關閉時刪除session

嚴格的講，做不到這一點。

可以做一點努力的辦法是在所有的用戶端頁面裏使用javascript代碼window.oncolose來監視流覽器的關閉動作，然後向伺服器發送一個請求來刪除session。

但是對於流覽器崩潰或者強行殺死進程這些非常規手段仍然無能為力。

4、有個HttpSessionListener是怎麼回事

你可以創建這樣的listener去監控session的創建和銷毀事件，使得在發生這樣的事件時你可以做一些相應的工作。

注意是session的創建和銷毀動作觸發listener，而不是相反。

類似的與HttpSession有關的listener還有HttpSessionBindingListener，HttpSessionActivationListener和HttpSessionAttributeListener。

5、存放在session中的物件必須是可序列化的嗎

不是必需的。

要求物件可序列化只是為了session能夠在集群中被複製或者能夠持久保存或者在必要時server能夠暫時把session交換出記憶體。

在WeblogicServer的session中放置一個不可序列化的物件在控制臺上會收到一個警告。

我所用過的某個iPlanet版本如果session中有不可序列化的物件，在session銷毀時會有一個Exception，很奇怪。

6、如何才能正確的應付用戶端禁止cookie的可能性

對所有的URL使用URL重寫，包括超鏈結，form的action，和重定向的URL，具體做法參見[6]

http:

7、開兩個流覽器視窗訪問應用程式會使用同一個session還是不同的session

參見第三小節對cookie的討論，對session來說是只認id不認人，因此不同的流覽器，不同的視窗打開方式以及不同的cookie存儲方式都會對這個問題的答案有影響。

8、如何防止用戶打開兩個流覽器視窗操作導致的session混亂

這個問題與防止表單多次提交是類似的，可以通過設置用戶端的權杖來解決。

就是在伺服器每次生成一個不同的id返回給用戶端，同時保存在session裏，用戶端提交表單時必須把這個id也返回伺服器，程式首先比較返回的id與保存在session裏的值是否一致，如果不一致則說明本次操作已經被提交過了。

可以參看《J2EE核心模式》關於表示層模式的部分。

需要注意的是對於使用javascriptwindow.open打開的視窗，一般不設置這個id，或者使用單獨的id，以防主視窗無法操作，建議不要再window.open打開的視窗裏做修改操作，這樣就可以不用設置。

9、為什麼在WeblogicServer中改變session的值後要重新調用一次session.setValue

做這個動作主要是為了在集群環境中提示WeblogicServersession中的值發生了改變，需要向其他伺服器進程複製新的session值。

10、為什麼session不見了

排除session正常失效的因素之外，伺服器本身的可能性應該是微乎其微的，雖然筆者在iPlanet6SP1加若干補丁的Solaris版本上倒也遇到過；

流覽器插件的可能性次之，筆者也遇到過3721插件造成的問題；

理論上防火牆或者代理伺服器在cookie處理上也有可能會出現問題。

出現這一問題的大部分原因都是程式的錯誤，最常見的就是在一個應用程式中去訪問另外一個應用程式。

我們在下一節討論這個問題。

7、跨應用程式的session共用

常常有這樣的情況，一個大專案被分割成若干小專案開發，為了能夠互不干擾，要求每個小專案作為一個單獨的web應用程式開發，可是到了最後突然發現某幾個小專案之間需要共用一些資訊，或者想使用session來實現SSO（singlesignon），在session中保存login的用戶資訊，最自然的要求是應用程式間能夠訪問彼此的session。

然而按照Servlet規範，session的作用範圍應該僅僅限於當前應用程式下，不同的應用程式之間是不能夠互相訪問對方的session的。

各個應用伺服器從實際效果上都遵守了這一規範，但是實現的細節卻可能各有不同，因此解決跨應用程式session共用的方法也各不相同。

首先來看一下Tomcat是如何實現web應用程式之間session的隔離的，從Tomcat設置的cookie路徑來看，它對不同的應用程式設置的cookie路徑是不同的，這樣不同的應用程式所用的sessionid是不同的，因此即使在同一個流覽器視窗裏訪問不同的應用程式，發送給伺服器的sessionid也可以是不同的。

根據這個特性，我們可以推測Tomcat中session的記憶體結構大致如下。

筆者以前用過的iPlanet也採用的是同樣的方式，估計SunONE與iPlanet之間不會有太大的差別。

對於這種方式的伺服器，解決的思路很簡單，實際實行起來也不難。

要麼讓所有的應用程式共用一個sessionid，要麼讓應用程式能夠獲得其他應用程式的sessionid。

iPlanet中有一種很簡單的方法來實現共用一個sessionid，那就是把各個應用程式的cookie路徑都設為/（實際上應該是/NASApp，對於應用程式來講它的作用相當於根）。

session-info>

path>

/NASApp<

/path>

/session-info>

需要注意的是，操作共用的session應該遵循一些編程約定，比如在sessionattribute名字的前面加上應用程式的首碼，使得setAttribute（"

name"

"

neo"

）變成setAttribute（"

app1.name"

），以防止命名空間衝突，導致互相覆蓋。

在Tomcat中則沒有這麼方便的選擇。

在Tomcat版本3上，我們還可以有一些手段來共用session。

對於版本4以上的Tomcat，目前筆者尚未發現簡單的辦法。

只能借助于第三方的力量，比如使用檔、資料庫、JMS或者用戶端cookie，URL參數或者隱藏欄位