java網路通訊：HTTP協議 之 Sessions與Cookies

標籤：一段   自己   get   儲存   通訊   資料庫   是什麼   最大   取消   

　　通過前一篇部落格的講解，我們大體知道了HTTP協議是什麼，它有什麼組成，以及它的工作原理，那麼在HTTP的很多特點中，有一點叫做，無狀態，就HTTP是一個無狀態的協議，如果需要前面的資訊用於處理後邊的請求，那麼在HTTP當中，就需要對前邊的資訊進行重發，這一點是很不方便的，那麼為瞭解決HTTP在用於需要記錄前邊資訊的情境的問題，提出了這麼兩個概念，Session和Cookie。那麼我們先來瞭解一下Session是什麼呢？

　　Session，顧名思義，中文含義是會話，如同前文所述，它是用於解決一類用來在用戶端與伺服器之間保持狀態的解決方案，在java當中討論的Session，通常指的是javax.servlet.http.HttpSession，可以看出Session它本身是一個對象，那麼在這個對象當中主要包含了以下幾個要素：1.屬性，用於儲存Request當中的各類資訊。2.SessionID，用於映射相應Request的標識。也許這麼說，可能有一些不大清晰，那麼我們還是老規矩，舉一個栗子來說：

　　假設我們的WebServer是一個商場的儲物處，而每一個HTTP Request是一個來商場購物的顧客，那麼顧客需要在商場當中存包，管理員會將顧客的包放到相應的儲物櫃，當中而這個儲物櫃就相當於Session，並且交給顧客相應的號碼牌作為顧客離開的時候要取包的憑證，並且之後一段時間這個儲物櫃就只交給這個顧客使用了，這個號碼牌就是SessionID。那麼等這個顧客（HTTP Request）下次來的時候，只需要初始相應的號碼牌（SessionID），儲物處（WEB Server）就會將客戶需要用的儲物櫃（Session）交個顧客使用，顧客可以在儲物櫃裡頭放東西（存入相應的屬性，setAttribute）以及取東西（getAttribute）等，當然，商場的儲物處也可以將顧客的儲物櫃給取消，然後給其他客戶使用。當顧客離開商場的時候（這時候顧客變成了HTTP Response），商場的儲物間還會友情的提示儲物櫃的編號告訴顧客（將SessionID放入Response當中），以防顧客下次忘記帶來號碼牌。這樣顧客下次過來的時候，又會帶著相同的號碼牌。

　　通過這個栗子，我們可以很好的理解了Session與HTTP Request和WEB Server之間的關係咯吧？Request和WEB Server就是依靠Session對該次狀態進行記錄，並且下次訪問的時候，就會通過相同的SessionID擷取到上一次的狀態，解決了HTTP的無狀態的問題，那麼我們在標題當中提到的Cookie又是什麼東西呢？其實，Cookie就是我們在例子當中提到的 “號碼牌”，這個號碼牌就放在用戶端的（儲存與瀏覽器的）一位顧客不可能一輩子只去一個商場，那麼這個顧客手上就會有很多 “號碼牌”，當顧客想去其中的某一個商場的時候，就會在自己手裡找一找有沒有那個商場的號碼牌（尋找符合範圍的Cookie）然後帶著這個號碼牌去相應的商場進行存包取包等操作。

　　這個例子呢，只是讓我們對HTTP Request、WEB Server、Cookie、Session、HTTP Response之間的關係做一個大體的瞭解，那麼接下來，我們開始正經的介紹在HTTP當中的Cookie和Session，以及在面試當中常常遇到過的相關問題。

 

Cookie 機制

　　Cookie在瀏覽器的產生，主要是通過拓展HTTP協議來實現的，在第一次訪問WEB Server的時候，WEB Server會在響應的HTTP Response當中的響應前序添加一行特殊的指示，提示瀏覽器在本地儲存相應的cookie（相當於顧客第一次來商場的儲物處存東西，管理員為顧客分配一個儲物櫃，然後給顧客一個號碼牌，要求顧客要拿著）。而這個Cookie的主要內容主要包括以下幾點：

1.名字：即cookie的名字。

2.值：在Cookie中存入的值。

