浏览器缓存知识归纳
瀏覽器緩存（Browser Catching）是為了節約網絡的資源加速瀏覽，瀏覽器在用戶磁盤上對最近請求過的文檔進行存儲，當訪問者再次請求這個頁面時，瀏覽器就可以從本地磁盤顯示文檔，這樣就可以加速頁面的閱覽。 —-摘自《百度百科》
?
瀏覽器緩存是提升網頁性能的一大利器，但是，也是一把雙刃劍。利用的好網頁的性能會有大幅度提升，服務器的壓力也會減小。利用的不好，也會遇到很多的問題。本文結合瀏覽器緩存的知識，結合真實案例進行分析，希望對讀者有所幫助。
?
瀏覽器緩存分類
?
瀏覽器緩存分為強緩存和協商緩存，瀏覽器加載一個頁面的簡單流程如下：
?
瀏覽器先根據這個資源的http頭信息來判斷是否命中強緩存。如果命中則直接加在緩存中的資源，并不會將請求發送到服務器。
如果未命中強緩存，則瀏覽器會將資源加載請求發送到服務器。服務器來判斷瀏覽器本地緩存是否失效。若可以使用，則服務器并不會返回資源信息，瀏覽器繼續從緩存加載資源。
如果未命中協商緩存，則服務器會將完整的資源返回給瀏覽器，瀏覽器加載新資源，并更新緩存。
?
強緩存
?
命中強緩存時，瀏覽器并不會將請求發送給服務器。在Chrome的開發者工具中看到http的返回碼是200，但是在Size列會顯示為(from cache)。
?
?
強緩存是利用http的返回頭中的Expires或者Cache-Control兩個字段來控制的，用來表示資源的緩存時間。
?
Expires
?
該字段會返回一個時間，比如Expires:Thu,31 Dec 2037 23:59:59 GMT。這個時間代表著這個資源的失效時間，也就是說在2037年12月31日23點59分59秒之前都是有效的，即命中緩存。這種方式有一個明顯的缺點，由于失效時間是一個絕對時間，所以當客戶端本地時間被修改以后，服務器與客戶端時間偏差變大以后，就會導致緩存混亂。于是發展出了Cache-Control。
?
Cache-Control
?
Cache-Control是一個相對時間，例如Cache-Control:3600，代表著資源的有效期是3600秒。由于是相對時間，并且都是與客戶端時間比較，所以服務器與客戶端時間偏差也不會導致問題。
?
Cache-Control與Expires可以在服務端配置同時啟用或者啟用任意一個，同時啟用的時候Cache-Control優先級高。
?
協商緩存
?
若未命中強緩存，則瀏覽器會將請求發送至服務器。服務器根據http頭信息中的Last-Modify/If-Modify-Since或Etag/If-None-Match來判斷是否命中協商緩存。如果命中，則http返回碼為304，瀏覽器從緩存中加載資源。
?
Last-Modify/If-Modify-Since
?
瀏覽器第一次請求一個資源的時候，服務器返回的header中會加上Last-Modify，Last-modify是一個時間標識該資源的最后修改時間，例如Last-Modify: Thu,31 Dec 2037 23:59:59 GMT。
?
?
當瀏覽器再次請求該資源時，上送的請求頭中會包含If-Modify-Since，該值為緩存之前返回的Last-Modify。服務器收到If-Modify-Since后，根據資源的最后修改時間判斷是否命中緩存。
?
?
如果命中緩存，則返回http304，并且不會返回資源內容，并且不會返回Last-Modify。由于對比的服務端時間，所以客戶端與服務端時間差距不會導致問題。但是有時候通過最后修改時間來判斷資源是否修改還是不太準確（資源變化了最后修改時間也可以一致）。于是出現了ETag/If-None-Match。
?
ETag/If-None-Match
?
與Last-Modify/If-Modify-Since不同的是，Etag/If-None-Match返回的是一個校驗碼（ETag: entity tag）。ETag可以保證每一個資源是唯一的，資源變化都會導致ETag變化*。服務器根據瀏覽器上送的If-None-Match值來判斷是否命中緩存。
?
?
* ETag擴展說明
?
我們對ETag寄予厚望，希望它對于每一個url生成唯一的值，資源變化時ETag也發生變化。神秘的Etag是如何生成的呢？以Apache為例，ETag生成靠以下幾種因子
?
文件的i-node編號，此i-node非彼iNode。是Linux/Unix用來識別文件的編號。是的，識別文件用的不是文件名。使用命令’ls –I’可以看到。
文件最后修改時間
文件大小
生成Etag的時候，可以使用其中一種或幾種因子，使用抗碰撞散列函數來生成。所以，理論上ETag也是會重復的，只是概率小到可以忽略。
?
生產問題分析
?
背景：某次投產，某系統投產后由于強緩存設置時間不恰當導致變更的功能沒有體現。后來通過變更文件路徑強行解決問題。
?
變更上下文根，導致URL變化一定可以解決問題。但我們不可能每一次都這么做；還有，在瀏覽器端關閉緩存、或者清除緩存后再繼續瀏覽、同時使用Ctrl+F5刷新，也可以解決問題，但是我們也不可能讓每一個客戶在投產后都做一次這個操作。
?
那我們怎么辦呢？從問題原因來看，是將經常變化的資源緩存時間設置的過長導致的。理論上來講，只要正確劃分經常變化資源與不經常變化資源就可以解決問題。但是誰也不能保證不經常變化的資源就一定不會變化。
?
萬一不經常變化的資源變更了怎么辦呢？在資源請求的URL中增加一個參數，比如：css/main.css?v=20160105。這個參數是一個版本號，客戶化在js代碼中，每一次投產的時候變更一下，當這個參數變化的時候，強緩存都會失效并重新加載。這樣一來，即使是不常變化的資源，投產以后也需要重新加載。這樣就完美的解決了問題。
?
本文參考數篇技術博客、百度百科、維基百科、Apache官方說明以及自己的理解完成，如有不正確的地方歡迎斧正。
轉載于:https://www.cnblogs.com/HCT118/p/5592370.html
總結
- 上一篇： Linux下对于inode的理解
- 下一篇： swift Array 数组