圖解 HTTP 的緩存機制 | 實用 HTTP

題圖：by @joewakeford

1、序

Hi，你們好，我是承香墨影！

HTTP 協議在網絡知識中佔據了重要的地位，HTTP 協議最基礎的就是請求和響應的報文頭（Header），大多數 Http 協議的使用方式，都是依賴設置不一樣的 HTTP 請求/響應 的 Header 來實現的。

本系列《實用 HTTP》就拋開常規的 Header 講解式的表述方式，從實際問題出發，來分析這些 Http 協議的使用方式，究竟是爲了解決什麼問題？同時講解它是如何設計的和它實現原理。

HTTP 協議是一種無狀態的「鬆散協議」，它不會記錄不一樣請求的狀態，而且由於它自己包含了兩端（客戶端和服務端），根據請求和響應來區分，它大部分的內容都只是一個建議，其實雙邊是能夠不遵照此建議的。例如：服務端說，這個數據緩存有一天的時效性，可是客戶端能夠說，我不聽我不聽，我就要每次去從新請求。

「這裏寫了建議零售價 2 元...」

「哦，不接受建議！」

說到緩存，本文就來講說 HTTP 緩存相關的內容。

2、HTTP緩存使用

2.1 爲何須要緩存

緩存說白了就是爲了快，不管是從磁盤到內存仍是從網絡到本地，都是爲了在下次實用此資源的時候，可以快速響應，避免屢次的 I/O 操做。

經過網絡獲取資源，是一件耗時的操做，較大的資源還會須要客戶端和服務端之間進行屢次往返通訊，這不但會增長客戶端響應的時間，同時還會增長網絡流量。

在 HTTP 協議中，自然就有對緩存的支持，瀏覽器和 App 使用的開源網絡庫中，都是利用 HTTP 緩存來實現對資源的緩存。

瀏覽器是自然支持 HTTP 緩存，開源庫則須要進行一些例如存規則和緩存的資源存放路徑之類的簡單設定。

2.2 設計一個緩存策略

那若是讓咱們來設計緩存的策略，首先有兩個重要的指標須要考慮。

1. 緩存失效

既然緩存主要是針對數據的複用，那咱們就須要有一個條件來斷定當前緩存的數據，是否依然有效。

老是不能一次緩存，終身使用吧，咱們還須要在緩存失效以後，從新獲取新的數據並進行緩存。這個前提就是，緩存都須要有一個失效的策略。

2. 減小讀取

雖然緩存會有失效策略，可是這只是客戶端單方面認爲失效，此時應該再去服務端從新獲取一遍數據。

可有些狀況下，其實資源可能依然有效，並無發生變更。那就須要有一個策略，讓服務端通知客戶端，當前緩存依然有效，能夠繼續使用。這樣在減小傳輸流量以外，也能夠加快相應時間，提升效率。

這就是一個好的緩存策略必需要考慮的地方，實際上 HTTP 緩存，也是這樣設計的。

2.3 HTTP 緩存

HTTP 緩存主要是經過請求和響應報文頭中的對應 Header 信息，來控制緩存的策略。

這裏主要涉及兩個 Header：

• Cache-Control：設定緩存策略，是否使用緩存，超時時間是多少。
• ETag：當前返回數據的驗證令牌，多是 Hash 值也多是其餘指紋，主要用於在下次請求的時候攜帶上，讓服務端依此判斷當前數據是否有更改。

服務端在返回響應數據的時候，會在報文頭中，增長用於描述當前響應的內容類型、數據長度、緩存策略（Cache-Control）、驗證令牌（ETag）等信息。

例如上圖就表示了一次請求響應的事務，大概客戶端請求一個文件的時候，服務端返回了一個 200 的狀態碼，表示響應正常，響應的數據長度爲 1024 個字節，建議客戶端將此資源緩存最多 120 秒，而且提供了一個指紋令牌（「cxmyDev123」），用來做爲當前數據的惟一標識。

2.4 ETag 數據令牌

Cache-Control 中設定的 max-age 很好理解，就是設定緩存超時的時間，HTTP 緩存是限定一個超時的秒數，來肯定緩存失效的時間。

上古時期還會使用 expires 來決定超時的日期，可是已經被廢棄了，若是和 Cache-Control 同時存在，以 Cache-Control 爲準。

在此時間間隔範圍內，客戶端不會再向服務端發送新的請求。當資源距離上一次緩存的時間間隔，大於 120 秒後，客戶端纔會再次向服務端發送請求。

假如沒有數據令牌的狀況下，大概步驟應該是這樣的：

