來杯一點點 - HTTP 緩存

文章首發於 來杯一點點 - HTTP 緩存。

在閱讀該文章以前，建議對 HTTP 有所瞭解，能夠看HTTP 入門體檢，會對如下的內容有所幫助。

介紹

重用已獲取的資源可以有效的提高網站與應用的性能。Web 緩存可以減小延遲與網絡阻塞，進而減小顯示某個資源所用的時間。藉助 HTTP 緩存，Web 站點變得更具備響應性。

基本流程

1. 瀏覽器發起請求(攜帶 Cache-Control )，會先去本地緩存看看是否有緩存而且命中，假若有就直接返回緩存資源，反之則就轉向代理服務器；
2. 代理服務器去查找相關的緩存設置，如s-maxage，以及該資源是否有緩存，一樣的會去檢查是否命中緩存資源，假若有則會返回至本地緩存，反之則到達源服務器；
3. 到達源服務器後，源服務器會返回資源新文件，而後一步步返回。

這大概就是緩存最粗糙的一個基本流程，接下來咱們來一步步的淺析緩存的原理。

Cache-Control

在 網絡協議入門體檢 中咱們已經列舉了關於 Cache-Control 的緩存指令，因爲緩存的篇幅有點多，就不在堆積成一篇來說解。

緩存請求指令

常見緩存請求指令	說明
no-cache	強制向服務器再次驗證
no-store	不緩存請求或響應的任何內容
max-age=(秒)	響應的最大 Age 值
max-stale=[秒]	接收已過時的響應
min-fresh=(秒)	指望在指定時間內的響應仍有效

常見緩存響應指令	說明
public	可向任意方提供響應的緩存
private	僅向特定用戶返回響應
no-cache	緩存前必須先確認其有效性
no-store	不緩存請求或響應的任何內容
max-age=(秒)	響應的最大 Age 值
s-maxage=(秒)	公共緩存服務器響應的最大 Age 值
must-revalidate	可緩存但必須再向源服務器進行確認

Cache-Control 緩存特性

咱們一開始看到表格估計會嚇一跳，僅僅只是一個 Cache-Control 就幾乎有那麼多指令。但實際上咱們把它分爲特性模塊來看，咱們天然而然就會清晰不少。

可緩存性

• public：就是該 HTTP 請求所請求的內容，不管是通過代理服務器仍是客戶端，均可以對該請求進行緩存操做；
• private：只有發起請求的瀏覽器才能夠進行緩存，而代理服務器則不能夠；
• no-cache：這裏的意思是能夠緩存，可是在緩存以前無論過沒過時，都須要向源服務器進行資源有效性校驗；

過時性

• max-age：該緩存何時到期；
• s-maxage：在代理服務器中，若是咱們同時設置了 max-age 以及 s-maxage，那麼代理服務器會讀取 s-maxage，由於該指令是專門爲代理服務器而存在的；

從新驗證

• must-revalidate：假如還沒到過時時間，那麼可使用緩存資源；反之就必須到源服務器進行有效檢驗；
• proxy-revalidate：同 must-revalidate，只是 proxy-revalidate 用在緩存服務器；

其餘

• no-store：看起來跟 no-cache 同樣，實際上 no-store 則是表示完全的不可使用緩存，也就是說每次請求都是最新的資源；
• no-transform：主要是針對代理服務器的，有些代理服務器會將源資源進行一些二次處理，例如壓縮，轉格式等操做，no-transform 指令是指明瞭代理服務器不容許對資源進行二次處理；
• …：剩餘的指令表示其餘的幾乎不多見到，在這裏就不在多說，以後有遇到場景再回來補充。

Cache-Control 實戰模擬

咱們開始來經過實戰模擬一下有關 Cache-Control 的指令對緩存的做用。Koa2，啓動。

const Koa = require('koa');
const fs = require('fs');
const path = require('path');
const util = require('util');

const readFile = util.promisify(fs.readFile);
const app = new Koa();

