圖解 HTTP 的緩存機(jī)制 | 實(shí)用 HTTP

作者：張旸 2018-07-12 15:30:03

HTTP 協(xié)議在網(wǎng)絡(luò)知識中占據(jù)了重要的地位，HTTP 協(xié)議最基礎(chǔ)的就是請求和響應(yīng)的報(bào)文頭（Header），大多數(shù) Http 協(xié)議的使用方式，都是依賴設(shè)置不同的 HTTP 請求/響應(yīng) 的 Header 來實(shí)現(xiàn)的。

[[236386]]

一、序

Hi，大家好，我是承香墨影！

本系列《實(shí)用 HTTP》就拋開常規(guī)的 Header 講解式的表述方式，從實(shí)際問題出發(fā)，來分析這些 Http 協(xié)議的使用方式，到底是為了解決什么問題？同時講解它是如何設(shè)計(jì)的和它實(shí)現(xiàn)原理。

HTTP 協(xié)議是一種無狀態(tài)的“松散協(xié)議”，它不會記錄不同請求的狀態(tài)，并且因?yàn)樗旧戆藘啥耍蛻舳撕头?wù)端），根據(jù)請求和響應(yīng)來區(qū)分，它大部分的內(nèi)容都只是一個建議，其實(shí)雙邊是可以不遵守此建議的。例如：服務(wù)端說，這個數(shù)據(jù)緩存有一天的時效性，但是客戶端可以說，我不聽我不聽，我就要每次去重新請求。

“這里寫了建議零售價(jià) 2 元…”

“哦，不接受建議！”

說到緩存，本文就來說說 HTTP 緩存相關(guān)的內(nèi)容。

二、HTTP緩存使用

2.1 為什么需要緩存

緩存說白了就是為了快，無論是從磁盤到內(nèi)存還是從網(wǎng)絡(luò)到本地，都是為了在下次實(shí)用此資源的時候，能夠快速響應(yīng)，避免多次的 I/O 操作。

通過網(wǎng)絡(luò)獲取資源，是一件耗時的操作，較大的資源還會需要客戶端和服務(wù)端之間進(jìn)行多次往返通信，這不但會增加客戶端響應(yīng)的時間，同時還會增加網(wǎng)絡(luò)流量。

在 HTTP 協(xié)議中，天然就有對緩存的支持，瀏覽器和 App 使用的開源網(wǎng)絡(luò)庫中，都是利用 HTTP 緩存來實(shí)現(xiàn)對資源的緩存。

瀏覽器是天然支持 HTTP 緩存，開源庫則需要進(jìn)行一些例如存規(guī)則和緩存的資源存放路徑之類的簡單設(shè)定。

2.2 設(shè)計(jì)一個緩存策略

那如果讓我們來設(shè)計(jì)緩存的策略，首先有兩個重要的指標(biāo)需要考慮。

1. 緩存失效

既然緩存主要是針對數(shù)據(jù)的復(fù)用，那我們就需要有一個條件來判定當(dāng)前緩存的數(shù)據(jù)，是否依然有效。

總是不能一次緩存，終身使用吧，我們還需要在緩存失效之后，重新獲取新的數(shù)據(jù)并進(jìn)行緩存。這個前提就是，緩存都需要有一個失效的策略。

2. 減少讀取

雖然緩存會有失效策略，但是這只是客戶端單方面認(rèn)為失效，此時應(yīng)該再去服務(wù)端重新獲取一遍數(shù)據(jù)。

可有些情況下，其實(shí)資源可能依然有效，并沒有發(fā)生變動。那就需要有一個策略，讓服務(wù)端通知客戶端，當(dāng)前緩存依然有效，可以繼續(xù)使用。這樣在減少傳輸流量之外，也可以加快相應(yīng)時間，提高效率。

這就是一個好的緩存策略必須要考慮的地方，實(shí)際上 HTTP 緩存，也是這樣設(shè)計(jì)的。

2.3 HTTP 緩存

HTTP 緩存主要是通過請求和響應(yīng)報(bào)文頭中的對應(yīng) Header 信息，來控制緩存的策略。

這里主要涉及兩個 Header：

Cache-Control：設(shè)定緩存策略，是否使用緩存，超時時間是多少。
ETag：當(dāng)前返回?cái)?shù)據(jù)的驗(yàn)證令牌，可能是 Hash 值也可能是其他指紋，主要用于在下次請求的時候攜帶上，讓服務(wù)端依此判斷當(dāng)前數(shù)據(jù)是否有更改。

服務(wù)端在返回響應(yīng)數(shù)據(jù)的時候，會在報(bào)文頭中，增加用于描述當(dāng)前響應(yīng)的內(nèi)容類型、數(shù)據(jù)長度、緩存策略（Cache-Control）、驗(yàn)證令牌（ETag）等信息。

例如上圖就表示了一次請求響應(yīng)的事務(wù)，大概客戶端請求一個文件的時候，服務(wù)端返回了一個 200 的狀態(tài)碼，表示響應(yīng)正常，響應(yīng)的數(shù)據(jù)長度為 1024 個字節(jié)，建議客戶端將此資源緩存最多 120 秒，并且提供了一個指紋令牌（“cxmyDev123”），用來作為當(dāng)前數(shù)據(jù)的唯一標(biāo)識。

