HTTP session, cookie機制詳解

1、什麼是http session,有什麼用

HTTP協議自己是無狀態的,自己並不能支持服務端保存客戶端的狀態信息，因而，Web Server中引入了session的概念，用來保存客戶端的狀態信息。

這 裏用一個形象的比喻來解釋session的工做方式。假設Web Server是一個商場的存包處，HTTP Request是一個顧客，第一次來到存包處，管理員把顧客的物品存放在某一個櫃子裏面（這個櫃子就至關於Session），而後把一個號碼牌交給這個顧 客，做爲取包憑證（這個號碼牌就是Session ID）。顧客（HTTP Request）下一次來的時候，就要把號碼牌（Session ID）交給存包處（Web Server）的管理員。管理員根據號碼牌（Session ID）找到相應的櫃子（Session），根據顧客（HTTP Request）的請求，Web Server能夠取出、更換、添加櫃子（Session）中的物品，Web Server也可讓顧客（HTTP Request）的號碼牌和號碼牌對應的櫃子（Session）失效。顧客（HTTP Request）的忘性很大，管理員在顧客回去的時候（HTTP Response）都要從新提醒顧客記住本身的號碼牌（Session ID）。這樣，顧客（HTTP Request）下次來的時候，就又帶着號碼牌回來了。 咱們能夠看到，Session ID其實是在客戶端和服務端之間經過HTTP Request和HTTP Response傳來傳去的。

2、通常用來實現Session的方法有兩種·

1）URL重寫。 Web Server在返回Response的時候，檢查頁面中全部的URL，包括全部的鏈接，和HTML Form的Action屬性，在這些URL後面加上「;jsessionid=XXX」。 下一次，用戶訪問這個頁面中的URL。jsessionid就會傳回到Web Server。

2）Cookie。

若是客戶端支持Cookie，Web Server在返回Response的時候，在Response的Header部分，加入一個「set-cookie: jsessionid=XXXX」header屬性，把jsessionid放在Cookie裏傳到客戶端。

客戶端會把Cookie存放在本地文件裏，下一次訪問Web Server的時候，再把Cookie的信息放到HTTP Request的「Cookie」header屬性裏面，這樣jsessionid就隨着HTTP Request返回給Web Server。

3、session的工做原理

1）當一個用戶向服務器發送第一個請求時，服務器爲其創建一個session，併爲此session建立一個標識號； 2 ) 這個用戶隨後的全部請求都應包括這個標識號。服務器會校對這個標識號以判斷請求屬於哪一個session。

這種機制不使用IP做爲標識，是由於不少機器是經過代理服務器方式上網，無法區分每一臺機器。

對於session標識號（sessionID），有兩種方式實現：cookies和URL重寫。

4、HttpSession總結

一、HTTP協議自己是「鏈接-請求-應答-關閉鏈接」模式的，是一種無狀態協議（HTTP只是一個傳輸協議）； 二、Cookie規範是爲了給HTTP增長狀態跟蹤用的（若是要精確把握，建議仔細閱讀一下相關的RFC），但不是惟一的手段； 三、所謂Session，指的是客戶端和服務端之間的一段交互過程的狀態信息（數據）；這個狀態如何界定，生命期有多長，這是應用自己的事情； 四、 因爲B/S計算模型中計算是在服務器端完成的，客戶端只有簡單的顯示邏輯，因此，Session數據對客戶端應該是透明的不可理解的而且應該受控於服 務端；Session數據要麼保存到服務端（HttpSession），要麼在客戶端和服務端之間傳遞（Cookie或url rewritting或Hidden input）； 五、因爲HTTP自己的無狀態性，服務端沒法知道客戶端相繼發來的請求是來自一個客戶的，因此，當使用服務端HttpSession存儲會話數據的時候客戶端的每一個請求都應該包含一個session的標識(sid, jsessionid 等等)來告訴服務端； 六、會話數據保存在服務端（如HttpSession）的好處是減小了HTTP請求的長度，提升了網絡傳輸效率；客戶端session信息存儲則相反； 七、 客戶端Session存儲只有一個辦法：cookie(url rewritting和hidden input由於沒法作到持久化，不算，只能做爲交換session id的方式，即a method of session tracking)，而服務端作法大體也是一個道理：容器有個session管理器（如tomcat的 org.apache.catalina.session包裏面的類），提供session的生命週期和持久化管理並提供訪問session數據的 api； 八、使用服務端仍是客戶端session存儲要看應用的實際狀況的。通常來講不要求用戶註冊登陸的公共服務系統（如google）採用 cookie作客戶 端session存儲（如google的用戶偏好設置），而有用戶管理的系統則使用服務端存儲。緣由很顯然：無需用戶登陸的系統惟一可以標識用戶的就是用 戶的電腦，換一臺機器就不知道誰是誰了，服務端session存儲根本無論用；而有用戶管理的系統則能夠經過用戶id來管理用戶我的數據，從而提供任意復 雜的個性化服務； 九、客戶端和服務端的session存儲在性能、安全性、跨站能力、編程方便性等方面都有必定的區別，並且優劣並不是絕對（譬如 TheServerSide 號稱不使用HttpSession，因此性能好，這很顯然：一個具備上億的訪問用戶的系統，要在服務端數據庫中檢索出用戶的偏好信息顯然是低效 的，Session管理器無論用什麼數據結構和算法都要耗費大量內存和CPU時間；而用cookie，則根本不用檢索和維護session數據，服務器可 以作成無狀態的，固然高效）； 十、 所謂的「會話cookie」簡單的說就是沒有明確指明有效期的cookie，僅在瀏覽器當前進程生命期內有效，能夠被後繼的Set-Cookie操做清除掉。 當 程序須要爲某個客戶端的請求建立一個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.

