HTTP瀏覽器緩存粗解

前言：

請求一個頁面或文件時，觀察開發者工具中的Network頁籤中，此文件的請求狀態，會發現常見的會出現200或304狀態，做爲前端開發，200狀態最爲熟悉，而304，也是成功的請求，只不過是使用了本地緩存而已。

使用本地緩存，至少有兩個好處：

• 加快頁面的展現速度，由於不用再從服務器把文件下載一遍。
• 能極大的節約服務器寬帶。

可能縮短用戶的展現速度，只是提升用戶體驗，對開發人員沒太多益處（固然做爲有責任感的開發，這點也不能忽略），但節約服務器寬帶，則能給技術開發人員減小極大的壓力了。

因此得學。

請求頭和響應頭

要說緩存，首先須要瞭解請求頭。
每個請求，發出的時候，會自帶一個請求頭：Request Headers；
響應返回的時候，自帶一個響應頭：Response Headers；

緩存主要由服務器響應時，在響應頭中設置緩存方案，主要是設置兩個字段：

• expires：不支持HTTP1.1及更高級的HTTP版本，設置一個資源到期時間點。
• cache-control：只支持HTTP1.1和更高級的HTTP版本，優先級高於expires，能控制本地緩存（私有緩存，或者成爲瀏覽器緩存）和共享緩存（代理服務器緩存）

瀏覽器的HTTP緩存分爲兩種：

• 強緩存：手動設置了expires或cache-control。
• 協商緩存：未設置上面兩個字段時爲此模式，則爲通用的默認緩存模式，經過對比服務器文件更新時間Last-Modified，和源服務器文件每次更新時，自動生成的版本號ETag，來判斷是發送新文件，仍是返回狀態碼304，來告知瀏覽器使用瀏覽器緩存。

注：強緩存只是設置時間間隔，減小了刷新時請求服務器的次數，當請求發出後，一樣也是使用協商緩存模式處理。

本文如下出現的服務器，如無特殊說明，指的是直接能訪問到的服務器，好比如有代理服務器，則指的是代理服務器；若無代理服務器，則爲源服務器。

1. 請求頭 Request Headers

第一次請求資源，沒有任何緩存的餘地，請求頭中的相關字段以下：

• cache-control 當前瀏覽器的緩存狀況：

  • no-cache：通常爲第一次請求、或強制刷新、或明確設置no-store的不緩存時，告知後臺我這兒徹底沒有緩存，返回值正常爲200
  • 不會發出請求：非頁面html文件，設置了緩存時間，且此文件還沒有過時，狀態碼200
  • max-age=0：當前的頁面htlm文件，每次打開頁面都會請求一次，狀態值200或304
  • 沒有此字段：非第一次，設置了過時時間，可是過時了

• if-modified-since 非第一次請求，纔會有：

  • 用於協商緩存，判斷文件有沒有更新的依據，內容是上次響應時返回的Last-Modified字段，意思是服務器此文件的最後更新時間

• If-None-Match：非第一次請求，纔會有：

  • 用於協商緩存，判斷文件有沒有更新的依據，內容是上次響應時返回的ETag字段，意思是服務器此文件的最後一個更新時，服務器隨機生成的版本號
• Pragma 只第一次請求出現，值爲no-cache，效果和cache-control: "no-cache" 等同，用於兼容http1.0

2. 響應頭 Response Headers

設置位置：

• web服務器設置，好比 nginx Apache等（推薦）
• 若爲先後臺未分離項目，可由後臺代碼中設置
• 可由前端，在html頁面中，使用標籤設置

相關字段說明:

• expires 到期時間
• 已被cache-control取代，其值相似於："Wed, 08 Jan 2020 08:25:55 GMT"
• cache-control 緩存執行方案設置的經常使用值：
• max-age=秒數：單位爲秒的時間間隔，向服務器請求一次以後，再次想要請求時的間隔未超過此時間，則不會發出請求，直接使用本地緩存，狀態碼200；直到時間超過，才能發出請求，但若是服務器對比後，發現此文件未變化，則返回304，還是使用緩存，若變化了，纔會發送新文件，並返回200
• s-maxage=秒數：功能同max-age=秒數，只對代理服務器生效，優先級高於max-age=秒數
• private：只容許瀏覽器緩存
• public：能夠被代理服務器緩存
• must-revalidate：表示瀏覽器中的文件被命中，必需要檢查源服務器是否有更新，即便已經有緩存
• proxy-revalidata：表示代理服務器每次被請求，必需要檢查源服務器是否有更新，即便已經有緩存
• no-cache：看似是不緩存，其實仍然有緩存，只不過每次都會向源服務器對比一下文件，仍會出現304
• no-store：瀏覽器和代理服務器真實不緩存，每次都直接請求並獲取文件

• Date: 此文件在頁面中被使用的時間

  • 最近一次向服務器請求時，服務器返回的時間，若最近幾回刷新，都直接使用了瀏覽器緩存，沒有發出請求，則值不變，其值相似"Tue, 08 Jan 2019 08:14:59 GMT其值相似

• Last-Modified 服務器中，此文件的最後更新時間

  • 當瀏覽器再次發出請求此文件時，會把此值放在請求頭If-Modified-Since字段中（見上面請求頭說明），其值相似"Tue, 08 Jan 2019 06:45:12 GMT"

• ETag 每次源服務器的文件更新，自動生成的文件的版本號，HTTP1.1才支持

  • 當瀏覽器再次發出請求此文件時，會把此值放在請求頭If-None-Match字段中（見上面請求頭說明），優先級高於Last-Modified，其值相似"5c3446f8-57b"

注：HTTP1.0於1996年提出，HTTP1.1於1999年提出，HTTP2.0於2015年提出，當前應用最普遍的爲HTTP1.1。

注：當使用PUT方法，對服務器資源進行更新的時候，請求頭可能還會出現If-Match這個字段，這個字段與If-None-Match在使用方式相似，但功能不一樣；
這個字段會把舊文件的Etag帶給服務器，服務器在對比當前文件的Etag是否和If-None-Match（舊文件的Etag）相同，若是相同，說明此時服務器還是舊文件，則能夠覆蓋更新；若不一樣，說明此文件已被更新過，再也不進行預期的覆蓋更新。

不一樣的緩存配置和生效時機

如下爲響應頭設置不一樣的cache-control，在非html文件、不一樣的請求方式時，請求的狀況和請求頭的cache-control的值，和網絡和資源正常時，狀態碼的值。

請求方式	max-age=秒數	未設置	no-cache	no-store
首次請求或Ctrl + F5	no-cache，200，發出請求，獲得所有正文。	no-cache，200，發出請求，獲得所有正文。	no-cache，200，發出請求，獲得所有正文。	no-cache，200，發出請求，獲得所有正文。
再次請求，或輸入連接回車打開	若未過時，不發出請求，200，直接使用瀏覽器緩存；若過時，則無此字段，走協商緩存，可能200或304	不發出請求，200，直接使用瀏覽器緩存	無此字段，走協商緩存，可能200或304	無此字段，200，發出請求，獲得所有正文。
F5 刷新	同上	同上	同上	同上

html文件再第一次請求，和以上的資源狀況相同，且不管首次的響應頭中cache-control爲什麼值，非第一次請求的請求頭中的cache-control字段均爲max-age=0，使用協商緩存。

html文件是整個頁面的入口，只要html未發生變化，那說明引用的資源的名字，是沒有發生變化的，資源的請求動向會符合上面的表格；若是發生了變了，那新變化的資源，都會進行首次請求（若是很早以前，這個資源被使用過，則一樣走上面的表格）。

前端緩存的文件類別和緩存位置

前端既然能緩存，那確定也是須要分一些類別的。

WebKit內核，將資源分爲兩個大類，一個是主資源，好比html文件和下載項；二是派生資源，好比頁面中的圖片、js、css等資源。

若是主資源訪問失敗，那會馬上進行報錯，好比404（不存在該資源），403（資源拒絕這次訪問）等等；
只要主資源能夠訪問完成，那麼基礎的頁面就能夠展現了，此時若是其餘的派生資源，好比css樣式文件，js腳本文件，圖片文件等資源沒法訪問，也只會在控制檯進行報錯。