3.到期時間：如果不設定到期時間，則表示這個cookie的生命期為瀏覽器會話期間，只要關閉瀏覽器視窗，cookie就消失了。這種生命期為瀏覽器會話期的cookie被稱為會話cookie。會話cookie一般不儲存在硬碟上而是儲存在記憶體裡，當然這種行為並不是規範規定的。如果設定了到期時間，瀏覽器就會把cookie儲存到硬碟上，關閉後再次開啟瀏覽器，這些cookie仍然有效直到超過設定的到期時間。

4.路徑和域：指定某一個域比如.google.com，也可以指定一個域下的具體某台機器比如www.google.com，路徑就是跟在網域名稱後面的URL路徑，比如/或者/foo，路徑與域合在一起就構成了cookie的作用範圍。

這裡提到一點，當設定了到期時間的cookie被存在硬碟之後，可以在不同的瀏覽器進程間共用。對於Mozilla Firefox0.8，所有的進程和標籤頁都可以共用同樣的cookie。

 

Seesion 機制

　　session機制是一種伺服器端的機制，伺服器使用一種類似於散列表的結構（也可能就是使用散列表）來儲存資訊。當某個用戶端發起HTTP Request，並需要使用一個Session的時候，WEB Server首先會檢查在這個Http Request裡頭有沒有相應的SessionID，如果已包含一個SessionID則說明以前已經為此用戶端建立過session，伺服器就按照session id把這個session檢索出來使用（如果檢索不到，可能會建立一個），如果用戶端的Http Request中不包含session id，則為此用戶端建立一個session並且產生一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字串，這個session id將被在本次響應Http response中返回給用戶端儲存。

　　這裡要格外的提一點，之前的例子當中，一直說SessionID，是用Cookie來進行儲存的，這是當然可以的，cookie的名字都是類似於SEEESIONID，但是當用戶端（瀏覽器）禁用Cookie的話，是不是就意味著這個SessionID沒法儲存了呢？當然是不可能的啊。

　　由於cookie可以被人為的禁止，必須有其他機制以便在cookie被禁止時仍然能夠把session id傳遞迴伺服器。經常被使用的一種技術叫做URL重寫，就是把session id直接附加在URL路徑的後面，附加方式也有兩種，一種是作為URL路徑的附加資訊，表現形式為http://...../xxx;jsessionid=ByOK ... 99zWpBng!-145788764，另一種是作為查詢字串附加在URL後面，表現形式為http://...../xxx?jsessionid=ByOK ... 99zWpBng!-145788764（這個jsessionid就是用來儲存SessionID的），這兩種方式對於使用者來說是沒有區別的，只是伺服器在解析的時候處理的方式不同，採用第一種方式也有利於把session id的資訊和正常程式參數區分開來。為了在整個互動過程中始終保持狀態，就必須在每個用戶端可能請求的路徑後面都包含這個session id。

 

瞭解完Session和Cookie機制之後，我們來看看一些面試當中的乾貨。

 

Session常見問題

 

1.Session建立的時間：人們常有一個誤解就是以為Session是在有用戶端訪問的時候就一定會被建立，然而事實是到某個Server端程式調用了HttpServletRequest.getSession(true)這樣的語句時才被建立，即在開啟瀏覽器第一次請求該jsp的時候，伺服器會自動為其建立一個session（JSP沒有顯示關閉Session的時候），在JSP的預設編譯成Servlet時將會自動加上這樣一條語句 HttpSession session = HttpServletRequest.getSession(true);這也是JSP中隱含的 session對象的來曆。如果不需要在JSP當中使用Session的話，需要顯示的聲明關閉Session，<% @page session="false"%>。

注意：訪問*.html的靜態資源因為不會被編譯為Servlet，也就不涉及session的問題、

 

2.Session刪除的時間：滿足以下三種情況，則會刪除Session。

1）Session逾時：逾時指的是連續一定時間伺服器沒有收到該Session所對應用戶端的請求，並且這個時間超過了伺服器設定的Session逾時的最大時間。

2）程式調用HttpSession.invalidate()

3）伺服器關閉或服務停止（一般情況下，session是不做持久化的。）

除了以上情況，均不會刪除Session，比如關閉瀏覽器，是不會刪除Session的，只會刪除會話Cookie（沒有被存入硬碟的Cookie）

 

