瀏覽器中緩存機制的示例分析

這篇文章主要介紹了瀏覽器中緩存機制的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

瀏覽器的緩存機制？

認識瀏覽器緩存

當瀏覽器請求一個網(wǎng)站時，會加載各種資源，對于一些不經(jīng)常變動的資源，瀏覽器會將他們保存在本地內(nèi)存中，下次訪問時直接加載這些資源，提高訪問速度。

如何知道資源是請求的服務器還是讀取的緩存呢？

看上面這張圖，有些資源的size值是大小，有些是from disk cache，有些是from memory cache，顯示大小的是請求的服務器資源，而顯示后面兩種的則是讀取的緩存。

• disk cache： 就是將資源存儲在磁盤中，等待下次訪問時不需重新下載，直接從磁盤中讀取，它的直接操作對象為CurlCacheManager。（效率比內(nèi)存緩存慢，但存儲容量大，存儲時間長）

• memory cache： 就是將資源緩存到內(nèi)存中，等待下次訪問時不需重新下載，直接從內(nèi)存中讀取。（從效率上看它是最快的，從存活時間來看，它是最短的。）

瀏覽器緩存分類

• 強緩存

• 協(xié)商緩存

瀏覽器在向服務器請求資源時，首先判斷是否命中強緩存，沒命中再判斷是否命中協(xié)商緩存

強緩存

瀏覽器在加載資源時，會先根據(jù)本地緩存資源的header中判斷是否命中強緩存，如果命中則直接使用緩存中的資源，不會再向服務器發(fā)送請求。 （這里的header中的信息指的是 expires 和 cache-control）

• Expires

該字段是 http1.0 時的規(guī)范，它的值為一個絕對時間的 GMT 格式的時間字符串，比如 Expires:Mon,18 Oct 2066 23:59:59 GMT。這個時間代表著這個資源的失效時間，在此時間之前，即命中緩存。這種方式有一個明顯的缺點，由于失效時間是一個絕對時間，所以當服務器與客戶端時間偏差較大時，就會導致緩存混亂。所以這種方式很快在后來的HTTP1.1版本中被拋棄了。

• Cache-Control

Cache-Control 是 http1.1 時出現(xiàn)的 header 信息，主要是利用該字段的 max-age 值來進行判斷，它是一個相對時間，例如 Cache-Control:max-age=3600，代表著資源的有效期是 3600 秒。cache-control 除了該字段外，還有下面幾個比較常用的設置值：

no-cache：需要進行協(xié)商緩存，發(fā)送請求到服務器確認是否使用緩存。

no-store：禁止使用緩存，每一次都要重新請求數(shù)據(jù)。

public：可以被所有的用戶緩存，包括終端用戶和 CDN 等中間代理服務器。

private：只能被終端用戶的瀏覽器緩存，不允許 CDN 等中繼緩存服務器對其緩存。

Cache-Control 與 Expires 可以在服務端配置同時啟用，同時啟用的時候 Cache-Control 優(yōu)先級高。

協(xié)商緩存

當強緩存沒命中時，瀏覽器會發(fā)送一個請求到服務器，服務器根據(jù) header 中的信息來判斷是否命中協(xié)商緩存。如果命中，則返回304 ，告訴瀏覽器資源未更新，可以使用本地緩存。 （這里的header信息指的是Last-Modify/If-Modify-Since 和 ETag/If-None-Match）

• Last-Modify/If-Modify-Since

瀏覽器第一次請求一個資源的時候，服務器返回的 header 中會加上 Last-Modify，Last-modify 是一個時間標識該資源的最后修改時間。

當瀏覽器再次請求該資源時，request 的請求頭中會包含 If-Modify-Since，該值為緩存之前返回的 Last-Modify。服務器收到 If-Modify-Since 后，根據(jù)資源的最后修改時間判斷是否命中緩存。

如果命中緩存，則返回 304，并且不會返回資源內(nèi)容，并且不會返回 Last-Modify。

缺點:

短時間內(nèi)資源發(fā)生了改變，Last-Modified 并不會發(fā)生變化。

周期性變化。如果這個資源在一個周期內(nèi)修改回原來的樣子了，我們認為是可以使用緩存的，但是 Last-Modified 可不這樣認為,因此便有了 ETag。

• ETag/If-None-Match

與 Last-Modify/If-Modify-Since 不同的是，Etag/If-None-Match 返回的是一個校驗碼。ETag 可以保證每一個資源是唯一的，資源變化都會導致 ETag 變化。服務器根據(jù)瀏覽器上送的 If-None-Match 值來判斷是否命中緩存。

與 Last-Modified 不一樣的是，當服務器返回 304 Not Modified 的響應時，由于 ETag 重新生成過，response header 中還會把這個 ETag 返回，即使這個 ETag 跟之前的沒有變化。

Last-Modified 與 ETag 是可以一起使用的，服務器會優(yōu)先驗證 ETag，一致的情況下，才會繼續(xù)比對 Last-Modified，最后才決定是否返回 304。

總結

當瀏覽器訪問一個已經(jīng)訪問過的資源是，它的步驟是：

1.先看是否命中強緩存，命中?的話直接使用緩存

2.沒命中強緩存，則會發(fā)送請求到服務器看是否命中?協(xié)商緩存

3.如果命中了協(xié)商緩存，服務器會返回304告訴瀏覽器可以使用本地緩存

4.沒命中協(xié)商緩存，則服務器會返回新的資源給瀏覽器

感謝你能夠認真閱讀完這篇文章，希望小編分享的“瀏覽器中緩存機制的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業(yè)資訊頻道，更多相關知識等著你來學習!