掌握 HTTP 緩存——從請求到響應過程的一切（上）

01-30

作者：James Sinclair
編譯：鬍子大哈，Web前端路上的一隻大哈。
知乎專欄：前端大哈，會討論關於前端的一切。歡迎關注我的知乎專欄，定期發布優質前端技術文章。
本文簡介：本文由淺入深地介紹了HTTP響應頭中哪些標籤和緩存有關，以及CDN緩存是如何起作用的。
翻譯原文：http://huziketang.com/blog/posts/detail?postId=58b77935204d50674934c3ad

英文原文：Mastering HTTP Caching - from request to response and everything

轉載請註明出處，保留原文鏈接以及作者信息

CDN類的網站曾經一度雄踞 Alexa 域名排行的前 100。以前一些小網站不需要使用 CDN 或者根本負擔不起其價格，不過這一現象近幾年發生了很大的變化，CDN 市場上出現了很多按次付費，非公司性的提供商，這使得 CDN 變成人人都能負擔的起的一種服務了。本文講述的就是如何使用這種簡單易用的緩存服務。

使用內容分發網路（ CDN ）你需要先正確地認識 HTTP 響應頭：和 HTTP 響應頭中的哪些標籤相關？它們是怎麼起作用的？如何使用它們？文章中我會回答這些問題。

本文講的並不會像教科書那麼精確，實際上在某些情況下，為了敘述的清晰、簡潔，我會按自己的理解簡化某些問題，文章中會通過一些實際的例子來介紹緩存理論。在這篇文章的基礎上，還會寫一些文章來介紹對於某些指定的 CMS 或框架如何使用 CDN 來作為緩存層。

為什麼使用 CDN？

CDN 是一個全球分散式網路，它把網站內容更快地傳遞給全球範圍內的一個具體位置，而往往這個具體的位置離實際的內容伺服器距離很遠。舉個例子，你的網站主機在愛爾蘭，而你的用戶則在澳大利亞訪問。這時當你的用戶訪問你的網站的時候，延遲會很大，把你的（靜態）數據用 CDN 放到澳大利亞則會很大程度上提高用戶訪問網站的體驗。

然而 CDN 的使用並不局限於此。其實 CDN 可以理解成一個普通緩存，如代理緩存（邊緣緩存）。即便你並不關心用戶的具體地理位置，你也應該考慮使用 CDN 的代理緩存來提高你的用戶體驗。

為什麼使用代理緩存？

簡而言之，代理緩存會緩存你網站一些頁面，通過緩存來傳輸「靜態」內容非常快。一個簡單的例子，假設你有一個帶有開始頁面的博客，這裡面列出了所有近期的博客列表。完成這一過程，PHP 腳本要從資料庫中獲取到最近的文章實體，並且將它們轉換成 HTML 結果頁並返回給用戶。因此，對於一次請求（訪問）包含了：一次 PHP 執行 + 一組資料庫查詢。對於 1000 次請求（訪問）包含了：1000 次 PHP 執行 + 1000 組資料庫查詢。每一次 PHP 執行都要進行 CPU、內存和 I/O 操作，對於資料庫操作也是同樣。

請求的需求量和訪問用戶的多少呈線性正比關係。聽起來怎麼樣？不怎麼樣，因為這個線性關係是有最大限度的：磁碟最大只能提供一定程度的 I/O，CPU 和內存也都不是無限的。這樣下去到了某個點，也就是說某個資源到了瓶頸的時候，就出現問題了：你的網站會訪問的非常慢，甚至會出現所有人都不能訪問的情況。其實這時其他資源並沒有被全部打滿。誠然，這時你可以擴展你的硬體規模來突破這一瓶頸，但是這將使工程變得很複雜，成本也更高。實際上還有更簡單、更便宜的解決方法。

在中間加一層代理緩存，會減少資源對你的限制。拿前面的例子來講，使用代理緩存只有第一次請求需要執行 PHP 腳本、查詢資料庫和生成 HTML 結果頁。所有後面過來的請求都會從這個緩存中取內容，讀取緩存幾乎和直接讀取內存一樣快。這意味著，上面的線性規模瓶頸的問題解決了！100 個用戶或者1000 個用戶都沒關係，依然只有 1 次 PHP 執行、1 次資料庫查詢和 1 次的結果頁生成。

CDN != CDN