1. 客戶端會首先找到本地緩存，而後發現它已經失效，沒法再次使用。

2. 客戶端再次向服務端發出新的請求，並獲取完整的數據再次進行緩存。以後再刷新該緩存的超時時間。

可是這是一件效率很是低的事情，服務端並沒有法肯定所持有的源資源何時會失效，因此提供的 max-age 值，只是一個參考值，是須要取平衡的，過短會致使請求頻繁，太長又會致使沒法及時刷新客戶端資源。而此時再次請求的時候，是存在必定的機率，客戶端緩存的數據和服務端上持有的數據是一致的，咱們就不須要再次對此數據資源進行二次緩存，直接使用客戶端以前緩存的數據便可，同時還須要刷新緩存超時時間。

這正是數據驗證令牌（ETag）想要解決的問題，服務端生成並返回的這個數據指紋令牌，一般就是返回數據的 Hash 值或者其餘數據指紋，客戶端無需關心它的生成規則，只須要知道它是當前數據的一個惟一標識。

客戶端須要在下次請求時將其經過 If-None-Match 這個請求報文頭，將此驗證令牌發送至服務端，若是數據令牌指紋和服務端當前的數據一致，則標識資源未發生新的變化。就會返回一個 304 的狀態碼，表示能夠繼續使用客戶端本地緩存的數據，並刷新超時時間。注意當響應碼爲 304 的時候，它是不包含數據內容的。

一般此緩存操做對咱們都是透明的，它是瀏覽器和開源網絡庫的基本實現，咱們無需本身去判斷 max-age 和 ETag 的值，這一步咱們只須要肯定服務端對此有支持便可。

這裏只是提到了 If-None-Match，它標識比較 ETag 是否不一致，除此以外，還有一些其餘的相關報文頭，例如 If-Match，有興趣能夠查閱相關資料。

2.5 Cache-Control

前面舉的例子中，咱們只爲 Cache-Control 設定了一個 max-age，可是其實還有一些更豐富的配置。

從緩存性能最優化的角度來看，最佳的緩存是無需與服務端通訊的緩存，能夠經過緩存來消滅網絡延遲以及數據請求，從而來提升用戶的體驗。

Cache-Control 是在 HTTP/1.1 中被定義的，它能夠用於取代以前的緩存策略，如今全部的瀏覽器都支持 Cache-Control ，它已經成爲一種通用的標準。

Cache-Control 還有一些更靈活的配置，用來對緩存作一些更細緻的操做。

1. 「no-cache」 和 「no-store」

這兩個參數都表示每一次請求，都須要真實的發送一個網絡請求。

它們之間的區別在於，「no-cache」並非真的不緩存數據，它只是要求每次都確認資源是否過時，也就是它會利用數據令牌 ETag 來必定程度的減少傳輸的流量。

而 「no-store」 徹底是要求客戶端，每次都從新請求數據並下載最新的數據，不作任何緩存處理。這種不緩存的策略，也包括中間鏈接的代理、網關 等中間傳輸的通道，也一併不對數據進行緩存，每次都從源服務器上獲取數據。

2. 「public」 和 「private」

「public」 是一種默認的策略，表示當前緩存是開放的，任何請求響應的中間環節，均可以對其進行緩存，若是咱們不顯式指定，則當前爲 「public」 緩存。

與之相對的 「private」，則表示當前響應是針對單個用戶的，並不是通用數據，所以不建議任何中間緩存對其進行緩存。例如：瀏覽器就是一個比較私人的緩存源，它會緩存 「private」 的緩存，而 CDN 則不會。

3、最佳的緩存策略樹

前面提到，緩存的核心目的就是爲了快，能讓下次使用的時候快速複用。因此在理想狀況下，咱們應該將響應數據儘量多的緩存，儘量的緩存足夠長的時間，而且爲每一個資源提供單獨的數據驗證令牌，以便在時間過時以後快速校驗。

可是任何事情都是要取其平衡點的，不存在什麼最佳緩存策略，並不是全部響應資源都須要加緩存，這就須要根據業務場景來設定。

這裏給出一個增長 HTTP 緩存的通用策略樹，你在對響應增長緩存的時候，能夠參考它來執行。

正常狀況下，咱們針對不一樣的響應屬性，會對它設置不一樣的緩存策略，下面根據場景，舉幾個例子。

3.1 用戶相關的數據

和單個用戶緊密相關的數據，一般咱們是不建議使用緩存的，可是依然存在幾個等級。

1. 嚴格不使用緩存

Cache-Control:no-store

2. 容許客戶終端緩存，可是每次使用都須要確認

