http快取主要分為了兩類 強快取(本地快取)和協商快取
瀏覽器在請求某一資源時，會先獲取改資源快取的header資訊，判斷是否命中強快取（expires的資訊和cache-control）若命中直接從快取中獲取該資源資訊，包括快取header資訊，本次請求根本就不會與伺服器進行通訊。此為強快取（本地快取）
如果沒有命中強快取，瀏覽器會傳送請求到伺服器，請求會攜帶第一次請求返回的的有關快取的header欄位資訊（last-modified/if-modified-since 和 etag/if-none-match）,由伺服器根據請求中相關header資訊來比對結果是否協商快取命中，若命中，則伺服器返回新的響應header資訊更新快取中的對應header資訊，但是並不返回資源內容，它會告知瀏覽器可以直接從快取獲取，否則返回最新的資源內容。
獲取資源形式 狀態碼 傳送請求到伺服器協商快取 從快取取 304（not modified） 是，正如其名，通過伺服器來告知快取是否可用
1 expires,這是http1.0的規範，它的值為乙個絕對時間的gmt格式的時間字串，如mon, 10 jun 2015 21:31:12 gmt。如果傳送請求的時間在expires之前，那麼本地快取始終有效，否則就會傳送請求到伺服器來獲取資源。
注意：如果cache-control與expires同時存在的話，cache-control的優先順序高於expires。
協商快取都是由伺服器來確定快取資源是否可用的，所以客戶端與伺服器端通過某種標識進行通訊，從而讓伺服器判斷請求資源是否可以快取訪問，
這裡涉及到下面兩組header欄位。這兩組搭檔都是成對出現的，即第一次請求的響應頭帶上某個字段（last-modified或者etag),則後續請求則會帶上對應的請求字段(if-modified-since或者if-none-match)，若響應頭沒有last-modified或者etag欄位，則請求頭也不會有對應的字段。
1,第一次和伺服器互動，伺服器返回資源 在response的header加上last-modified的header.這個header表示這個資源在伺服器上的最後修改時間
2,第二次請求這個資源，瀏覽器會在request header加上if-modified-since的header.這個header的值就是上一次請求時返回的last-modified的值。伺服器再次收到資源請求。根據瀏覽器傳過來的if-modified-since和資源在伺服器上的最後修改時間判斷資源是否有變化，如果沒有發生變化則返回
304 not modified .但是不會返回資源內容。如果有變化，就正常返回資源內容和更新last-modified欄位。當伺服器返回304 not modified的響應時，response header中不會再新增last-modified的字段。因為既然資源沒有變化，那麼last-modified也就不會改變.
etag/if-none-match
這兩個值是由伺服器生產的每乙個資源的唯一標識字串，只要資源有變化就這個值就會改變，其判斷過程和last-modified/if-modified-since類似，與last-modified不一樣的是。當伺服器返回304 not
modified的響應 response header中還會把這個etag返回，即使這個etag跟之前沒有變化。
**etag比較的是檔案資源的特徵值，而last-modifield則比較的是檔案資源的最後的修改時間。這兩個其實是相輔相成的，不是有了etag就不該有last-modifield，有了last-modifield就不該有etag，同時傳入伺服器時，伺服器會根據自己的快取機制進行選擇要使用哪個，甚至可以兩個都進行參考
比如img肯定判斷last-modified更方便。其他檔案可能比較etag更方便
**你可能會覺得使用last-modified已經足以讓瀏覽器知道本地的快取副本是否足夠新，為什麼還要etag呢。http1.1 etag的出現主要是為了解決幾個last-modifed比較難解決的問題：
1 一些檔案也行會週期性的更改，但是他的內容並不改變（僅僅改變的修改時間），這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get;
2 某些檔案修改非常頻繁，比如在秒以下的時間內進行修改（比方說1s內修改n次）if-modified-since能檢查到的粒度是s級的，這種修改無法判斷（unix記錄mtime只能精確到秒）
3 某些伺服器不能精確得到檔案的最後修改時間。
http快取詳細分析
http快取主要分為了兩類 強快取 本地快取 和協商快取 瀏覽器在請求某一資源時，會先獲取改資源快取的header資訊，判斷是否命中強快取 expires的資訊和cache control 若命中直接從快取中獲取該資源資訊，包括快取header資訊，本次請求根本就不會與伺服器進行通訊。此為強快取 本...
快取擊穿問題分析
快取一般作為rds的前置元件，將常用的資源快取，用來減少rds的讀取壓力，也是諸多系統常用的一種方案，如果允許訪問快取失敗直接訪問資料庫，然後再將資料回寫到快取中，那麼就會存在快取擊穿的問題，快取擊穿 快取中的資料未被命中，進而請求直接對資料庫進行查詢，當大量的類似查詢瞬間出現，就會出現資料庫的壓力...
瀏覽器 HTTP 快取原理分析
以前專案中遇到了很多瀏覽器快取相關的問題，也在網上查過資料，搞過伺服器的配置，來確保客戶端載入伺服器資源的速度和資源有效性。最近仔細看了下http協議中和快取相關的一些屬性，總結一下。瀏覽器第一次訪問伺服器資源 index.html 在瀏覽器中沒有快取檔案，直接向伺服器傳送請求。伺服器返回 200 ...