CDN 的類型也各有不同。網站管理者可能會好奇數據是怎麼存儲的？存放在哪？以及數據是如何分布在 CDN 上的？是如何分發的呢？本文不是寫給網站管理者的而是寫給開發者的，所以在這我只能告訴你有「經典 CDN」和「對等 CDN」，後者是現在主流採用的方法。

對於開發者，相比於把數據拿到 CDN 以後做什麼來說，會對如何把數據放到 CDN 中更感興趣。說起來，有 push CDN 和 pull CDN 兩種。顧名思義，「push CDN」表示你要給 CDN 提供內容；「pull CDN」表示如何從 CDN 取內容。

本文將主要介紹 pull CDN，因為在很多情況下 pull CDN 更加簡單易用，不需要費多大事就能集成到現有的網站中。

pull CDN 是如何起作用的？

我們來做個例子，假設你有一個可訪問的網站，URL 是 https://www.foobar.tld。在這樣的場景下，域名http://www.foobar.tld 會被放到 pull CDN 伺服器中，而不是你的網站伺服器中。CDN 作為你網站伺服器的一個代理。

還有一個不被公開的域名指向實際的網站伺服器。在這個例子中假設它是 direct.foobar.tld，實際網站伺服器叫做源。

這個 CDN 將會接受所有的請求。如果它的緩存中有結果的話將會直接返回給用戶，否則會將這個請求託管給你實際的網站伺服器，然後把返回的結果緩存起來為以後的請求做儲備，同時將結果返回給用戶。

最簡單的 pull CDN 運行的過程如下：

獲取一個頁面的請求，這個頁面：http://www.foobar.tld/some/page
把 some/page 當做緩存 key 檢查緩存中是否存在
在緩存中則直接從緩存中返回結果給用戶
不在緩存則請求 http://direct.foobar.tld/some/page，把返回的結果以 some/page 作為 key 寫入緩存，並返回結果給用戶

靜態內容 VS 動態內容

上面的這一過程對於完全靜態的內容完全適用。靜態內容指的是如果用戶訪問同一個 URL 地址，返回的所有數據都是一樣的。比如 CSS 文件就有這樣的特點，http://www.foobar.tld/public/css/main.css 這個文件是一個普通文件，對於所有訪問網站的用戶都是一樣的，那麼它就特別適合用緩存存起來。

和靜態文件相對的是動態文件。內容在運行時才能確定，這種情況也是非常常見的。比如多語言問題，需要根據瀏覽器語言來返回內容。還有一些和「user session」相關的內容，比如當用戶登陸了以後，就要把「登陸」按鈕換成「退出」按鈕，你肯定不希望這個被緩存。這些高度活躍的內容（如每小時或者更短時間更新的頁面）不能被緩存，或者說不能在緩存中停留時間過長。

這就是緩存有意思的地方，理解和實現它並不難。

緩存頭

絕大多數的 pull CDN 採用以「每頁」緩存形式解決動態內容的問題。為了達到這樣的效果，一個簡單的方法是 HTPP 響應緩存頭。

首先對於緩存頭你需要知道有「舊版本」和「新版本」兩種，就是說它並不是一開始就設計成當前所使用的這個版本的，也有一個逐漸演變的過程。新版本指的是 HTTP/1.1，而舊版本指的是 HTTP/1.0。它有特別多的可選選項，每個人對這個問題都很頭疼。我認為這是大家不願意使用緩存頭的最重要的原因。

言歸正傳，我們只關注 ETag 和 Cache-Control 這兩個標籤就足以了。大多數 CDN 還支持舊版本（Expires，Pragma 和 Age），不過這些只作為向後兼容來使用。

ETag 頭

我們從最簡單的開始 ETag：它是文檔版本的標識符。通常是內容的 MD5 值，不過它也可以包含其他內容，代表的是文檔的版本/日期，如： 1.0 或者 2017-02-27。這裡注意一點是，它必須用雙引號括起來，如：ETag: "d3b07384d113edec49eaa6238ad5ff00"。

二次驗證

現在來考慮 ETag 的實際應用：二次驗證。我們暫時不考慮前面代理+源的架構模式，只考慮簡單的客戶端-伺服器模式。如下圖：

假設客戶端請求了 http://www.foobar.tld/hello.txt，接著服務端返回了如下的響應內容：

# REQUESTnGET /hello.txt HTTP/1.1nHost: www.foobar.tldnn# RESPONSEnHTTP/1.1 200 OKnDate: Sun, 05 Feb 2017 12:34:56 UTCnServer: ApachenLast-Modified: Sun, 05 Feb 2017 10:34:56 UTCnETag: "8a75d48aaf3e72648a4e3747b713d730"nContent-Length: 8nContent-Type: text/plain; charset=UTF-8nnthe bodyn