Cache-Control:no-cache
ETag:"cxmyDev1234"

3. 容許客戶終端短期緩存

Cache-Control:private max-age=600
ETag:"cxmyDev1234"

3.2 通用數據

一些通用響應資源，更新的頻率很是的低，咱們能夠根據須要調整 max-age 的大小便可。

Cache-Control:max-age=86400
ETag:"cxmyDev1234"

4、廢棄和更新緩存的響應

緩存的策略，一旦肯定並下發到客戶端，服務端就失去了對齊的控制權。也就是說，若是咱們設定了 max-age，在此資源有效期超時以前，哪怕服務端的源資源已經被替換修改，咱們也沒有一個合適的時機去通知客戶端更新新的響應數據。

那麼有沒有什麼好的策略去標記資源廢棄？同時又能友好的利用緩存策略。

在互聯網上，全部服務上的資源，都有一個對應的 URL（統一資源定位符），它能夠明確說明如何從一個精確且固定的位置獲取資源。而 HTTP 緩存，也是依賴於 URL 的，注意 URL 是大小寫敏感的，同一個 URL 表示同一個請求響應，依此來判斷緩存和後續緩存的複用。

因此咱們是能夠在 URL 上作文章的。

4.1 瀏覽器的廢棄策略

前面提到，瀏覽器是自然支持 HTTP 緩存的，對於瀏覽器來講，它所面對的就是一個個 HTML 頁面，頁面內會包含一些 CSS、Image、JavaScript、JSON 資源和數據。

針對不一樣的資源和數據，咱們能夠在其 URL 上，增長數據令牌指紋，當資源變更的時候，同時也去刷新改指紋令牌。

到這裏就很好理解了：

• HTML 頁面，使用 no-cache，強制每次都向源服務器確認數據。
• CSS文件一般變更的頻率很是低，因此能夠容許中間層緩存，而且緩存時間爲一年不過時。
• JavaScript內有業務邏輯，能夠設定爲只容許客戶終端緩存。
• getUserInfo，是爲我的用戶數據相關，這裏推薦可緩存，可是須要每次向服務器從新確認。

4.2 App 接口的緩存策略

在 App 中使用的接口，其實和網頁又不同，HTML 網頁的結構相似一個樹形結構，先經過獲取 .html 文件獲取其內全部資源的表，而後依次根據緩存策略進行訪問。

可是在 App 中，和服務器的交互都是經過數據接口來實現的，就不存在最開始獲取一個相似 HTML 文件這樣的樹形接口，每一個接口都是一個個「孤島」，能夠單獨存在。咱們就沒法提早知道某個接口的響應數據已通過期，同時也沒法修改 URL 上攜帶的數據指紋令牌。

可是其實咱們是能夠經過 App 和設備的一些固有信息，做爲 URL 的參數傳遞，以此來刷新數據。

例如這裏 /app/main 獲取主頁的數據，這裏將當前 App 的版本號當參數拼接在 URL 的後面，以此方式來強制不一樣的版本，刷新不一樣的數據。避免剛升級上來的 App，還在使用舊版本的數據。

這個例子中，版本號只是其中一個維度，若是有必要，還能夠傳遞其餘維度的信息，例如當前網絡狀態，當前用戶 id 等等。

5、小結

到這裏咱們基本上把 HTTP 的緩存全部相關的內容都講了一遍，這裏簡單總結一下。

• HTTP 緩存依賴 URL 作惟一標識，不一樣的 URL 使用不一樣的緩存。
• Cache-Control 能夠控制緩存策略，共有或者私有、緩存超時時長等。
• 經過 ETag 來標記數據指紋令牌，以此來肯定響應數據是否更新。
• 應該爲每一個響應資源提供對應的緩存策略。
• 若是須要廢棄以前的緩存，能夠利用修改請求 URL 的方式，將數據指紋令牌追加在 URL 以後，以此來更新數據。

關於 HTTP 緩存，你還有什麼更好的想法，能夠在留言區討論。

參考資料：

• 《HTTP緩存》：http://t.cn/RL1NI8P
• 《基於緩存策略三要素分解法》

---

公衆號後臺回覆成長『 成長』，將會獲得我準備的學習資料，也能回覆『 加羣』，一塊兒學習進步；你還能回覆『 提問』，向我發起提問。

推薦閱讀：

• 小程序 UI 佈局指南（一）
• 程序員的密碼管理之道
• 手動刷新 MediaStore，保存的圖片當即出如今相冊中
• 僞代碼、幽默和 Google 的藝術！
• 漫畫：App 防止 Fiddler 抓包小技巧！