瀏覽器 HTTP 協議緩存機制詳解--網絡緩存決策機制流程圖

時間 2019-11-16

原文原文鏈接

https://www.cnblogs.com/520yang/articles/4807408.htmlphp

最近在準備優化日誌請求時遇到了一些使人疑惑的問題，好比爲何響應頭裏出現了兩個 cache control、爲何明明設置了 no cache 卻仍是發請求，爲何屢次訪問時有時請求裏帶了 etag，有時又沒有帶？等等。。。html

後來查了一些資料以及同事親自驗證，總算對這些問題有了個清晰的理解，如今整理出來以備忘。node

一、緩存的分類

緩存分爲服務端側（server side，好比 Nginx、Apache）和客戶端側（client side，好比 web browser）。web

服務端緩存又分爲代理服務器緩存和反向代理服務器緩存（也叫網關緩存，好比 Nginx反向代理、Squid等），其實普遍使用的 CDN 也是一種服務端緩存，目的都是讓用戶的請求走」捷徑「，而且都是緩存圖片、文件等靜態資源。segmentfault

客戶端側緩存通常指的是瀏覽器緩存，目的就是加速各類靜態資源的訪問，想一想如今的大型網站，隨便一個頁面都是一兩百個請求，天天 pv 都是億級別，若是沒有緩存，用戶體驗會急劇降低、同時服務器壓力和網絡帶寬都面臨嚴重的考驗。瀏覽器

二、瀏覽器緩存機制詳解

瀏覽器緩存控制機制有兩種：HTML Meta標籤 vs. HTTP頭信息緩存

2.1 HTML Meta標籤控制緩存

瀏覽器緩存機制，其實主要就是HTTP協議定義的緩存機制（如： Expires； Cache-control等）。可是也有非HTTP協議定義的緩存機制，如使用HTML Meta 標籤，Web開發者能夠在HTML頁面的<head>節點中加入<meta>標籤，代碼以下：服務器

 
         < 
         META  
         HTTP-EQUIV 
         = 
         "Pragma"  
         CONTENT 
         = 
         "no-cache" 
         >

上述代碼的做用是告訴瀏覽器當前頁面不被緩存，每次訪問都須要去服務器拉取。使用上很簡單，但只有部分瀏覽器能夠支持，並且全部緩存代理服務器都不支持，由於代理不解析HTML內容自己。而普遍應用的仍是 HTTP頭信息來控制緩存，下面我主要介紹HTTP協議定義的緩存機制。網絡

2.2 HTTP頭信息控制緩存

2.2.1 瀏覽器請求流程

瀏覽器第一次請求流程圖：

瀏覽器再次請求時：

2.2.2 幾個重要概念解釋

Expires策略：Expires是Web服務器響應消息頭字段，在響應http請求時告訴瀏覽器在過時時間前瀏覽器能夠直接從瀏覽器緩存取數據，而無需再次請求。不過Expires 是HTTP 1.0的東西，如今默認瀏覽器均默認使用HTTP 1.1，因此它的做用基本忽略。Expires 的一個缺點就是，返回的到期時間是服務器端的時間，這樣存在一個問題，若是客戶端的時間與服務器的時間相差很大（好比時鐘不一樣步，或者跨時區），那麼偏差就很大，因此在HTTP 1.1版開始，使用Cache-Control: max-age=秒替代。
Cache-control策略（重點關注）：Cache-Control與Expires的做用一致，都是指明當前資源的有效期，控制瀏覽器是否直接從瀏覽器緩存取數據仍是從新發請求到服務器取數據。只不過Cache-Control的選擇更多，設置更細緻，若是同時設置的話，其優先級高於Expires。

 
         值能夠是public、private、no-cache、no- store、no-transform、must-revalidate、proxy-revalidate、max-age 
        
         各個消息中的指令含義以下： 
        
         Public指示響應可被任何緩存區緩存。 
        
         Private指示對於單個用戶的整個或部分響應消息，不能被共享緩存處理。這容許服務器僅僅描述當用戶的部分響應消息，此響應消息對於其餘用戶的請求無效。 
        
         no-cache指示請求或響應消息不能緩存，該選項並非說能夠設置」不緩存「，容易望文生義~ 
        
         no-store用於防止重要的信息被無心的發佈。在請求消息中發送將使得請求和響應消息都不使用緩存，徹底不存下來。 
        
         max-age指示客戶機能夠接收生存期不大於指定時間（以秒爲單位）的響應。 
        
         min-fresh指示客戶機能夠接收響應時間小於當前時間加上指定時間的響應。 
        
         max-stale指示客戶機能夠接收超出超時期間的響應消息。若是指定max-stale消息的值，那麼客戶機能夠接收超出超時期指定值以內的響應消息。

