詳解Cookie、Session和緩存

1 Cookie和Session

      Cookie和Session都爲了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是爲了解決HTTP無狀態的問題而所作的努力。

      Session能夠用Cookie來實現，也能夠用URL回寫的機制來實現。用Cookie來實現的Session能夠認爲是對Cookie更高級的應用。

1.1二者比較

Cookie和Session有如下明顯的不一樣點：

      1）Cookie將狀態保存在客戶端，Session將狀態保存在服務器端；

      2）Cookies是服務器在本地機器上存儲的小段文本並隨每個請求發送至同一個服務器。Cookie最先在RFC2109中實現，後續RFC2965作了加強。網絡服務器用HTTP頭向客戶端發送cookies，在客戶終端，瀏覽器解析這些cookies並將它們保存爲一個本地文件，它會自動將同一服務器的任何請求縛上這些cookies。Session並無在HTTP的協議中定義；

      3）Session是針對每個用戶的，變量的值保存在服務器上，用一個sessionID來區分是哪一個用戶session變量,這個值是經過用戶的瀏覽器在訪問的時候返回給服務器，當客戶禁用cookie時，這個值也可能設置爲由get來返回給服務器；

      4）就安全性來講：當你訪問一個使用session 的站點，同時在本身機子上創建一個cookie，建議在服務器端的SESSION機制更安全些.由於它不會任意讀取客戶存儲的信息。

1.2 Session機制

      Session機制是一種服務器端的機制，服務器使用一種相似於散列表的結構（也可能就是使用散列表）來保存信息。

當程序須要爲某個客戶端的請求建立一個session的時候，服務器首先檢查這個客戶端的請求裏是否已包含了一個session標識 - 稱爲 session id，若是已包含一個session id則說明之前已經爲此客戶端建立過session，服務器就按照session id把這個 session檢索出來使用（若是檢索不到，可能會新建一個），若是客戶端請求不包含session id，則爲此客戶端建立一個session而且生成一個與此session相關聯的session id，session id的值應該是一個既不會重複，又不容易被找到規律以仿造的字符串，這個 session id將被在本次響應中返回給客戶端保存。

1.2.1 Session的實現方式

1  使用Cookie來實現

      服務器給每一個Session分配一個惟一的JSESSIONID，並經過Cookie發送給客戶端。

當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID。這樣服務器可以找到這個客戶端對應的Session。

流程以下圖所示：

2  使用URL回顯來實現

      URL回寫是指服務器在發送給瀏覽器頁面的全部連接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個連接都會把JSESSIONID帶會服務器。

      若是直接在瀏覽器輸入服務端資源的url來請求該資源，那麼Session是匹配不到的。

      Tomcat對Session的實現，是一開始同時使用Cookie和URL回寫機制，若是發現客戶端支持Cookie，就繼續使用Cookie，中止使用URL回寫。若是發現Cookie被禁用，就一直使用URL回寫。jsp開發處理到Session的時候，對頁面中的連接記得使用response.encodeURL() 。

1.2.2 與Cookie相關的HTTP擴展頭

      1）Cookie：客戶端將服務器設置的Cookie返回到服務器；

      2）Set-Cookie：服務器向客戶端設置Cookie；

      3）Cookie2 (RFC2965)）：客戶端指示服務器支持Cookie的版本；

      4）Set-Cookie2 (RFC2965)：服務器向客戶端設置Cookie。

1.2.3 Cookie的流程

      服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie頭中發送給服務器。從而實現會話的保持。

流程以下圖所示：

2 緩存的實現原理

2.1 什麼是Web緩存

WEB緩存(cache)位於Web服務器和客戶端之間。

緩存會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：若是是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。

HTTP協議定義了相關的消息頭來使WEB緩存儘量好的工做。

2.2緩存的優勢

      減小相應延遲：由於請求從緩存服務器（離客戶端更近）而不是源服務器被相應，這個過程耗時更少，讓web服務器看上去相應更快。

      減小網絡帶寬消耗：當副本被重用時會減低客戶端的帶寬消耗；客戶能夠節省帶寬費用，控制帶寬的需求的增加並更易於管理。

2.3與緩存相關的HTTP擴展消息頭

      Expires：指示響應內容過時的時間，格林威治時間GMT

      Cache-Control：更細緻的控制緩存的內容

      Last-Modified：響應中資源最後一次修改的時間

      ETag：響應中資源的校驗值，在服務器上某個時段是惟一標識的。

      Date：服務器的時間

      If-Modified-Since：客戶端存取的該資源最後一次修改的時間，同Last-Modified。

      If-None-Match：客戶端存取的該資源的檢驗值，同ETag。

2.4客戶端緩存生效的常見流程

      服務器收到請求時，會在200OK中回送該資源的Last-Modified和ETag頭，客戶端將該資源保存在cache中，並記錄這兩個屬性。當客戶端須要發送相同的請求時，會在請求中攜帶If-Modified-Since和If-None-Match兩個頭。兩個頭的值分別是響應中Last-Modified和ETag頭的值。服務器經過這兩個頭判斷本地資源未發生變化，客戶端不須要從新下載，返回304響應。常見流程以下圖所示：

2.5 Web緩存機制

      HTTP/1.1中緩存的目的是爲了在不少狀況下減小發送請求，同時在許多狀況下能夠不須要發送完整響應。前者減小了網絡迴路的數量；HTTP利用一個「過時（expiration）」機制來爲此目的。後者減小了網絡應用的帶寬；HTTP用「驗證（validation）」機制來爲此目的。

HTTP定義了3種緩存機制：

      1）Freshness：容許一個迴應消息能夠在源服務器不被從新檢查，而且能夠由服務器和客戶端來控制。例如，Expires迴應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明瞭緩存的最長時間；

      2）Validation：用來檢查以一個緩存的迴應是否仍然可用。例如，若是一個迴應有一個Last-Modified迴應頭，緩存可以使用If-Modified-Since來判斷是否已改變，以便判斷根據狀況發送請求；

      3）Invalidation： 在另外一個請求經過緩存的時候，經常有一個反作用。例如，若是一個URL關聯到一個緩存迴應，可是其後跟着POST、PUT和DELETE的請求的話，緩存就會過時。