在響應裡面，有兩個有意思的頭標識：一個是 ETag，內容的 MD5值，一個是 Last-Modified，這是 hello.txt 文件最後一次被修改的時間。

這裡就是二次驗證起作用的地方：當客戶端在很短的時間內再次訪問上面的 URL，客戶端瀏覽器會使用 If-* 請求頭。如 If-None-Match 檢查 ETag 的內容是否有改變。也就是說，如果 ETag 發生變化，客戶端接收到的一個完整的新響應；如果 ETag 沒變化，客戶端接收到的是一個表明內容沒變化的標識。

GET /hello.txt HTTP/1.1nIf-None-Match: "8a75d48aaf3e72648a4e3747b713d730"nHost: www.foobar.tldn

如果 ETag 沒有改變，那麼服務端將會返回：

HTTP/1.1 304 Not ModifiednDate: Sun, 05 Feb 2017 12:34:57 UTCnServer: ApachenLast-Modified: Sun, 05 Feb 2017 10:34:56 UTCnETag: "8a75d48aaf3e72648a4e3747b713d730"nContent-Length: 8nContent-Type: text/plain; charset=UTF-8n

正如上面所展示的，這次伺服器的響應裡面不是 200 ok，而是304 Not Modified，這就是說它略過包體部分，讓客戶端直接去自己的緩存里拿數據。在這個例子中，包體內容是 the body，比較小，效果不明顯。可是想像一下如果是很大的內容呢，或者是很複雜的動態生成內容呢，價值就很大了。

作為一個開發者，你可能會想：「並沒有那麼好用嘛，我還不得不掌握 IF- 類的頭標識，比以前更費事了」。

別急，這只是介紹了共享緩存，也就是代理緩存的由來，我們看原始的架構：<客戶端-代理-源端>，代理根據自己的緩存返回給客戶端 304 Not Modified，接下來的章節詳解介紹，介紹之前我要先講一下 Last-Modfied 頭。

在處理上面那個 hello.txt 靜態文件的例子時，客戶端還可以使用 If-Not-Modified-Since: Sun, 05 Feb 2017 10:34:56 UTC 來達到同樣的效果（返回 304 響應）。這對於靜態文件來說也很好用，因為響應頭中的 Last-Modified 標識是根據伺服器磁碟上的「更改時間戳」自動生成的。然而，「更改時間戳」對於動態文件通常沒什麼用，因為動態生成文件頻繁更新，時間戳很難確定。我們都知道，你最想緩存起來的是內容，生成內容的代價是最大的，所以 ETag 頭是更好的選擇。

Cache-Control頭

Cache-Control 頭相對來講難一些。兩個原因：第一，Cache-Control 既可以用於請求頭，也可以用於響應頭。本文中著重討論響應頭，因為這是開發者所必須要掌握的。第二，它控制著兩個緩存：本地緩存（又稱私有緩存）和共享緩存。

本地緩存，是指在客戶端本地機器中的緩存。站在開發者的角度，它並不完全受你的控制，通常瀏覽器會自己決定是否把某些內容放到緩存中，這意味著：不要依賴於本地緩存。用戶也可能在關閉瀏覽器的時候清理所有緩存，而你並不知道有這樣的操作。除非你監測到了某個用戶的流量不斷上漲，導致緩存內容迅速失效，這時候你才會意識到。

共享緩存，也就是本文所介紹的：處於客戶端和伺服器之間的緩存。即 CDN。你對共享緩存擁有絕對的控制，應該好好地利用它。

現在我們來用一些代碼作為示例深入學習一下。

Cache-Control: public max-age=3600
Cache-Control: private immutable
Cache-Control: no-cache
Cache-Control: public max-age=3600 s-maxage=7200
Cache-Control: public max-age=3600 proxy-revalidate

乍一看這些代碼很令人困惑，但是不要擔心，它並沒有那麼難，我來一點點介紹。首先你要知道 Cache-Control 有三種屬性：緩衝能力、過期時間和二次驗證。

首先是緩衝能力，它關注的是緩存到什麼地方，和是否應該被緩存。他的幾個重要的屬性是：

private：表示它只應該存在本地緩存；
public：表示它既可以存在共享緩存，也可以被存在本地緩存；
no-cache：表示不論是本地緩存還是共享緩存，在使用它以前必須用緩存里的值來重新驗證；
no-store：表示不允許被緩存。