Last-Modified/If-Modified-Since：Last-Modified/If-Modified-Since要配合Cache-Control使用。

 
         Last-Modified：標示這個響應資源的最後修改時間。web服務器在響應請求時，告訴瀏覽器資源的最後修改時間。 
        
         If-Modified-Since：當資源過時時（使用Cache-Control標識的max-age），發現資源具備Last-Modified聲明，則再次向web服務器請求時帶上頭 If-Modified-Since，表示請求時間。web服務器收到請求後發現有頭If-Modified-Since 則與被請求資源的最後修改時間進行比對。若最後修改時間較新，說明資源又被改動過，則響應整片資源內容（寫在響應消息包體內），HTTP 200；若最後修改時間較舊，說明資源無新修改，則響應HTTP 304 (無需包體，節省瀏覽)，告知瀏覽器繼續使用所保存的cache。

Etag/If-None-Match：Etag/If-None-Match也要配合Cache-Control使用。

 
         Etag：web服務器響應請求時，告訴瀏覽器當前資源在服務器的惟一標識（生成規則由服務器決定）。Apache中，ETag的值，默認是對文件的索引節（INode），大小（Size）和最後修改時間（MTime）進行Hash後獲得的。 
        
         If-None-Match：當資源過時時（使用Cache-Control標識的max-age），發現資源具備Etage聲明，則再次向web服務器請求時帶上頭If-None-Match （Etag的值）。web服務器收到請求後發現有頭If-None-Match 則與被請求資源的相應校驗串進行比對，決定返回200或304。

既生Last-Modified何生Etag？你可能會以爲使用Last-Modified已經足以讓瀏覽器知道本地的緩存副本是否足夠新，爲何還須要Etag（實體標識）呢？HTTP1.1中Etag的出現主要是爲了解決幾個Last-Modified比較難解決的問題：

 
         Last-Modified標註的最後修改只能精確到秒級，若是某些文件在1秒鐘之內，被修改屢次的話，它將不能準確標註文件的修改時間 
        
         若是某些文件會被按期生成，當有時內容並無任何變化，但Last-Modified卻改變了，致使文件無法使用緩存 
        
         有可能存在服務器沒有準確獲取文件修改時間，或者與代理服務器時間不一致等情形

Etag是服務器自動生成或者由開發者生成的對應資源在服務器端的惟一標識符，可以更加準確的控制緩存。Last-Modified與ETag一塊兒使用時，服務器會優先驗證ETag。

yahoo的Yslow法則中則提示謹慎設置Etag：須要注意的是分佈式系統裏多臺機器間文件的last-modified必須保持一致，以避免負載均衡到不一樣機器致使比對失敗，Yahoo建議分佈式系統儘可能關閉掉Etag(每臺機器生成的etag都會不同，由於除了 last-modified、inode 也很難保持一致)。
Pragma行是爲了兼容HTTP1.0，做用與Cache-Control: no-cache是同樣的。
最後總結下幾種狀態碼的區別：

三、用戶行爲與緩存

瀏覽器緩存行爲還有用戶的行爲有關，若是你們對強制刷新（Ctrl + F5）還有印象的話應該能馬上明白個人意思~負載均衡

用戶操做	Expires/Cache-Control	Last-Modified/Etag
地址欄回車	有效	有效
頁面連接跳轉	有效	有效
新開窗口	有效	有效
前進、後退	有效	有效
F5刷新	無效(BR重置max-age=0)	有效
Ctrl+F5刷新	無效（重置CC=no-cache）	無效（請求頭丟棄該選項）