瀏覽器快取機制

本文整理在，我的github上。歡迎star。

主要目的是允許post請求的響應將客戶端定位到某個資源上。比如說，在檔案上傳完成後讓客戶端自動重定向到乙個上傳成功的結果頁面。

通知瀏覽器，可以使用快取。這篇博文要描述的重點

說到瀏覽器快取，通常會遇到一下兩種。

那麼，這兩種http狀態，對應什麼樣的機制，流程呢？

綜合以上描述，瀏覽器在請求乙個資源時，使用快取的流程大概如下。

首先瀏覽器會判斷，這個資源是否有快取。沒有的話，正常請求。

如果有快取的話，瀏覽會判斷快取是否過期。如果快取沒有過期，則直接使用。此時就是200（from cache）。

通過上次快取留下的：cache-control max-age 和 expires。

注意：cache-control的優先順序高於expires。

如果瀏覽器的快取過期了，它會請求伺服器。伺服器會校驗快取的資料是否真的發生了更改。如果伺服器端發現資料沒有變。就會返回乙個304告訴瀏覽器，你請求的資料「not modified」，可以繼續用快取。同時，瀏覽器會更新快取首部的過期時間等資訊。

這裡瀏覽器發起請求時，會用到上次快取首部的last-modified/e-tag。

具體做法是：

取出上次快取的last-modified的值，放在本次請求header的if-modified-since中。

取出上次快取的e-tag的值，放在本次請求header中的if-none-match中。

伺服器會據此判斷資源是否發生過修改，瀏覽器中的快取是否依然可用。

如果伺服器端修改了上次快取的內容，則直接返回200，並攜帶新的內容。

![瀏覽器快取流程圖](

上文中提到了幾個http頭，這裡做一下詳細的解釋。

頭部字段提供乙個日期和時間。

（cache-control max-age 和 s-maxage 將覆蓋 expires 頭部。）

寫到這，整個瀏覽器及http快取機制應該徹底介紹清楚了。

那麼，就只剩下如何應用了。

所謂靜態資源，就是很少會修改的內容，包括前端常年打交道的css、js及檔案等等。

通常情況下，靜態資源的http頭是這樣配置的。

cache-control: public, max-age=31536000
expires: (一年後的今天)
etag: (基於內容生成)
last-modified: (過去某個時間)
vary: accept-encoding

到這裡，可以據此給站點中全部的靜態資源配置快取頭。這裡我有兩個建議。

對於非私密性和經常性變動的資源，我們可以這樣做。

cache-control: public, max-age=0
expires: (當前時間)
etag: (基於內容生成)
last-modified: (過去某個時間)
vary: accept-encoding

這樣配置的意義在於，內容可以被瀏覽器快取起來。但是因為過期時間的問題，每次都會到服務端判斷是否過期。未過期的話，就會收到304，進而繼續使用快取。

你如果需要更嚴格的控制，需要告知瀏覽器即使當使用者點選了「返回／前進」按鈕，也需要重新檢查這些資源檔案，那麼可以使用：

cache-control: public, no-cache, no-store

對於私密或者針對使用者的內容，需要把 public 替換為 private 以避免內容被**快取。

cache-control: private, …

建議避免使用 etag。尤其是使用apache，又配置了負載均衡的情況下。

針對生成的 etag，預設的apache方法需要把檔案的索引節（inode），大小（size）和最後修改時間作為輸入求值得到。這會導致在負載均衡的環境中，生成的 etag 值變得毫無用處，因為每個伺服器都會針對相同的檔案生成乙個不同的 etag 值。這個可能就是唯一的問題導致很多人完全禁用 etag，其實只要精確地針對乙個匹配的檔案生成乙個獨一無二的 etag 值，就沒有必要禁用 etag 了。

指定「vary: accept-encoding」標頭，用一句話來說明它的意義，就是「告訴**伺服器快取兩種版本的資源：壓縮和非壓縮，這有助於避免一些公共**不能正確地檢測content-encoding標頭的問題。

還有乙個現實的原因：ie 瀏覽器不快取任何帶有 vary 頭但值不為 accept-encoding 和 user-agent 的資源。所以通過這種方式新增這個頭，才能確保這些資源在 ie 下被快取。

總的來說，加這麼一句肯定沒錯，相當於「多喝熱水」。

瀏覽器快取機制

瀏覽器快取機制

瀏覽器快取機制

瀏覽器快取機制

相關推薦