在web應用的開發中我們會經常看到這樣的url：http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x
session的實現方式
做web開發的同學都知道，http是無狀態的會話協議，也就是說無法保存用戶的信息。那如果有一些信息需要在用戶的瀏覽活動中一直保持，該怎麼做呢？我們可以把這些信息在每次請求的時候作爲參數傳遞給服務器，但這樣做既麻煩又耗費資源，這時候就體現出了session的重要性。session是web開發中不可或缺的一個特性。它是對於一個特定的用戶請求，在 web服務器上保存的一個全局變量。有了它我們就可以把用戶的一些信息保存在服務器上，而不用在服務器和客戶端之間來回傳遞。知道了session的作用，那session是怎麼實現的呢？服務器上爲每個用戶都保存了一個session，那當用戶請求過來的時候是怎麼知道某一個用戶應該對應哪個 session呢？這時jsessionid就派上用場了。每一個session都有一個id來作爲標識，這個id會傳到客戶端，每次客戶端請求都會把這個id傳到服務器，服務器根據id來匹配這次請求應該使用哪個session。jsessionid就是客戶端用來保存sessionid的變量，主要是針對j2ee實現的web容器，沒有研究過其他語言是用什麼變量來保存的。一般對於web應用來說，客戶端變量都會保存在cookie 中，jsessionid也不例外。不過與一般的cookie變量不同，jsessionid是保存在內存cookie中的，在一般的cookie文件中是看不到它的影子的。內存cookie在打開一個瀏覽器窗口的時候會創建，在關閉這個瀏覽器窗口的時候也同時銷燬。這也就解釋了爲什麼session變量不能跨窗口使用，要跨窗口使用就需要手動把jsessionid保存到cookie裏面。
jsessionid的作用
在以上的文字中我們瞭解了session的實現原理，同時也知道了session跟jsessionid緊密不可分割的聯繫。只有通過jsessionid才能使 session機制起作用，而jsessionid又是通過cookie來保存。看到這裏，也許你會發現一個問題，如果用戶禁用了cookie，那 jsessionid不是就不能保存了嗎？session不是不起作用了嗎？我們真的對此束手無策了嗎？當然不是。在用戶禁用了cookie時候，我們可以通過url重寫來實現jsessionid的傳遞。這就是我上面指出的那樣的url:http://www.xxx.com/xxx_app;jsessionid=xxxxxxxxxx?a=x&b=x..。 jessionid通過這樣的方式來從客戶端傳遞到服務器端，從而來標識session。注意一點，jsessionid跟一般的url參數傳遞方式是不同的，不是作爲參數跟在？後面，而是緊跟在url後面用；來分隔。這樣在用戶禁用cookie的時候我們也可以傳遞jsessionid來使用 session了，只不過需要每次都把jseesionid作爲參數跟在url後面傳遞。那這樣豈不是很麻煩，每次請求一個url都要判斷cookie是否可用，如果禁用了cookie，還要從url裏解析出jsessionid，然後跟在處理完後轉到的url後面，以保持jsessionid的傳遞。這些問題sun當然已經幫我們想到了，所以提供了2個方法來使事情變得簡單：response.encodeURL()和 response.encodeRedirectURL()。這2個方法會判斷cookie是否可用，如果禁用了會解析出url中的 jsessionid，並連接到指定的url後面，如果沒有找到jessionid會自動幫我們生成一個。至於爲什麼要有2個方法？這2個方法有什麼不同？google了一下，說是這2個方法在判斷是否要包含jsessionid的邏輯上會稍有不同。在調用 HttpServletResponse.sendRedirect前，應該先調用encodeRedirectURL()方法，否則可能會丟失 Sesssion信息。這2個方法的使用方法如：response.sendRedirect(response.encodeURL("/myapp /input.jsp"));。如果cookie沒有禁用，我們在瀏覽器地址欄中看到的地址是這樣的：/myapp/input.jsp，如果禁用了 cookie，我們會看到：/myapp /input.jsp;jsessionid=73E6B2470C91A433A6698C7681FD44F4。所以，我們在寫web應用的時候，爲了保險起見，應該在程序裏的每一個跳轉url上都使用這2個方法，來保證session的可用性。
說道這裏，大家應該對jsessionid和session的關係，以及jsessionid的作用有個了一個大致的瞭解，具體應用還要自己在項目中具體情況具體對待。
=============================================================================================
jsessionid=CA72488F94BC8A3E92FEEDA8CC736FDC 這個jsessionid是session的一個標識。 我在這裏轉貼jdbc老大的部分講解 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 另一種是作爲查詢字符串附加在URL後面，表現形式爲http://..... /xxx?jsessionid=ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764 這兩種方式對於用戶來說是沒有區別的，只是服務器在解析的時候處理的方式不同，採用第一種方式也有利於把session id的信息和正常程序參數區分開來。爲了在整個交互過程中始終保持狀態，就必須在每個客戶端可能請求的路徑後面都包含這個session id。 另一種技術叫做表單隱藏字段。就是服務器會自動修改表單，添加一個隱藏字段，以便在表單提交時能夠把session id傳遞迴服務器。比如下面的表單<form name="testform" action="/xxx"><input type="text">< /form> 在被傳遞給客戶端之前將被改寫成<form name="testform" action="/xxx"& gt;<input type="hidden" name="jsessionid" value="ByOK3vjFD75aPnrF7C2HmdnV6QZcEbzWoWiBYEnLerjQ99zWpBng!-145788764"& gt;<input type="text"></form> 這種技術現在已較少應用，筆者接觸過的很古老的 iPlanet6(SunONE應用服務器的前身)就使用了這種技術。實際上這種技術可以簡單的用對action應用URL重寫來代替。 在談論session機制的時候，常常聽到這樣一種誤解“只要關閉瀏覽器，session就消失了”。其實可以想象一下會員卡的例子，除非顧客主動對店家提出銷卡，否則店家絕對不會輕易刪除顧客的資料。對session來說也是一樣的，除非程序通知服務器刪除一個session，否則服務器會一直保留，程序一般都是在用戶做log off的時候發個指令去刪除session。然而瀏覽器從來不會主動在關閉之前通知服務器它將要關閉，因此服務器根本不會有機會知道瀏覽器已經關閉，之所以會有這種錯覺，是大部分session機制都使用會話cookie來保存session id，而關閉瀏覽器後這個 session id就消失了，再次連接服務器時也就無法找到原來的session。
如果服務器設置的cookie被保存到硬盤上，或者使用某種手段改寫瀏覽器發出的HTTP請求頭，把原來的session id發送給服務器，則再次打開瀏覽器仍然能夠找到原來的 session。 恰恰是由於關閉瀏覽器不會導致session被刪除，迫使服務器爲seesion設置了一個失效時間，當距離客戶端上一次使用session的時間超過這個失效時間時，服務器就可以認爲客戶端已經停止了活動，纔會把session刪除以節省存儲空間。
在一些投票之類的場合，我們往往因爲公平的原則要求每人只能投一票，在一些WEB開發中也有類似的情況，這時候我們通常會使用COOKIE來實現，例如如下的代碼：
< % cookie[]cookies = request.getCookies();
if (cookies.lenght == 0 || cookies == null)
doStuffForNewbie();
//沒有訪問過
}
else
{
doStuffForReturnVisitor(); //已經訪問過了
}
% >
這是很淺顯易懂的道理，檢測COOKIE的存在，如果存在說明已經運行過寫入COOKIE的代碼了，然而運行以上的代碼後，無論何時結果都是執行doStuffForReturnVisitor()，通過控制面板-Internet選項-設置-察看文件卻始終看不到生成的cookie文件，奇怪，代碼明明沒有問題，不過既然有cookie，那就顯示出來看看。
cookie[]cookies = request.getCookies();
if (cookies.lenght == 0 || cookies == null)
out.println("Has not visited this website");
}
else
{
for (int i = 0; i < cookie.length; i++)
{
out.println("cookie name:" + cookies[i].getName() + "cookie value:" +
cookie[i].getValue());
}
}
運行結果:
cookie name:JSESSIONID cookie value:KWJHUG6JJM65HS2K6 爲什麼會有cookie呢,大家都知道，http是無狀態的協議，客戶每次讀取web頁面時，服務器都打開新的會話，而且服務器也不會自動維護客戶的上下文信息，那麼要怎麼才能實現網上商店中的購物車呢，session就是一種保存上下文信息的機制，它是針對每一個用戶的，變量的值保存在服務器端，通過SessionID來區分不同的客戶,session是以cookie或URL重寫爲基礎的，默認使用cookie來實現，系統會創造一個名爲JSESSIONID的輸出cookie，我們叫做session
cookie,以區別persistent cookies,也就是我們通常所說的cookie,注意session cookie是存儲於瀏覽器內存中的，並不是寫到硬盤上的，這也就是我們剛纔看到的JSESSIONID，我們通常情是看不到JSESSIONID的，但是當我們把瀏覽器的cookie禁止後，web服務器會採用URL重寫的方式傳遞Sessionid，我們就可以在地址欄看到sessionid=KWJHUG6JJM65HS2K6之類的字符串。
明白了原理，我們就可以很容易的分辨出persistent cookies和session cookie的區別了，網上那些關於兩者安全性的討論也就一目瞭然了，session cookie針對某一次會話而言，會話結束session cookie也就隨着消失了，而persistent cookie只是存在於客戶端硬盤上的一段文本（通常是加密的），而且可能會遭到cookie欺騙以及針對cookie的跨站腳本攻擊，自然不如session cookie安全了。
通常session cookie是不能跨窗口使用的，當你新開了一個瀏覽器窗口進入相同頁面時，系統會賦予你一個新的sessionid，這樣我們信息共享的目的就達不到了，此時我們可以先把sessionid保存在persistent cookie中，然後在新窗口中讀出來，就可以得到上一個窗口SessionID了，這樣通過session cookie和persistent cookie的結合我們就實現了跨窗口的session tracking（會話跟蹤）。
在一些web開發的書中，往往只是簡單的把Session和cookie作爲兩種並列的http傳送信息的方式，session cookies位於服務器端，persistent cookie位於客戶端，可是session又是以cookie爲基礎的，明白的兩者之間的聯繫和區別，我們就不難選擇合適的技術來開發web service了。
----------------------------------------------------------------------------------------------------------------------
cookie和session機制之間的區別與聯繫
具體來說cookie機制採用的是在客戶端保持狀態的方案。它是在用戶端的會話狀態的存貯機制，他需要用戶打開客戶端的cookie支持。cookie的作用就是爲了解決HTTP協議無狀態的缺陷所作的努力.
而session機制採用的是一種在客戶端與服務器之間保持狀態的解決方案。同時我們也看到，由於採用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的。而session提供了方便管理全局變量的方式
session是針對每一個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪個用戶session變量,這個值是通過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器。
就安全性來說：當你訪問一個使用session 的站點，同時在自己機子上建立一個cookie，建議在服務器端的SESSION機制更安全些.因爲它不會任意讀取客戶存儲的信息。
正統的cookie分發是通過擴展HTTP協議來實現的，服務器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie
從網絡服務器觀點看所有HTTP請求都獨立於先前請求。就是說每一個HTTP響應完全依賴於相應請求中包含的信息狀態管理機制克服了HTTP的一些限制並允許網絡客戶端及服務器端維護請求間的關係。在這種關係維持的期間叫做會話(session)。
Cookies是服務器在本地機器上存儲的小段文本並隨每一個請求發送至同一個服務器。IETF RFC 2965 HTTP State Management Mechanism 是通用cookie規範。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies
----------------------------------------------------------------------------------------------------
| cookie和session機制區別與聯繫 |
|
具體來說cookie機制採用的是在客戶端保持狀態的方案，而session機制採用的是在服務器端保持狀態的方案。同時我們也看到，由於採用服務器端保持狀態的方案在客戶端也需要保存一個標識，所以session機制可能需要藉助於cookie機制來達到保存標識的目的，但實際上它還有其他選擇。 cookie機制。正統的cookie分發是通過擴展HTTP協議來實現的，服務器通過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也可以生成cookie。而cookie的使用是由瀏覽器按照一定的原則在後臺自動發送給服務器的。瀏覽器檢查所有存儲的cookie，如果某個cookie所聲明的作用範圍大於等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。 |