3.session存放在哪裡：存放於伺服器的記憶體當中，也可以做特殊處理進行持久化，存入資料庫或者硬碟。

 

4.SessionID的產生和使用：當用戶端第一次請求伺服器。且需要應用到Session的時候，伺服器會為用戶端建立一個Session，並且相應的產生一個SessionID用來表示該Session，當瀏覽器下次（session繼續有效時）請求別的資源的時候，瀏覽器會自動地將SessionID放置到要求標頭中，伺服器接收到請求後就得到該請求的SessionID，伺服器找到該id的Session 返還給要求者（Servlet）使用。一個會話只能有一個Session對象，對Session來說是只認id不認人。

 

5.同一用戶端機器多次請求同一個資源，session是否一樣：對於多標籤的瀏覽器（比如360瀏覽器）來說，在一個瀏覽器視窗中，多個標籤同時訪問一個頁面，session 是一個。對於多個瀏覽器視窗之間，同時或者相隔很短時間訪問一個頁面，session是多個的，和瀏覽器的進程有關。

 

總結一下：Session是一個容器，可以存放會話過程中的任何對象，Session因為請求（request對象）而產生，同一個會話中多個request共用了一Session對象，可以直接從請求中擷取到Session對象，並且其實，session的建立和使用總在服務端，而瀏覽器從來都沒得到過session對象。但瀏覽器可以請求Servlet（jsp也是 Servlet）來擷取session的資訊。用戶端瀏覽器真正緊緊拿到的是session ID，而這個對於瀏覽器操作的人來說，是不可見的，並且使用者也無需關心自己處於哪個會話過程中。

 

6.Session共用的方法

1）用戶端Cookie儲存：用戶端Cookie儲存以cookie加密的方式儲存在用戶端.

優點是減輕伺服器端的壓力，每次session資訊被寫在客服端。然後經瀏覽器再次提交到伺服器。即使兩次請求在叢集中的兩台伺服器上完成，也可以到達session共用。

2）伺服器間Session同步：使用伺服器間session同步使用主-從伺服器的架構，當使用者在主伺服器上登入後，通過指令碼或者守護進程的方式，將session資訊傳遞到各個從伺服器中，這樣使用者訪問其它的從伺服器時，就可以讀到session資訊。 缺點：比如速度慢、不穩定等，另外，如果 session 資訊傳遞是主->從單向的，會有一些風險，比如主伺服器down了，其它伺服器無法獲得 session 資訊

3）使用叢集管理Session（如MSM） ：使用叢集統一管理Session提供一個叢集儲存session共用資訊.其他應用統統把自己的session資訊存放到session叢集伺服器組。當應用系統需要session資訊的時候直接到 session 叢集伺服器上讀取。目前大多都是使用 Memcache 來對 Session 進行儲存。目前比較流行的兩種方案：

a） 使用Filter方式：此方式使用過濾器的方式重新對httpRequest 對象進行了封裝，並加入memcached用戶端,此方式的優點是：使用簡單，把過濾器配置進去即可，另外比較靈活，因為它是在用戶端實現的，配置比較靈活,而且伺服器無關，你可以在任何支援servlet的容器上部署。
b）使用Memcached-Session-Manager，俗稱MSM，是一個用於解決分布式 tomcat 環境下 session 共用的問題的開源解決方案。它的實現原理為以tomcat外掛程式的方式部署在伺服器，修改了 servlet 容器代碼中的 session 相關代碼，使其串連 memcached ，在 memcached 中建立和更新session。

4）把Session持久化到資料庫：將session持久化到資料中這種共用session的方式即將session資訊存入資料庫中，其它應用可以從資料庫中查出session資訊。目前採用這種方案時所使用的資料庫一般為mysql。 利用資料庫共用 session 的方案有一定的實用性，但也有如下缺點：首先 session 的並發讀寫在資料庫中完成，對 mysql 的效能要求比較高；其次，我們需要額外地實現 session 淘汰(逾時)邏輯代碼，即定時從資料庫表中更新和刪除 session 資訊，增加了工作量。

java網路通訊：HTTP協議 之 Sessions與Cookies