之前一直對瀏覽器快取只能描述乙個大概，深層次的原理不能描述上來；終於在前端的兩次面試過程中被問倒下，為了洩恨，查閱一些資料最終對其有了乙個更深入的理解，廢話不多說，趕緊來看看瀏覽器快取的那些事吧，有不對的地方，請各位不吝賜教啊。
本文主要講解瀏覽器端的快取，快取的作用是不言而喻的，能夠極大的改善網頁效能，提高使用者體驗。
1、瀏覽器快取
快取這東西，第一次必須獲取到資源後，然後根據返回的資訊來告訴如何快取資源，可能採用的是強快取，也可能告訴客戶端瀏覽器是協商快取，這都需要根據響應的header內容來決定的。下面用兩幅圖來描述瀏覽器的快取是怎麼玩的，讓大家有個大概的認知。
瀏覽器第一次請求時：
瀏覽器後續在進行請求時：
從上圖可以知道，瀏覽器快取包含兩種型別，即強快取（也叫本地快取）和協商快取，瀏覽器在第一次請求發生後，再次請求時：
• 瀏覽器在請求某一資源時，會先獲取該資源快取的header資訊，判斷是否命中強快取（cache-control和expires資訊），若命中直接從快取中獲取資源資訊，包括快取header資訊；本次請求根本就不會與伺服器進行通訊；在firebug下可以檢視某個具有強快取資源返回的資訊，例如本地firebug檢視的乙個強快取js檔案
• 如果沒有命中強快取，瀏覽器會傳送請求到伺服器，請求會攜帶第一次請求返回的有關快取的header欄位資訊（last-modified/if-modified-since和etag/if-none-match），由伺服器根據請求中的相關header資訊來比對結果是否協商快取命中；若命中，則伺服器返回新的響應header資訊更新快取中的對應header資訊，但是並不返回資源內容，它會告知瀏覽器可以直接從快取獲取；否則返回最新的資源內容你可能會覺得使用last-modified已經足以讓瀏覽器知道本地的快取副本是否足夠新，為什麼還需要etag呢？http1.1中etag的出現主要是為了解決幾個last-modified比較難解決的問題：
• 一些檔案也許會週期性的更改，但是他的內容並不改變(僅僅改變的修改時間)，這個時候我們並不希望客戶端認為這個檔案被修改了，而重新get；
• 某些檔案修改非常頻繁，比如在秒以下的時間內進行修改，(比方說1s內修改了n次)，if-modified-since能檢查到的粒度是s級的，這種修改無法判斷(或者說unix記錄mtime只能精確到秒)；
• 某些伺服器不能精確的得到檔案的最後修改時間。
這時，利用etag能夠更加準確的控制快取，因為etag是伺服器自動生成或者由開發者生成的對應資源在伺服器端的唯一識別符號。
last-modified與etag是可以一起使用的，伺服器會優先驗證etag，一致的情況下，才會繼續比對last-modified，最後才決定是否返回304。
5、使用者的行為對快取的影響
盜用網上的一張圖，基本能描述使用者行為對快取的影響
總結：etag存的是是伺服器自動生成或者由開發者生成的對應資源在伺服器端的唯一識別符號。而last-modified存的是時間，如果cache-control與expires同時存在的話，cache-control的優先順序高於expires，last-modified與etag是可以一起使用的，伺服器會優先驗證etag，一致的情況下，才會繼續比對last-modified，最後才決定是否返回304。
如果當前catch-control是public，max-age沒設定，應該如何處理？
用在瀏覽器本地的（上次請求該資源的時間-上次修改該資源的時間）也就是(date-last-modified)
瀏覽器快取機制
最近在準備優化日誌請求時遇到了一些令人疑惑的問題，比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求，為什麼多次訪問時有時請求裡帶了 etag，有時又沒有帶？等等。後來查了一些資料以及同事親自驗證，總算對這些問題有了個清晰的理解，現在整理出來以...
瀏覽器快取機制
當我們瀏覽乙個頁面發現有異常時，通常考慮的就是書不是瀏覽器做了快取呢，按ctrl f5重新請求一次就能請求到沒有快取的頁面，這個是為什麼呢。首先，ctrl f5組合鍵重新整理頁面，那麼瀏覽器會直接向目標url傳送請求，而不再使用瀏覽器快取的資料。其次，當請求到達伺服器端依然有可能出現使用伺服器端的資...
瀏覽器快取機制
瀏覽器快取機制 瀏覽器快取機制，其實主要就是 協議定義的快取機制 如 expires cache control 等 但是也有非 協議定義的快取機制，如使用 html meta 標籤，web 開發者可以在 html 頁面的節點中加入 標籤，如下 上述 的作用是告訴瀏覽器當前頁面不被快取，每次訪問都需...