派生資源是能夠緩存的，那麼緩存位置也須要明瞭一下

當前前端緩存的文件，主要有兩個位置：

• from memory cache：緩存在內存中，當瀏覽器關閉，資源清除，也就是緩存被清除。
• from disk cache：緩存在磁盤中，能夠長久緩存，即便電腦重啓也無妨，但只能緩存派生資源。

這個位置，是能夠在前臺的控制檯的network頁籤中看到的，且也只有當用到該緩存的文件時，纔會展現，以下圖所示：

在Size一欄中，270B表示發出了請求，表示了該文件的大小；
from memory cache就顯而易見了，表示未發出請求，直接從內存中拿的現有的已緩存的資源；
from disk cache一樣表示未發出請求，只不過是從磁盤中直接拿的資源；

拓展

HTTP1.0和HTTP1.1的一些區別

HTTP1.0最先在網頁中使用是在1996年，那個時候只是使用一些較爲簡單的網頁上和網絡請求上，而HTTP1.1則在1999年纔開始普遍應用於如今的各大瀏覽器網絡請求中，同時HTTP1.1也是當前使用最爲普遍的HTTP協議。 主要區別主要體如今：

• 緩存處理，在HTTP1.0中主要使用header裏Last-Modified和Expires來，來實現協商緩存，而HTTP1.1則引入了更多的緩存控制策略例如Etag，If-Unmodified-Since（用於斷點續傳），cache-control, If-None-Match等更多可供選擇的緩存頭來控制緩存策略。
• 帶寬優化及網絡鏈接的使用，HTTP1.0中，存在一些浪費帶寬的現象，例如客戶端只是須要某個對象的一部分，而服務器卻將整個對象送過來了，而且不支持斷點續傳功能，HTTP1.1則在請求頭引入了range頭域，它容許只請求資源的某個部分，即返回碼是206（Partial Content），這樣就方便了開發者自由的選擇以便於充分利用帶寬和鏈接。
• 錯誤通知的管理，在HTTP1.1中新增了24個錯誤狀態響應碼，如409（Conflict）表示請求的資源與資源的當前狀態發生衝突；410（Gone）表示服務器上的某個資源被永久性的刪除。
• Host頭處理，在HTTP1.0中認爲每臺服務器都綁定一個惟一的IP地址，所以，請求消息中的URL並無傳遞主機名（hostname）。但隨着虛擬主機技術的發展，在一臺物理服務器上能夠存在多個虛擬主機（Multi-homed Web Servers），而且它們共享一個IP地址。HTTP1.1的請求消息和響應消息都應支持Host頭域，且請求消息中若是沒有Host頭域會報告一個錯誤（400 Bad Request）。
• 長鏈接，HTTP 1.1支持長鏈接（PersistentConnection）和請求的流水線（Pipelining）處理，在一個TCP鏈接上能夠傳送多個HTTP請求和響應，減小了創建和關閉鏈接的消耗和延遲，在HTTP1.1中默認開啓Connection： keep-alive，必定程度上彌補了HTTP1.0每次請求都要建立鏈接的缺點。

注：參考連接：HTTP1.0、HTTP1.1 和 HTTP2.0 的區別

HTTPS與HTTP的一些區別

HTTPS：是以安全爲目標的HTTP通道，簡單講是HTTP的安全版，即HTTP下加入SSL層，HTTPS的安全基礎是SSL，所以加密的詳細內容就須要SSL。

• HTTPS協議須要到CA申請證書，通常免費證書不多，須要交費。
• HTTP協議運行在TCP之上，全部傳輸的內容都是明文，HTTPS運行在SSL/TLS之上，SSL/TLS運行在TCP之上，全部傳輸的內容都通過加密的。
• HTTP和HTTPS使用的是徹底不一樣的鏈接方式，用的端口也不同，前者是80，後者是443。
• HTTPS能夠有效的防止運營商劫持，解決了防劫持的一個大問題。

注：參考連接：HTTP與HTTPS的區別