第二個是過期時間，很顯然它關注的是內容可以被緩存多久。它的幾個重要的屬性是：

max-age=<seconds>：設置緩存時間，設置單位為秒。本地緩存和共享緩存都可以；
s-maxage=<seconds>：覆蓋 max-age 屬性。只在共享緩存中起作用。

最後一個是二次驗證，表示精細控制。它的幾個重要屬性是：

immutable：表示文檔是不能更改的。
must-revalidate：表示客戶端（瀏覽器）必須檢查代理伺服器上是否存在，即使它已經本地緩存了也要檢查。
proxy-revalidata：表示共享緩存（CDN）必須要檢查源是否存在，即使已經有緩存。

通過上面的具體解釋，現在再來描述上面 Cache-Control 的那段代碼所表達的意思就好理解多了：

本地緩存和 CDN 緩存均緩存 1 小時；
不能緩存在 CDN，只能緩存在本地。並且一旦被緩存了，則不能被更新；
不能緩存。如果一定要緩存的話，確保對其進行了二次驗證；
本地緩存 1 小時，CDN 上緩存 2 小時；
本地和 CDN 均緩存 1 小時。但是如果 CDN 收到請求，則儘管已經緩存了 1 小時，還是要檢查源中文檔是否已經被改變。

實例

理論會很單調乏味，現在用短的實例來演示如何自動注入 ETag 和 Cache-Control 頭。例子是一個 Apache 的 .htaccess 文件，但是我希望你能夠領會要領，並且根據你自己的實際情況，應用到你自己的 Web 應用中。

# 為所有圖片設置 ETag，以及緩存時間為 1 天n<FilesMatch ".(gif|flv|jpg|jpeg|png|gif|swf)$">n FileETag -INode MTime Sizen Header set Cache-Control "max-age=86400 public"n</FilesMatch>nn# 為所有的 CSS 文件、JS 文件設置 ETag，以及緩存時間為 2 小時，同時保證進行了二次驗證n<FilesMatch ".(js|css)$">n FileETag -INode MTime Sizen Header set Cache-Control "max-age=7200 public must-revalidate"n Header unset Last-Modifiedn</FilesMatch>n

上面例子，是一個對 URL：http://www.foobar.tld/baz.jpg 的響應。包含了一個 ETag 頭，由更改時間和文件大小所構成，還有 Cache-Control 頭來設定緩存 1 天的時間。見下面的請求和響應：

# REQUESTnGET /baz.jpg HTTP/1.1nHost: www.foobar.tldnn# RESPONSEnHTTP/1.1 200 OKnDate: Tue, 07 Feb 2017 15:01:20 GMTnLast-Modified: Tue, 07 Feb 2017 15:01:15 GMTnETag: "4-547f20501b9e9"nContent-Length: 123nCache-Control: max-age=86400 publicnContent-Type: image/jpegn

對於 URL： http://www.foobar.tld/dist/css/styles.css 的響應同樣也包含了 ETag 頭。由更改時間、文件大小和限定了 2 小時的 Cache-Control 構成。Last-Modfied 頭也刪除掉以確保只有 ETag 用來做二次驗證。見下面的請求和響應：

# REQUESTnGET /styles.css HTTP/1.1nHost: www.foobar.tldnn# RESPONSEnHTTP/1.1 200 OKnDate: Tue, 07 Feb 2017 15:00:00 GMTnServer: ApachenETag: "20-547f1fbe02409"nContent-Length: 32nCache-Control: max-age=7200 public must-revalidatenContent-Type: text/cssn

小結

本文中我們介紹了：

為什麼要使用 CDN，以及 CDN 是如何起作用的。
靜態內容和動態內容分別是什麼情況。
HTTP 頭是如何解決緩存問題的。

那麼想像一下這樣的場景，假設你有個網站，需要保存用戶的登錄狀態，而針對不同狀態的用戶需要不同的顯示。通常情況下，我們是用 Cookie 來解決用戶特性的問題。這時候問題就來了，如果 Cookie 也在 CDN 中緩存，那麼將會導致所有用戶的 Cookie 都一樣，這不是我們想要看到的。那麼怎麼解決呢？我們會在《掌握 HTTP 緩存——從請求到響應過程的一切（下）》中詳細介紹。

歡迎大家關注我的前端大哈 - 知乎專欄，定期發布高質量前端文章。

點擊《掌握 HTTP 緩存——從請求到響應過程的一切（上）》查看原文。