（1）
這是一個保險措施
因為Session默認是需要Cookie支持的
但有些客戶瀏覽器是關閉Cookie的
這個時候就需要在URL中指定服務器上的session標識,也就是5F4771183629C9834F8382E23BE13C4C
用一個方法(忘了方法的名字)處理URL串就可以得到這個東西
這個方法會判斷你的瀏覽器是否開啟了Cookie,如果他認為應該加他就會加上去
（2）
鏈接1：wapbrowse.jsp?curAlbumID=9 ；
鏈接2:wapbrowse.jsp;jsessionid=5AC6268DD8D4D5D1FDF5D41E9F2FD960?curAlbumID=9；
這兩個鏈接是從模擬器運行時生成的source中拷貝過來的，兩個鏈接都是指向wapbrowse.jsp,鏈接1由於不包含 jsessionid,所以在wapbrowse.jsp中變量為null,通過鏈接2打開wapbrowse.jsp可以正常訪問session 變量
（3）
URL重寫功能,為了防止一些用戶把Cookie禁止而無法使用session而設置的功能.jsessionid后面的一長串就是你服務器上的session的ID號,這樣無需cookie也可以使用session.
（4）
http本身是無session的，無法跟蹤客戶端的信息，換句話說：http協議不管是誰聯接自己。
為了實現session，必須有瀏覽器支持。瀏覽器可以用cookie存儲session，這是最通用的做法。
但是，如果我自己寫一個完全符合http協議的瀏覽器，但是不配合服務器的session要求，那么服務器就無法產生session。
好在現在的瀏覽器都支持session要求，即使關閉了cookie，瀏覽器也會向服務器傳遞sessionid，這個id是存儲在瀏覽器的內存空間中的，不保存在硬盤cookie中。
（5）
sessionid是作為一個臨時cookie放在瀏覽器端的。
session的具體信息放在服務器端。
每次瀏覽器發出的請求，都會在http header里 帶上 sessionid來標識自己。
既然用Struts，順便再把JSTL用上，
下面一個非常有用的標簽：
清單 12. 操作的語法
var="name" scope="scope">
...
URL 重寫是由 操作自動執行的。如果 JSP 容器檢測到一個存儲用戶當前會話標識的 cookie，那么就不必進行重寫。但是，如果不存在這樣的 cookie，那么 生成的所有 URL 都會被重寫以編碼會話標識。注：如果在隨后的請求中存在適當的 cookie，那么 將停止重寫 URL 以包含該標識。
參考：http://www-900.ibm.com/developerWorks/cn/java/j-jstl0318/index.shtml
（6）
方法一：url中緊跟servlet/jsp文件名加;jsessionid=sessionId，其中sessionId由 HttpSession.getId()得到，如http://localhost:8080/aaa /bbb.jsp;jsessionid=saldjfsdflsaeir234?para=1¶2=2
方法二：在application(ServletContext)里保存一個session管理器HashMap:sessionId--- sessionRef，這樣可以在所有的servlet/jsp里調用，這需要在url里將sessionId以參數形式傳遞，如http: //localhost:8080/aaa/bbb.jsp?sessionId=saldjfsdflsaeir234?para=1¶2=2，在服務 器端用request.getParameter("sessionId")獲取
（7）
session是在服務器端保存。服務器根據url請求中的session_id來查找對應的session。
以一個bbs為例，網站需要根據每個請求url獲取用戶的信息，如果以cookie方式，用戶信息全部是存放在cookie中的，這樣可能會不安 全；如果以session方式，用戶信息可以存放在服務器端，服務器只要從http請求中得到session_id，就可以得到存放在session中的 用戶信息了，這樣安全性比較高。session在服務器中的表現方式依服務器而定，可能是寫到臨時文件中，也可能直接放在內存中。
服務器從http請求中得到session_id的方式有兩種：cookie和url重寫。如果客戶端啟用cookie，那么 session_id可以保存在cookie中；如果禁用cookie，就用url重寫方式，在url中添加.jsessionid=xxxxx參數部 分，服務器會試圖從url中得到.jsessionid參數作為session_id.
（8）
cookie 是保存在客戶端的文本格式數據，session是客戶端登錄到應用，由服務器為該客戶端建立的唯一的標識，可以在session里面保存該客戶端的數據比如說用戶帳號。
一般cookie可以用來保存你的登錄帳號和密碼，在你登錄到應用服務上，自動添加到登錄界面或直接發送到服務器上進行登錄，這就是你經常能在論壇上看到的你的登錄信息保存一年的選項 的實現方式
（9）
在http的報文格式里面cookie和session是在同一個包文位置上的
如果ie發現包文里面包含cookie/session的信息的話，他會根據安全級別來決定是否保存相關信息，比如，如果安全機制允許使用 cookie那么ie將把cookie的信息保存到臨時文件里面，每次在請求服務器文件的時候會把收到的session的信息加入到請求的報文里面，這就 是session保存信息的原理。如果安全機制不允許使用cookie的話，雖然ie收到了cookie和session的信息，那么cookie的信息 不會被寫入臨時文件，當ie再次請求服務器文件的時候，也不會把收到的session的信息加入到請求報文里面，服務器就無法知道session的信息 了。
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的可用性。
以前很少遇到這樣的問題，今天又漲見識了...
資料來自互聯網:http://sizhefang.iteye.com/blog/25294