atitit。瀏覽器緩存機制 and 微信瀏覽器防止緩存的設計 attilax 總結

時間 2019-11-07

標籤 atitit 瀏覽器緩存機制微信防止設計 attilax 總結欄目瀏覽器简体版

原文原文鏈接

atitit。瀏覽器緩存機制 and 微信瀏覽器防止緩存的設計 attilax 總結html

1. 緩存的一些機制 1算法

1.1. http 304 1瀏覽器

1.2. 瀏覽器刷新的處理機制 1緩存

1.3. Expires 2服務器

1.4. Cache-Control 2微信

1.5. Last-Modified/E-tag 3dom

1.6. Etag 主要爲了解決 Last-Modified 沒法解決的一些問題。 4url

2. 不一樣的頁面打開方式產生的請求區別 5spa

1. 緩存的一些機制

1.1. http 304

若是已通過期了，那就去服務器請求，等待服務器響應，這是很費時間的，服務器若是發現資源沒有改變過，那麼就會返回304，告訴瀏覽器，我沒變過，你去讀緩存吧，因而瀏覽器也不用從服務器拉數據了，然而，等待服務器響應也是一個很要命的問題，在網速發達的今天，等一個響應，有時比下載還慢。

304是HTTP狀態碼，服務器用來標識這個文件沒修改，不返回內容，瀏覽器在接收到個狀態碼後，會使用瀏覽器已緩存的文件

固然瀏覽器在判斷到緩存過時後，請求中頭部附帶If-Modified-Since字段去拉取某一個文件，服務器會根據這個指定的時間去判斷，若是這個時間點以後沒有修改，也會返回304

做者:: 老哇的爪子 Attilax 艾龍， EMAIL:1466519819@qq.com

轉載請註明來源： http://blog.csdn.net/attilax

1.2. 瀏覽器刷新的處理機制

若是是用瀏覽器刷新的，那麼瀏覽器不會去判斷max-age了，直接去服務器拿，若是服務器判斷資源沒變過，則仍是會返回304，和

讀取過的文件在http header設置了expire(http 1.0) / max-age(http 1.1)，在正常瀏覽時，如未超時，而且瀏覽器也有緩存時，會直接從瀏覽器緩存取出，但若是你在當前頁面按刷新按鈕（F5）時，有的瀏覽器會再次向服務器發出請求，有些瀏覽器不會。

1.3. Expires

Expires 頭部字段提供一個日期和時間，在該日期前的全部對該資源的請求都會直接使用瀏覽器緩存而不用向服務器請求（注意：cache-control max-age 和 s-maxage 將覆蓋 Expires 頭部。）

Expires 字段接收如下格式的值：「Expires: Sun, 08 Nov 2009 03:37:26 GMT」。

可是使用Expires存在服務器端時間和瀏覽器時間不一致的問題。

1.4. Cache-Control

Cache-Control 是最重要的規則。這個字段用於指定全部緩存機制在整個請求/響應鏈中必須服從的指令。該字段一般覆蓋默認緩存算法。另外，緩存指令是單向的，即請求中存在一個指令並不意味着響應中將存在同一個指令。

簡單地說，該字段用於控制瀏覽器在什麼狀況下直接使用本地緩存而不向服務器發送請求。通常具備如下值：

· public: 全部內容都將被緩存

· private: 內容只緩存到似有緩存中

· no-cache: 全部內容都不會被緩存

· no-store: 全部內容都不會被緩存到緩存或者internet臨時文件中

· must-revalidation/proxy-revalidation: 若是緩存的內容失效，請求必須發送到服務器/代理以進行從新驗證

· max-age=xxx( xxx is numeric ): 緩存的內容將在 xxx 秒後失效, 這個選項只在HTTP 1.1可用, 並若是和Last-Modified一塊兒使用時, 優先級較高

其中最經常使用的屬性即是 max-age, 這個字段很簡單，就是瀏覽器在資源成功請求後的制定時間內，都將直接調用本地緩存和不會向服務器去請求數據。

