1 Cookie和Session
Cookie和Session都爲了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是爲了解決HTTP無狀態的問題而所做的努力。
Session可以用Cookie來實現，也可以用URL回寫的機制來實現。用Cookie來實現的Session可以認爲是對Cookie更高級的應用。
1.1兩者比較
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 使用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返回到服務器；
3）Cookie2 (RFC2965)）：客戶端指示服務器支持Cookie的版本；
4）Set-Cookie2 (RFC2965)：服務器向客戶端設置Cookie。
1.2.3 Cookie的流程
服務器在響應消息中用Set-Cookie頭將Cookie的內容回送給客戶端，客戶端在新的請求中將相同的內容攜帶在Cookie頭中發送給服務器。從而實現會話的保持。
2 緩存的實現原理
2.1 什麼是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）”機制來爲此目的。
1）Freshness：允許一個迴應消息可以在源服務器不被重新檢查，並且可以由服務器和客戶端來控制。例如，Expires迴應頭給了一個文檔不可用的時間。Cache-Control中的max-age標識指明瞭緩存的最長時間；
2）Validation：用來檢查以一個緩存的迴應是否仍然可用。例如，如果一個迴應有一個Last-Modified迴應頭，緩存能夠使用If-Modified-Since來判斷是否已改變，以便判斷根據情況發送請求；
3）Invalidation： 在另一個請求通過緩存的時候，常常有一個副作用。例如，如果一個URL關聯到一個緩存迴應，但是其後跟着POST、PUT和DELETE的請求的話，緩存就會過期。