app.use(async ctx => {
  const url = ctx.request.url;

  if (url.includes('.jpg')) {
    const img = await readFile(path.resolve(__dirname, `.${url}`));
    ctx.body = img;
  } else {
    const html = await readFile(path.resolve(__dirname, `./index.html`));
    ctx.status = 200;
    ctx.set('Content-Type', 'text/html');
    ctx.res.end(html);
  }
});

app.listen(3000);
複製代碼

執行完畢，咱們能夠看到不管咱們怎麼刷新頁面，圖片的 Size 依舊是那個 Size，不增不減，說明並無緩存。

咱們在輸出圖片以前，設置緩存指令max-age=5，表示緩存時間5s。這樣咱們就能夠很好的觀察它的開始緩存以及結束緩存以後的表現。記得關閉 Chrome 瀏覽器的 Disable Cache。

ctx.set('Cache-Control', 'max-age=5');
複製代碼

對應的響應報文以下，能夠看到咱們已經成功的設置了 Cache-Control 報文指令。

在下圖能夠看到，中間的5s都是內存緩存讀取的資源，耗時0ms，先後分別是開始拉取資源以及緩存時間過時。

此時，假如咱們在緩存期間修改了資源內容，可是路徑名不變，那麼讀取的資源是新資源呢仍是緩存資源呢？答案是緩存資源，由於一旦設置了 Cache-Control 而且在客戶端緩存了，那麼再起請求假如還在緩存期間，那麼就不會再向服務器發送請求了。

Expires

除了 Cache-Control 能夠控制資源的緩存狀態以外，還有Expires，它是 HTTP 1.0 的產物，可是仍是有不少地方會有到它。它跟 Cache-Control 中的 max-age 有什麼區別呢？

• 表達方式：Expires 是絕對時間，如 Expires: Tue Jul 09 2019 23:13:28 GMT+0800，而 max-age 是相對時間，如max-age=3600；
• 協議版本：Expires 是 HTTP 1.0 版本的首部字段，而 max-age 是 HTTP 1.1 版本及其以後的首部字段；
• 優先級：當請求協議版本爲 HTTP 1.0 時，同時存在 Expires 和 max-age 會無視 max-age，而當請求協議版本爲 HTTP 1.1 則會優先處理 max-age 指令；

除此以外，它們的使用方法時同樣的，所以咱們就再也不實戰演示了，它們都是用來校驗強緩存的標識。

緩存校驗 Last-Modified & ETag

Last-Modified

顧名思義，上次修改時間。主要配合 If-Modified-Since 或者 If-Unmodified-Sice。

基本流程：

1. 首次請求資源，服務器返回資源時帶上實體首部字段Last-Modified；
2. 當咱們再次請求該資源時，瀏覽器會自動在請求頭帶上首部字段If-Modified-Since，此時的 If-Modified-Since 等於 Last-Modified ；
3. 服務器接收到請求後，會根據 If-Modified-Since 配合 Last-Modified來判斷資源在該日期以後是否發生過變化；
4. 若是發生修改了，則返回新的資源並返回新的 Last-Modified，反之則返回狀態碼304 Not Modified，這個過程稱爲協商緩存。

ETag

相對於 Last-Modified，ETag 是一個更加嚴格的驗證，它主要是經過數字簽名表示資源的惟一性，但當該資源發生修改，那麼該簽名也會隨之變化，可是不管如何都會保證它的惟一性。因此根據它的惟一性，就能夠 If-Match 或者 If-Non-Match 知道資源有沒有發生修改。

基礎流程： 同 Last-Modified，只是把 Last-Modified 換成 ETag， If-Modified-Since 換成 If-Match 。可是假如 Last-Modified 以及 ETag 同時存在，則後者ETag 的優先級比較高。

強緩存 & 協商緩存

在進行最後一個實戰模擬以前，要先說下這兩個十分重要的概念：強緩存以及協商緩存。

強緩存