1.5. Last-Modified/E-tag

Last-Modified和E-tag的做用都是向服務器確認當前緩存文件是否爲最新。拋開功能不看，這兩個字段的表現以下：

· 若服務器在響應一個資源時添加了Last-Modified字段，那麼當下一次瀏覽器再一次向服務器請求該資源時（前提是瀏覽器中上一次的資源被緩存過了），會在請求header中包含If-Modified-Since字段，且值與服務器第一次響應給瀏覽器的Last-Modified字段一致

· 若服務器在響應一個資源時添加了ETag字段，那麼當下一次瀏覽器再一次向服務器請求該資源時（前提是瀏覽器中上一次的資源被緩存過了），會在請求header中包含If-None-Match字段，且值與服務器第一次響應給瀏覽器的ETag字段一致

那麼上述是遵循了Http協議的瀏覽器會自動實現的，而要實現304的功能，就須要服務器（好比Apache對於靜態資源會自動實現這兩個字段的響應）或者咱們手動在服務器端編寫響應的邏輯來實現。

· 若服務器在收到的資源請求中發現含有Last-Modified字段，則說明瀏覽器中包含了該資源的某一版本的緩存，此時服務器端將根據該字段的值進行必定的邏輯判斷，以決定讓瀏覽器直接使用已有的緩存（返回304）仍是將最新的文件發送過去（200，發送新文件並更新Last-Modified字段）

· 若服務器在收到的資源請求中發現含有If-None-Matc字段，則說明瀏覽器中包含了該資源的某一版本的緩存，此時服務器端將根據該字段的值進行必定的邏輯判斷，以決定讓瀏覽器直接使用已有的緩存（返回304）仍是將最新的文件發送過去（200，發送新文件，並更新ETag）

若同時使用了Last-Modified和ETag，正確的作法應該是當二者都符合條件時，才返回304

1.6. Etag 主要爲了解決 Last-Modified 沒法解決的一些問題。

· 一些文件也許會週期性的更改，可是他的內容並不改變(僅僅改變的修改時間)，這個時候咱們並不但願客戶端認爲這個文件被修改了，而從新GET。這種狀況下能夠將某個能用來代表文件內容是否被更改的值（好比md5）來做爲ETag

· 某些文件修改很是頻繁，好比在秒如下的時間內進行修改，(比方說1s內修改了N次)，If-Modified-Since能檢查到的粒度是s級的，這種修改沒法判斷(或者說UNIX記錄MTIME只能精確到秒)

· 某些服務器不能精確的獲得文件的最後修改時間

2. 不一樣的頁面打開方式產生的請求區別

通常咱們打開（或者更新）一個頁面（或者資源）有幾種方式：

· 在地址欄中輸入地址，而後回車

· 激活當前頁面地址，而後回車

· F5刷新頁面

· 單機Back/Forward按鈕

上面幾種方式對資源的請求，會產生不一樣的結果，而且各瀏覽器的表現並不一致。具體的區別能夠參考鳥哥的《瀏覽器緩存機制》

其中你們須要注意的一點是，刷新頁面（F5或者刷新按鈕），不論是否設置了max-age，都會從新像服務器發送請求。可是這不影響304邏輯。

最後, 歸納下關鍵的結論:

關鍵結論
打開新窗口	若是指定cache-control的值爲private、no-cache、must-revalidate,那麼打開新窗口訪問時都會從新訪問服務器。而若是指定了max-age值,那麼在此值內的時間裏就不會從新訪問服務器,例如：Cache-control: max-age=5 表示當訪問此網頁後的5秒內再次訪問不會去服務器.
在地址欄回車	若是值爲private或must-revalidate,則只有第一次訪問時會訪問服務器,之後就再也不訪問。若是值爲no-cache,那麼每次都會訪問。若是值爲max-age,則在過時以前不會重複訪問。
按後退按扭	若是值爲private、must-revalidate、max-age,則不會重訪問,而若是爲no-cache,則每次都重複訪問.
按刷新按扭	不管爲什麼值,都會重複訪問.