2.4 ETag 數(shù)據(jù)令牌

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

上古時期還會使用 expires 來決定超時的日期，但是已經(jīng)被廢棄了，如果和 Cache-Control 同時存在，以 Cache-Control 為準(zhǔn)。

在此時間間隔范圍內(nèi)，客戶端不會再向服務(wù)端發(fā)送新的請求。當(dāng)資源距離上一次緩存的時間間隔，大于 120 秒后，客戶端才會再次向服務(wù)端發(fā)送請求。

假如沒有數(shù)據(jù)令牌的情況下，大概步驟應(yīng)該是這樣的：

1. 客戶端會首先找到本地緩存，然后發(fā)現(xiàn)它已經(jīng)失效，無法再次使用。

2. 客戶端再次向服務(wù)端發(fā)出新的請求，并獲取完整的數(shù)據(jù)再次進(jìn)行緩存。之后再刷新該緩存的超時時間。

但是這是一件效率非常低的事情，服務(wù)端并無法確定所持有的源資源什么時候會失效，所以提供的 max-age 值，只是一個參考值，是需要取平衡的，太短會導(dǎo)致請求頻繁，太長又會導(dǎo)致無法及時刷新客戶端資源。而此時再次請求的時候，是存在一定的概率，客戶端緩存的數(shù)據(jù)和服務(wù)端上持有的數(shù)據(jù)是一致的，我們就不需要再次對此數(shù)據(jù)資源進(jìn)行二次緩存，直接使用客戶端之前緩存的數(shù)據(jù)即可，同時還需要刷新緩存超時時間。

這正是數(shù)據(jù)驗(yàn)證令牌（ETag）想要解決的問題，服務(wù)端生成并返回的這個數(shù)據(jù)指紋令牌，通常就是返回?cái)?shù)據(jù)的 Hash 值或者其他數(shù)據(jù)指紋，客戶端無需關(guān)心它的生成規(guī)則，只需要知道它是當(dāng)前數(shù)據(jù)的一個唯一標(biāo)識。

客戶端需要在下次請求時將其通過 If-None-Match 這個請求報(bào)文頭，將此驗(yàn)證令牌發(fā)送至服務(wù)端，如果數(shù)據(jù)令牌指紋和服務(wù)端當(dāng)前的數(shù)據(jù)一致，則標(biāo)識資源未發(fā)生新的變化。就會返回一個 304 的狀態(tài)碼，表示可以繼續(xù)使用客戶端本地緩存的數(shù)據(jù)，并刷新超時時間。注意當(dāng)響應(yīng)碼為 304 的時候，它是不包含數(shù)據(jù)內(nèi)容的。

通常此緩存操作對我們都是透明的，它是瀏覽器和開源網(wǎng)絡(luò)庫的基本實(shí)現(xiàn)，我們無需自己去判斷 max-age 和 ETag 的值，這一步我們只需要確定服務(wù)端對此有支持即可。

這里只是提到了 If-None-Match，它標(biāo)識比較 ETag 是否不一致，除此之外，還有一些其他的相關(guān)報(bào)文頭，例如 If-Match，有興趣可以查閱相關(guān)資料。

2.5 Cache-Control

前面舉的例子中，我們只為 Cache-Control 設(shè)定了一個 max-age，但是其實(shí)還有一些更豐富的配置。

從緩存性能***化的角度來看，***的緩存是無需與服務(wù)端通信的緩存，可以通過緩存來消滅網(wǎng)絡(luò)延遲以及數(shù)據(jù)請求，從而來提高用戶的體驗(yàn)。

Cache-Control 是在 HTTP/1.1 中被定義的，它可以用于取代之前的緩存策略，現(xiàn)在所有的瀏覽器都支持 Cache-Control ，它已經(jīng)成為一種通用的標(biāo)準(zhǔn)。

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

1. “no-cache” 和 “no-store”

這兩個參數(shù)都表示每一次請求，都需要真實(shí)的發(fā)送一個網(wǎng)絡(luò)請求。

它們之間的區(qū)別在于，“no-cache”并不是真的不緩存數(shù)據(jù)，它只是要求每次都確認(rèn)資源是否過期，也就是它會利用數(shù)據(jù)令牌 ETag 來一定程度的減小傳輸?shù)牧髁俊?/p>

而 “no-store” 完全是要求客戶端，每次都重新請求數(shù)據(jù)并下載***的數(shù)據(jù)，不做任何緩存處理。這種不緩存的策略，也包括中間連接的代理、網(wǎng)關(guān) 等中間傳輸?shù)耐ǖ溃惨徊⒉粚?shù)據(jù)進(jìn)行緩存，每次都從源服務(wù)器上獲取數(shù)據(jù)。

2. “public” 和 “private”

“public” 是一種默認(rèn)的策略，表示當(dāng)前緩存是開放的，任何請求響應(yīng)的中間環(huán)節(jié)，都可以對其進(jìn)行緩存，如果我們不顯式指定，則當(dāng)前為 “public” 緩存。

