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

前言

應該還是有不少人對這塊了解甚少，有興趣的在看看。今日早讀文章由來自首個前端Online Judge ScriptOJ@鬍子大哈翻譯授權分享。

正文從這開始～

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 作為你網站伺服器的一個代理。

這個 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 的實際應用：二次驗證。我們暫時不考慮前面代理+源的架構模式，只考慮簡單的客戶端-伺服器模式。如下圖：

# REQUEST

GET/hello.txt HTTP/1.1

Host:www.foobar.tld

# RESPONSE

HTTP/1.1200OK

Date:Sun,05Feb201712:34:56UTC

Server:Apache

Last-Modified:Sun,05Feb201710:34:56UTC

ETag:"8a75d48aaf3e72648a4e3747b713d730"

Content-Length:8

Content-Type:text/plain;charset=UTF-8

the body

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

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

GET/hello.txt HTTP/1.1

If-None-Match:"8a75d48aaf3e72648a4e3747b713d730"

Host:www.foobar.tld

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

HTTP/1.1304Not Modified

Date:Sun,05Feb201712:34:57UTC

Server:Apache

Last-Modified:Sun,05Feb201710:34:56UTC

ETag:"8a75d48aaf3e72648a4e3747b713d730"

Content-Length:8

Content-Type:text/plain;charset=UTF-8

正如上面所展示的，這次伺服器的響應裡面不是 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:publicmax-age=3600

Cache-Control:privateimmutable

Cache-Control:no-cache

Cache-Control:publicmax-age=3600s-maxage=7200

Cache-Control:publicmax-age=3600proxy-revalidate

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

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

private：表示它只應該存在本地緩存；

public：表示它既可以存在共享緩存，也可以被存在本地緩存；

no-cache：表示不論是本地緩存還是共享緩存，在使用它以前必須用緩存里的值來重新驗證；

no-store：表示不允許被緩存。

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

max-age=：設置緩存時間，設置單位為秒。本地緩存和共享緩存都可以；

s-maxage=：覆蓋 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天

FileETag-INode MTime Size

HeadersetCache-Control"max-age=86400 public"

# 為所有的 CSS 文件、JS 文件設置 ETag，以及緩存時間為2小時，同時保證進行了二次驗證

FileETag-INode MTime Size

HeadersetCache-Control"max-age=7200 public must-revalidate"

Header unset Last-Modified

# REQUEST

GET/baz.jpg HTTP/1.1

Host:www.foobar.tld

# RESPONSE

HTTP/1.1200OK

Date:Tue,07Feb201715:01:20GMT

Last-Modified:Tue,07Feb201715:01:15GMT

ETag:"4-547f20501b9e9"

Content-Length:123

Cache-Control:max-age=86400public

Content-Type:image/jpeg

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

# REQUEST

GET/styles.css HTTP/1.1

Host:www.foobar.tld

# RESPONSE

HTTP/1.1200OK

Date:Tue,07Feb201715:00:00GMT

Server:Apache

ETag:"20-547f1fbe02409"

Content-Length:32

Cache-Control:max-age=7200publicmust-revalidate

Content-Type:text/css

小結

本文中我們介紹了：

為什麼要使用 CDN，以及 CDN 是如何起作用的。

靜態內容和動態內容分別是什麼情況。

HTTP 頭是如何解決緩存問題的。

那麼想像一下這樣的場景，假設你有個網站，需要保存用戶的登錄狀態，而針對不同狀態的用戶需要不同的顯示。通常情況下，我們是用 Cookie 來解決用戶特性的問題。這時候問題就來了，如果 Cookie 也在 CDN 中緩存，那麼將會導致所有用戶的 Cookie 都一樣，這不是我們想要看到的。

關於本文

譯者：@鬍子大哈

作者：@James Sinclair

原文：https://blog.fortrabbit.com/mastering-http-caching

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！