瀏覽器快取機制詳解

2021-06-19 17:28:24 字數 3539 閱讀 3553

瀏覽器的快取機制,主要指由http

協議 定義的快取機制。但也有非

協議定義的快取機制,如

html meta 

標籤,但所有快取**伺服器都不支援,因為**不解析

html

內容本身。

下主要介紹

協議定義的快取機制

cache-control 用於指定

快取控制

cache-control

的選擇更多,設定更細緻,優先順序高於

expires

public —— 

指示該響應可以被共享快取快取。

private ——

指示該響應只能作為私有快取。

no-cache —— 

指示請求或響應訊息

no-store ——  

在請求訊息中傳送將使得請求和響應訊息都不使用快取。

max-age —— 

指示客戶機可以接收生存期不大於指定時間(以秒為單位)的響應。

min-fresh —— 

指示客戶機可以接收響應時間小於當前時間加上指定時間的響應。

max-stale —— 

指示客戶機可以接收超出超時期間的響應訊息。如果指定max-stale

訊息的值,那麼客戶機可以接收超出超時期指定值之內的響應訊息。

last-modified/if-modified-since

要配合cache-control

使用。若資源改動過,則響應

;若資源無修改,則響應

,告知瀏覽器繼續使用

cache並更新快取

。etag/if-none-match

也要配合

cache-control

使用。

中etag

的出現主要是為了解決幾個

last-modified

比較難解決的問題:

llast-modified

標註的最後修改只精確到秒級,如果某檔案在

1秒內,被修改多次,將不能準確標註檔案的修改時間

l如果某檔案會被定期生成,但有時內容並沒有任何變化,但

last-modified

卻改變了,導致檔案沒法使用快取

l有可能存在伺服器沒有準確獲取檔案修改時間,或者與**伺服器時間不一致等情形

etag

是伺服器自動生成或者由開發者生成的對應資源在伺服器端的唯一識別符號,能夠更加準確的控制快取。last-modified

與etag

是可以一起使用的,

伺服器會優先驗證

etag

,一致的情況下,才會繼續比對

last-modified

,最後才決定是否返回

304。

瀏覽器快取行為還有使用者的行為有關!

使用者操作

expires/cache-control

last-modified/etag

位址列回車 有效

有效頁面鏈結跳轉 有效

有效新開視窗 有效

有效前進、後退 有效

有效f5

重新整理 無效

有效ctrl+f5

重新整理 無效

無效 快取的處理流程

處理流程圖,如上所示,下面分步驟具體介紹:

1)請求處理

使用者發起乙個http請求,快取獲取到url,根據url查詢是否有匹配的副本,這個副本可能在記憶體中,也可能在本地磁碟。

2) 新鮮度檢測

如果快取中存在所請求資源的副本,則進行新鮮度檢測,檢查這個副本有沒有過期,如果沒有過期,直接使用。如果已經過期,則進行再驗證。

3)伺服器再驗證

快取中的文件過期了並不代表他和伺服器上的不一樣,所以這個時候就需要問問伺服器,過期的這段時間裡這個文件到底有沒有改變。如果改變了,快取就會獲取乙份新的文件副本,然後傳送給客戶端。如果沒有改變,快取只需要獲取新的首部,包括乙個新的過期時間,並對快取中的首部更新。

4)建立響應並返回

我們希望快取看起來就像是來自原始伺服器一樣,快取將已快取的伺服器響應首部作為響應首部,傳送給客戶端。

保質期的實現

http中,通過 cache-control 首部和 expires 首部為文件指定過期時間,通過對過期時間的判斷,快取就可以知道文件是不是在保質期內。expires 首部和 cache-control:max-age 首部都是來告訴快取文件有沒有過期,為什麼需要兩個響應首部來做這件簡單的事情了?其實這一切都是歷史原因,expires首部是http 1.0中提出來的,因為他使用的是絕對日期,如果服務端和客戶端時鐘不同步的話(實際上這種情況非常常見),快取可能就會認為文件已經過了保質期。

http 1.1為了修正這個問題,引入了cache-control:max-age首部,這個首部使用相對時間來控制保質期,讓一切變得更加合理。

伺服器再驗證

http中,使用兩個請求首部來完成這個功能:if-modified-sice 和 if-none-match。為啥又要兩個首部來完成這個功能了?答案還是因為歷史的原因。一開始使用 if-modified-sice:首部,date是上一次快取檔案時,響應中last-modified首部的值。

客戶端拿著這個值,問伺服器,這段時間內檔案有沒有修改過?伺服器看了看這個檔案的修改時間,如果沒有修改過,會返回乙個304 not modified的響應;如果修改過,把最新的檔案返回給客戶端。後來,人們發現這樣有問題,因為就算修改時間變化了,文件也不一定發生改變!於是乎,就有了 if-none-match:首部,tag是上一次快取文件時,響應中etag的值,etag是一種唯一標識資源的方式。

試探性過期

如果響應中既沒有cache-control:max-age首部又沒有expires首部,快取可以計算出乙個試探性最大使用期。這東西打個比方就是快取會根據響應的last-modified來決定這文件靠不靠譜,需不需要再驗證,如果last-modified中的日期是很早之前,那快取就認為這文件挺靠譜,近期之內應該不會變化;如果last-modified中的日期是最近幾天,那快取可能就認為這文件可能經常改變,不靠譜。當然這麼粗略的判斷想想就知道不嚴謹,所以我們一定要設定expires首部和cache-control首部。

寫在最後

在chrome上為了保證檔案安全,不信任快取過期時間的設定,每次請求時都會詢問伺服器(再驗證)。

瀏覽器快取機制詳解

瀏覽器快取就是把乙個已經請求過的web資源 比如html image js css等檔案 拷貝乙份副本儲存在瀏覽器中。快取會根據進來的請求儲存輸出內容的副本。當下乙個請求來到的時候,如果是相同的url,快取會根據快取機制決定是直接使用副本響應訪問請求,還是向源伺服器再次傳送請求。1 減少網路頻寬消耗...

瀏覽器快取機制

最近在準備優化日誌請求時遇到了一些令人疑惑的問題,比如為什麼響應頭里出現了兩個 cache control 為什麼明明設定了 no cache 卻還是發請求,為什麼多次訪問時有時請求裡帶了 etag,有時又沒有帶?等等。後來查了一些資料以及同事親自驗證,總算對這些問題有了個清晰的理解,現在整理出來以...

瀏覽器快取機制

當我們瀏覽乙個頁面發現有異常時,通常考慮的就是書不是瀏覽器做了快取呢,按ctrl f5重新請求一次就能請求到沒有快取的頁面,這個是為什麼呢。首先,ctrl f5組合鍵重新整理頁面,那麼瀏覽器會直接向目標url傳送請求,而不再使用瀏覽器快取的資料。其次,當請求到達伺服器端依然有可能出現使用伺服器端的資...