5、Session什麼時候被建立、什麼時候被刪除

什麼時候建立：一 個常見的誤解是覺得session在有客戶端訪問時就被建立，然而事實是直到某server端程序調用 HttpServletRequest.getSession(true)這樣的語句時才被建立，注意若是JSP沒有顯示的使用 <% @page session="false"%> 關閉session，則JSP文件在編譯成Servlet時將會自動加上這樣一條語句 HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的 session對象的來歷。因爲session會消耗內存資源，所以，若是不打算使用session，應該在全部的JSP中關閉它。 什麼時候刪除： a.程序調用HttpSession.invalidate(); b.距離上一次收到客戶端發送的session id時間間隔超過了session的超時設置; c.服務器進程被中止（非持久session） 如何作到在瀏覽器關閉的時候刪除cookie？ 嚴格的講，作不到這一點。能夠作一點努力的辦法是在全部的客戶端頁面裏使用javascript代碼window.oncolose來監視瀏覽器的關閉動做，而後向服務器發送一個請求來刪除session。可是對於瀏覽器崩潰或者強行殺死進程這些很是規手段仍然無能爲力。

6、Session的其餘問題

一、存放在session中的對象必須是可序列化的嗎？ 不是必需的。要求對象可序列化只是爲了session可以在集羣中被複制或者可以持久保存或者在必要時server可以暫時把session交換出內存。 二、如何才能正確的應付客戶端禁止cookie的可能性 對全部的URL使用URL重寫，包括超連接，form的action，和重定向的URL 三、開兩個瀏覽器窗口訪問應用程序會使用同一個session仍是不一樣的session

7、理解Cookie機制

1）cookie機制的基本原理就如上面的例子同樣簡單，可是還有幾個問題須要解決：「會員卡」如何分發；「會員卡」的內容；以及客戶如何使用「會員卡」。 2）正統的cookie分發是經過擴展HTTP協議來實現的，服務器經過在HTTP的響應頭中加上一行特殊的指示以提示瀏覽器按照指示生成相應的cookie。然而純粹的客戶端腳本如JavaScript或者VBScript也能夠生成cookie。 3） 而cookie的使用是由瀏覽器按照必定的原則在後臺自動發送給服務器的。瀏覽器檢查全部存儲的cookie，若是某個cookie所聲明的做用範圍大於 等於將要請求的資源所在的位置，則把該cookie附在請求資源的HTTP請求頭上發送給服務器。意思是麥當勞的會員卡只能在麥當勞的店裏出示，若是某家 分店還發行了本身的會員卡，那麼進這家店的時候除了要出示麥當勞的會員卡，還要出示這家店的會員卡。

8、cookie的內容

主要包括：名字，值，過時時間，路徑和域。 路徑、域和做用範圍：其中域能夠指定某一個域好比.google.com，至關於總店招牌，好比寶潔公司，也能夠指定一個域下的具體某臺機器好比www.google.com或者froogle.google.com，能夠用飄柔來作比。 路徑就是跟在域名後面的URL路徑，好比/或者/foo等等，能夠用某飄柔專櫃作比。 路徑與域合在一塊兒就構成了cookie的做用範圍。 過時時間：如 果不設置過時時間，則表示這個cookie的生命期爲瀏覽器會話期間，只要關閉瀏覽器窗口，cookie就消失了。這種生命期爲瀏覽器會話期的 cookie被稱爲會話cookie。會話cookie通常不存儲在硬盤上而是保存在內存裏，固然這種行爲並非規範規定的。若是設置了過時時間，瀏覽器 就會把cookie保存到硬盤上，關閉後再次打開瀏覽器，這些cookie仍然有效直到超過設定的過時時間。 瀏覽器差別：存 儲在硬盤上的cookie能夠在不一樣的瀏覽器進程間共享，好比兩個IE窗口。而對於保存在內存裏的cookie，不一樣的瀏覽器有不一樣的處理方式。對於 IE，在一個打開的窗口上按Ctrl-N（或者從文件菜單）打開的窗口能夠與原窗口共享，而使用其餘方式新開的IE進程則不能共享已經打開的窗口的內存 cookie；對於Mozilla Firefox0.8，全部的進程和標籤頁均可以共享一樣的cookie。通常來講是用javascript的window.open打開的窗口會與原窗 口共享內存cookie。瀏覽器對於會話cookie的這種只認cookie不認人的處理方式常常給採用session機制的web應用程序開發者形成很大的困擾。 轉自這裏。