Cookie 和 Session 都為了用來保存狀態信息，都是保存客戶端狀態的機制，它們都是為了解決HTTP無狀態的問題而所做的努力。 * Cookie機制 簡單地說，Cookie 就是瀏覽器儲存在用戶電腦上的一小段文本文件。Cookie 是純文本格式，不包含任何可執行的代碼。 一個 Web 頁面或服務器告知瀏覽器按照一定規范來儲存這些信息，并在隨后的請求中將這些信息發送至服務器，Web 服務器就可以使用這些信息來識別不同的用戶。 大多數需要登錄的網站在用戶驗證成功之后都會設置一個 Cookie，只要這個 Cookie 存在并可以，用戶就可以自由瀏覽這個網站的任意頁面。 Cookie 會被瀏覽器自動刪除，通常存在以下幾種原因： 1. 會話 Cooke (Session Cookie) 在會話結束時（瀏覽器關閉）會被刪除 2. 持久化 Cookie（Persistent Cookie）在到達失效日期時會被刪除 3. 如果瀏覽器中的 Cookie 數量達到限制，那么 Cookie 會被刪除以為新建的 Cookie 創建空間。 大多數瀏覽器支持最大為 4096 字節的 Cookie。由于這限制了 Cookie 的大小，最好用 Cookie 來存儲少量數據，或者存儲用戶 ID 之類的標識符。 用戶 ID 隨后便可用于標識用戶，以及從數據庫或其他數據源中讀取用戶信息。 瀏覽器還限制站點可以在用戶計算機上存儲的 Cookie 的數量。 大多數瀏覽器只允許每個站點存儲 20 個 Cookie；如果試圖存儲更多 Cookie，則最舊的 Cookie 便會被丟棄。 有些瀏覽器還會對它們將接受的來自所有站點的 Cookie 總數作出絕對限制，通常為 300 個。 使用 Cookie 的缺點： 1. 不良站點用 Cookie 收集用戶隱私信息； 2. Cookie竊取：黑客以可以通過竊取用戶的cookie來模擬用戶的請求行為。（跨站腳本攻擊XSS） 3. Session 機制 Session機制是一種服務器端的機制，服務器使用一種類似于散列表的結構（也可能就是使用散列表）來保存信息。當程序需要為某個客戶端的請求創建一個session的時候，服務器首先檢查這個客戶端的請求里是否已包含了一個Session標識（Session id）. 如果已包含一個SessionID 則說明以前已經為此客戶端創建過Session，服務器就按照SessionID把這個 Session檢索出來使用（如果檢索不到，可能會新建一個）。 如果客戶端請求不包含SessionID，則為此客戶端創建一個Session并且生成一個與此Session相關聯的SessionID，SessionID的值應該是一個既不會重復，又不容易被找到規律以仿造的字符串，這個SessionID將被在本次響應中返回給客戶端保存。 具體實現方式： * Cookie方式 服務器給每個Session分配一個唯一的JSESSIONID，并通過Cookie發送給客戶端。 當客戶端發起新的請求的時候，將在Cookie頭中攜帶這個JSESSIONID，這樣服務器能夠找到這個客戶端對應的Session。 * URL回寫 服務器在發送給瀏覽器頁面的所有鏈接中都攜帶JSESSIONID的參數，這樣客戶端點擊任何一個鏈接都會把JSESSIONID帶回服務器。如果直接在瀏覽器輸入服務端資源的url來請求該資源，那么Session是匹配不到的。 Web 緩存: WEB緩存(cache)位于Web服務器和客戶端之間，緩存機制會根據請求保存輸出內容的副本，例如html頁面，圖片，文件，當下一個請求來到的時候：如果是相同的URL，緩存直接使用副本響應訪問請求，而不是向源服務器再次發送請求。 主要分三種情況: 1. 未找到緩存(黑色線)：當沒有找到緩存時，說明本地并沒有這些數據，這種情況一般發生在我們首次訪問網站，或者以前訪問過，但是清除過緩存后。 瀏覽器就會先訪問服務器，然后把服務器上的內容取回來，內容取回來以后，就要根據情況來決定是否要保留到緩存中了。 2. 緩存未過期(藍色線)：緩存未過期，指的是本地緩存沒有過期，不需要訪問服務器了，直接就可以拿本地的緩存作為響應在本地使用了。這樣節省了不少網絡成本，提高了用戶體驗過。 3. 緩存已過期(紅色線)：當滿足過期的條件時，會向服務器發送請求，發送的請求一般都會進行一個驗證，目的是雖然緩存文檔過期了，但是文檔內容不一定會有什么改變，所以服務器返回的也許是一個新的文檔，這時候的HTTP狀態碼是200，或者返回的只是一個最新的時間戳和304狀態碼。 緩存過期后，有兩種方法來判定服務端的文件有沒有更新。 第一種在上一次服務端告訴客戶端約定的有效期的同時，告訴客戶端該文件最后修改的時間，當再次試圖從服務端下載該文件的時候，check下該文件有沒有更新（對比最后修改時間），如果沒有，則讀取緩存. 第二種方式是在上一次服務端告訴客戶端約定有效期的同時，同時告訴客戶端該文件的版本號，當服務端文件更新的時候，改變版本號，再次發送請求的時候check一下版本號是否一致就行了，如一致，則可直接讀取緩存。 瀏覽器是依靠請求和響應中的的頭信息來控制緩存的，如下： * Expires與Cache-Control：服務端用來約定和客戶端的有效時間的。 Expires規定了緩存失效時間（Date為當前時間），而`Cache-Control`的max-age規定了緩存有效時間（2552s）。 Expires是HTTP1.0的東西，而`Cache-Control`是HTTP1.1的，規定如果`max-age`和Expires同時存在，前者優先級高于后者。 * Last-Modified/If-Modified-Since緩存過期后，check服務端文件是否更新的第一種方式。 * ETag/If-None-Match：緩存過期時check服務端文件是否更新的第二種方式。 實際上ETag并不是文件的版本號，而是一串可以代表該文件唯一的字符串，當客戶端發現和服務器約定的直接讀取緩存的時間過了，就在請求中發送If-None-Match選項，值即為上次請求后響應頭的ETag值. 該值在服務端和服務端代表該文件唯一的字符串對比（如果服務端該文件改變了，該值就會變），如果相同，則相應HTTP304，客戶端直接讀取緩存，如果不相同，HTTP200，下載正確的數據，更新ETag值。 當然并不是所有請求都能被緩存。無法被瀏覽器緩存的請求： 1. HTTP信息頭中包含`Cache-Control:no-cache，pragma:no-cache（HTTP1.0）`，或`Cache-Control:max-age=0`等告訴瀏覽器不用緩存的請求 2. 需要根據Cookie，認證信息等決定輸入內容的動態請求是不能被緩存的 3. POST請求無法被緩存 瀏覽器緩存過程還和用戶行為有關。譬如先打開一個主頁有個jquery的請求（假設訪問后會緩存下來）。 接著如果直接在地址欄輸入 jquery 地址，然后回車，響應HTTP200（from cache），因為有效期還沒過直接讀取的緩存；如果`ctrl+r`進行刷新，則會相應HTTP304（Not Modified），雖然還是讀取的本地緩存，但是多了一次服務端的請求；而如果是ctrl+shift+r強刷，則會直接從服務器下載新的文件，響應HTTP200。