簡單粗暴來說，就是**客戶端知道資源過時時間後，由客戶端來決定要不要緩存。**那麼怎麼知道資源的過時時間呢？由誰來決定它們的過時時間呢？就是由咱們上文提到的 Expires 以及 Cache-Control: max-age。

協商緩存

跟強緩存相反，是由服務器來決定客戶端要不要使用緩存。在有 ETag 以及 Last-Modified 響應首部字段的狀況下，客戶端會向服務器發起資源的緩存校驗，而後服務器會告知客戶端是使用緩存(304)仍是返回一個全新的資源，表面上看都是會發起一個請求，可是響應的時候則是否是一個完整的響應則看是否須要緩存。

還記得Cache-Control的指令no-cache和no-store嗎？這時候應該就清楚了二者的區別了。no-cache 就是直接跳過強緩存進入協商緩存。而 no-store 則是不緩存，效果等同於 Chrome 瀏覽器的 Disable Cache，仔細觀察，你會發現請求首部字段是不會攜帶關於緩存的任何首部字段。

Last-Modified 實戰模擬

咱們在上面 max-age: 5 的基礎上添加 no-cache，能夠看到咱們不管如何刷新，都是一個新的資源(咱們還沒設置協商緩存的相關字段)。

在這裏咱們只作 Last-Modified 的實戰模擬，由於 ETag 同理。代碼較上面沒多大變化，我只貼變化的代碼。

const readStat = util.promisify(fs.stat);
// ... 沒變化
const imageUrl = path.resolve(__dirname, `.${url}`);
const imageStat = await readStat(imageUrl);
const lastModified = imageStat.mtime.toUTCString();
const ifModifiedSince = ctx.headers['if-modified-since'];

ctx.set('Cache-Control', 'max-age=5, no-cache');
ctx.set('Last-Modified', lastModified);
    
if (ifModifiedSince === lastModified) {
  ctx.status = 304;
  ctx.res.end();
} else {
  const imageBuffer = await readFile(imageUrl);
  ctx.body = imageBuffer;
}
複製代碼

能夠看到，第一次請求的時候，服務器攜帶響應首部字段Last-Modified，這時候的返回來的報文主體大小: 104KB。以後第二次請求時瀏覽器自動攜帶請求首部字段If-Modified-Since，響應返回來的報文主體大小: 172B

注：

koa2 有本身的一套處理協商緩存的屬性，即request.fresh，有興趣自行了解。

流程圖

總結

我想，這下子總算知道爲何有時候 Chrome 瀏覽器會展現disk cache/memory cache了吧，它跟304 Not Modified 一樣都是被緩存的意思，這是方式不同。因而可知，合理的使用緩存是多麼的重要，它可使咱們減小無所謂的請求、避免資源文件的重複傳輸、減小對源服務器的資源佔用等等好處，但也不能濫用。

彩蛋

咱們熟悉了瀏覽器的調試方式，可是不一樣的操做都是有不同的效果。注意到上圖的①、②沒有？它是這個彩蛋準備的。

• 輸入地址回車：流程從①開始走起；
• 刷新：Cmd+R (Mac) / Ctrl + R (Window) 。流程從 ② 走起，也就是跳過強緩存校驗直接到協商緩存。注意，從新輸入當前地址回車也是走這一步，這說明只有第一次輸入地址回車纔是從①開始；
• 強制刷新：Cmd + Shift + R (Mac) / Ctrl + Shift + R (Window)。不帶條件直接訪問服務器的文件；
• BF Cache (Backward/Forward Cache)：指的是瀏覽器前進/後退。在這裏既不是①也不是②。它是使用了更強的緩存策略，表現爲DOM，window，甚至JavaScript對象被緩存，以及同步XHR被緩存。並且這是瀏覽器本身的行爲，與HTTP無關，所以在不一樣瀏覽器有不一樣的表現，這就是爲何有時候 setTimeout 計時不可靠的緣由了。

參考

• 完全弄懂HTTP緩存機制及原理
• 說說瀏覽器端緩存的那點事兒
• HTTP緩存控制小結
• 瀏覽器前進/後退緩存（BF Cache）