但是 session存儲 請求 pri com 無法 體驗 -c data

1、為什麽有Session和Cookie

根據早期的HTTP協議，每次request-reponse時，都要重新建立TCP連接。TCP連接每次都重新建立，所以服務器無法知道上次請求和本次請求是否來自於同一個客戶端。因此，HTTP通信是無狀態的。服務器認為每次請求都是一個全新的請求，無論該請求是否來自同一地址。

但是這也帶來了問題，假如不使用Session或Cookie，那麽就意味著假如你登錄了某個購物網站，你的每次請求因為無狀態，購物網站的服務器都無法判斷你的身份和登陸與否，意味著為了保持登陸你必須瀏覽某個商品時登陸一次，瀏覽另一個商品又要登陸一次。
這種用戶體驗誰還願意上購物網站？於是出現了Cookie，它把少量的用戶信息存儲在用戶自己電腦上，因為它在同一個域名下是全局的，所以用戶訪問時，服務器就可以從該域名下任意頁面讀取Cookie中的信息，以判斷登陸狀態。
但Cookie存在用戶端，存儲尺寸也有大小限制，用戶自身還可以禁用，甚至可見並修改，安全性極差。為了安全，又能方便地讀取全局信息，於是出現了新的存儲會話機制，Session。

2、Session們誰是誰的誰（實現機制）

有了Session，就能讓用戶在一次會話中的多次HTTP請求產生關聯，讓多個頁面都能讀取到Session域裏面的值。Session信心存放在服務器端，也很好地解決了安全問題。
但是同樣有疑問，若幹客戶端和服務器連接，服務器會為每個客戶端的一次會話創建一個會話對象Session，如何區分哪個Session對應的是哪個客戶端呢？

答案是，多數容器是采用Cookie機制來實現Session機制，也就是說，利用Cookie來保存 “客戶端” 和 “服務器裏會話對象” 之間的對應關系。
使用Cookie實現會話機制的過程是：

• 當容器創建一個新的HttpSession對象後，會生成一個隨機數，稱之為會話ID，並將ID值封裝成一個名為JSESSIONID的Cookie，返回給客戶端；
• 之後的請求，在調用request.getSession方法獲得會話對象時，容器會先從request中獲取JSESSIONID的值，根據值查找到對應的會話對象，返回使用；
• 如果沒有獲得JSESSIONID值，則容器認為當前請求沒有相關聯的會話對象，會重復第一步進行生成。

實際上，整個過程很像點餐：

• 去餐館點了牛排，得到號碼牌（JSESSIONID）
• 你走開了幾步之後，服務員就忘了你是誰
• 你如果想取你的牛排，你就需要這個號碼牌去找服務員領
• 服務員能根據號碼牌確認你是顧客，你點過餐，把你對應的牛排拿給你
  
  

3、Cookie被阻止的處理

Cookie在瀏覽器設置是可以被阻止的，那麽根據其Session的實現機制，如果Cookie被禁用，那麽Session也會受到影響。
Cookie被阻止，那麽根據其實現機制，則找不到JSESSIONID的Cookie，會認為是首次登陸，所以無法利用Session保持用戶的登陸狀態。
解決辦法：強制把JSESSIONID傳遞給相關資源
Java Servlet API 中提出了跟蹤Session的另一種機制，如果客戶端瀏覽器不支持Cookie，容器可以重寫客戶請求的URL，把JSESSIONID添加到 URL信息中。HttpServletResponse接口提供了重寫 URL 的方法：public String encodeURL(String url)

• 先判斷當前的Web組件是否啟用Session，如果沒有啟用Session，直接返回參數url
  
• 如果啟用Session，再判斷客戶端瀏覽器是否支持Cookie
• 如果支持Cookie，直接返回參數url
• 如果不支持Cookie，就在參數url中加入JSESSIONID信息，然後返回修改後的url

如點擊以下鏈接：

<a href = <%=response.encodeURL("admin/doServlet")%> >URL重寫訪問</a>

4、Cookie和Session的區別

• 都是保存用戶信息，不同在於Session存儲在服務器端，Cookie是存儲在客戶端
• Session中可以保存任意對象，Cookie只能保存字符串
• Session隨會話結束而關閉，Cookie可以長期保存在客戶端硬盤上，也可以臨時保存在瀏覽器內存中
• Session用來保存重要信息，Cookie用來保存不重要的用戶信息

[06] Session實現機制以及和Cookie的區別