與之相對的 “private”，則表示當(dāng)前響應(yīng)是針對單個用戶的，并非通用數(shù)據(jù)，因此不建議任何中間緩存對其進(jìn)行緩存。例如：瀏覽器就是一個比較私人的緩存源，它會緩存 “private” 的緩存，而 CDN 則不會。

三、***的緩存策略樹

前面提到，緩存的核心目的就是為了快，能讓下次使用的時候快速復(fù)用。所以在理想情況下，我們應(yīng)該將響應(yīng)數(shù)據(jù)盡可能多的緩存，盡可能的緩存足夠長的時間，并且為每個資源提供單獨(dú)的數(shù)據(jù)驗(yàn)證令牌，以便在時間過期之后快速校驗(yàn)。

但是任何事情都是要取其平衡點(diǎn)的，不存在什么***緩存策略，并非所有響應(yīng)資源都需要加緩存，這就需要根據(jù)業(yè)務(wù)場景來設(shè)定。

這里給出一個增加 HTTP 緩存的通用策略樹，你在對響應(yīng)增加緩存的時候，可以參考它來執(zhí)行。

正常情況下，我們針對不同的響應(yīng)屬性，會對它設(shè)置不同的緩存策略，下面根據(jù)場景，舉幾個例子。

3.1 用戶相關(guān)的數(shù)據(jù)

和單個用戶緊密相關(guān)的數(shù)據(jù)，通常我們是不建議使用緩存的，但是依然存在幾個等級。

1. 嚴(yán)格不使用緩存

Cache-Control:no-store

2. 允許客戶終端緩存，但是每次使用都需要確認(rèn)

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

3. 允許客戶終端短時間緩存

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

3.2 通用數(shù)據(jù)

一些通用響應(yīng)資源，更新的頻率非常的低，我們可以根據(jù)需要調(diào)整 max-age 的大小即可。

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

四、廢棄和更新緩存的響應(yīng)

緩存的策略，一旦確定并下發(fā)到客戶端，服務(wù)端就失去了對齊的控制權(quán)。也就是說，如果我們設(shè)定了 max-age，在此資源有效期超時之前，哪怕服務(wù)端的源資源已經(jīng)被替換修改，我們也沒有一個合適的時機(jī)去通知客戶端更新新的響應(yīng)數(shù)據(jù)。

那么有沒有什么好的策略去標(biāo)記資源廢棄？同時又能友好的利用緩存策略。

在互聯(lián)網(wǎng)上，所有服務(wù)上的資源，都有一個對應(yīng)的 URL（統(tǒng)一資源定位符），它可以明確說明如何從一個精確且固定的位置獲取資源。而 HTTP 緩存，也是依賴于 URL 的，注意 URL 是大小寫敏感的，同一個 URL 表示同一個請求響應(yīng)，依此來判斷緩存和后續(xù)緩存的復(fù)用。

所以我們是可以在 URL 上做文章的。

4.1 瀏覽器的廢棄策略

前面提到，瀏覽器是天然支持 HTTP 緩存的，對于瀏覽器來說，它所面對的就是一個個 HTML 頁面，頁面內(nèi)會包含一些 CSS、Image、JavaScript、JSON 資源和數(shù)據(jù)。

針對不同的資源和數(shù)據(jù)，我們可以在其 URL 上，增加數(shù)據(jù)令牌指紋，當(dāng)資源變動的時候，同時也去刷新改指紋令牌。

到這里就很好理解了：

HTML 頁面，使用 no-cache，強(qiáng)制每次都向源服務(wù)器確認(rèn)數(shù)據(jù)。

CSS文件通常變動的頻率非常低，所以可以允許中間層緩存，并且緩存時間為一年不過期。

JavaScript內(nèi)有業(yè)務(wù)邏輯，可以設(shè)定為只允許客戶終端緩存。

getUserInfo，是為個人用戶數(shù)據(jù)相關(guān)，這里推薦可緩存，但是需要每次向服務(wù)器重新確認(rèn)。

4.2 App 接口的緩存策略

在 App 中使用的接口，其實(shí)和網(wǎng)頁又不一樣，HTML 網(wǎng)頁的結(jié)構(gòu)類似一個樹形結(jié)構(gòu)，先通過獲取 .html 文件獲取其內(nèi)所有資源的表，然后依次根據(jù)緩存策略進(jìn)行訪問。

但是在 App 中，和服務(wù)器的交互都是通過數(shù)據(jù)接口來實(shí)現(xiàn)的，就不存在最開始獲取一個類似 HTML 文件這樣的樹形接口，每個接口都是一個個“孤島”，可以單獨(dú)存在。我們就無法提前知道某個接口的響應(yīng)數(shù)據(jù)已經(jīng)過期，同時也無法修改 URL 上攜帶的數(shù)據(jù)指紋令牌。

但是其實(shí)我們是可以通過 App 和設(shè)備的一些固有信息，作為 URL 的參數(shù)傳遞，以此來刷新數(shù)據(jù)。