介紹
內容交付網路 (CDN) 是現代 Web 效能的支柱。透過在全球分佈的邊緣節點快取內容，CDN 大大減少了延遲並卸載了來源伺服器的流量。然而，有效的快取並不僅僅是啟用 CDN 然後就忘記它的問題。在效能（高快取命中率和低延遲）與新鮮度（最小陳舊性和快速失效）之間取得適當的平衡需要深思熟慮的策略。
本指南探討了 CDN 快取基礎、快取控制指令、代理鍵、失效策略、重新驗證時過時、多層快取和監控，提供您現在可以應用的實用方法。
CDN 快取基礎知識
CDN 快取在邊緣節點儲存回應副本（存在積分或 POP），因此可以在不聯繫來源伺服器的情況下處理對相同資源的後續請求。 快取命中時，回應將在 5-50 毫秒內提供。當快取未命中時，請求將傳輸到來源，從而增加 100-500 毫秒的延遲。
CDN 快取各種內容：靜態資產（圖片、CSS、JavaScript、字型）、API 回應（JSON、GraphQL）、HTML 頁面和串流內容。快取層次結構通常遵循邊緣節點→地方快取→來源屏蔽→來源伺服器。
不同的 CDN 提供者有不同的快取理念和功能：
| 供應商 | 快取控制 | 代理鍵 | 起源之盾 | SWR 支援 |
|---|---|---|---|---|
| 雲耀 | 完整 | 快取標籤 | Argo 分層快取 | 是的 |
| 快點 | 完整 | 代理鍵 | 快速盾 | 是的 |
| 阿卡邁 | 完整 | 快取標籤 | 物業經理 | 是的 |
| 雲前 | 完整 | — | 起源之盾 | 是的 |
深度快取控制指令
Cache-Control 標頭是指示 CDN 和瀏覽器如何快取回應的主要機制。了解其指令對於微調行為至關重要。
max-age=<seconds>— 指定資源保持新鮮的時間。對於像app.a1b2c3.js這樣的版本化資產，請使用immutable指令設定max-age=31536000。s-maxage=<seconds>— 專門針對共用快取（CDN 和代理程式）覆寫max-age，讓您可以為 CDN 與瀏覽器設定不同的 TTL。public與private—public允許透過 CDN 和瀏覽器進行快取；private僅將快取限制在瀏覽器中，這對於特定於使用者的內容很重要。no-cache與no-store—no-cache允許緩存，但需要對每個請求重新驗證。no-store完全禁止快取。stale-while-revalidate=<seconds>— 立即提供過時的內容，同時在背景取得新內容。immutable— 告訴瀏覽器資源在其新鮮生命週期內永遠不會改變，從而消除了條件重新驗證。
以下是針對不同內容類型的實用秘訣：
# Versioned static asset — cache for a year, skip revalidation
Cache-Control: public, max-age=31536000, immutable
# API response — fresh for 1 minute, stale for 24 hours
Cache-Control: public, s-maxage=60, stale-while-revalidate=86400
# HTML page — always revalidate
Cache-Control: public, no-cache
代理鍵和定向失效
代理鍵（也稱為原始快取標籤）可讓您對相關資源進行分組，以實現目標快取失效。您無需清除單個 URL，而是按標籤進行清除——對於分組內容來說，這是一種更有效的方法。
實作很簡單：您的來源伺服器在回應中包含 Surrogate-Key 標頭（Fastly）或 Cache-Tag 標頭（Cloudflare、Akamai）。標籤可以表示內容類型 (articles)、特定實體 (article:1234)、集合 (section:tech) 或操作 (purge-all)。
# Response header tagging an article
Cache-Tag: articles, article:1234, section:tech
更新文章時，清除所有標記有該 ID 的快取回應：
# Fastly surrogate key purge
curl -X POST "https://api.fastly.com/service/{service}/purge/article:1234" \
-H "Fastly-Key: $API_KEY"
# Cloudflare tag purge
curl -X POST "https://api.cloudflare.com/client/v4/zones/{zone}/purge_cache" \
-H "Authorization: Bearer $API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"tags":["article:1234"]}'
標籤命名的最佳實踐：避免空格，保持大小寫一致，並將每個回應的標籤限制為少於 256 個，以保持在提供者的限制範圍內。
重新驗證時過時
Stale-While-Revalidate (SWR) 是一種快取控制擴展，它將快取未命中懲罰從同步等待轉變為背景刷新。當對過時資源的請求到達時，CDN 立即提供過時版本，同時非同步取得新版本。
Cache-Control: public, max-age=60, stale-while-revalidate=86400
這可以使資源保持新鮮 60 秒，並允許提供陳舊內容長達 24 小時，同時在後台重新驗證。用戶看到零等待時間——他們總是得到即時回應。 SWR 與 stale-if-error 配合得很好，當來源無法存取時，它可以將過時的內容作為後備。 在 CDN 儀表板中顯示陳舊與新鮮的比率，以適當調整 SWR 視窗。
多層快取和 Origin Shield
有效的快取在多個層上運作：
- 瀏覽器快取 — 第一道防線。正確的
Cache-Control標頭可防止重複請求。 - CDN 邊緣快取 — 分散式邊緣節點提供附近使用者快取內容。
- CDN 來源屏蔽 — 一種中間緩存，可整合來自邊緣節點的請求，從而顯著減少來源負載。
- 應用程式快取 — Redis 或 Memcached 位於資料庫結果和渲染片段的來源。
- 資料庫查詢快取 — 在資料庫層級快取頻繁的查詢結果。
起源之盾值得特別關注。當多個邊緣節點錯過同一資產的快取時，它們都會聯繫源頭——這是一個雷群問題。源屏蔽攔截這些請求，檢查自己的緩存，並且只聯繫來源一次。這可以減少 80-95% 的原始流量。透過 Cloudflare Argo 分層快取、Fastly Shield 或 CloudFront Origin Shield 對其進行配置。
監控與調試
為了確保您的快取策略有效，請監控以下指標：
- 快取命中率 — 在 Cloudflare Analytics、Fastly Observatory 和 CloudFront 報告中提供。 80%以上為好； 95%以上為優秀。
- CDN 回應標頭 —
CF-Cache-Status(Cloudflare)、X-Cache(Fastly、CloudFront) 和Age告訴您是否從快取提供回應以及快取了多久。 - 快取缺失分析 — 確定資產缺失的原因：首次請求、逐出、TTL 過期或明確繞過。
使用 curl 偵錯快取標頭：
curl -I https://example.com/assets/app.js -H "Accept-Encoding: gzip"
# Look for: CF-Cache-Status: HIT, Age: 12345
結論
有效的 CDN 快取結合了適當的 TTL、用於目標失效的代理鍵、用於零等待刷新的 stale-while-revalidate 以及具有恢復能力的原始屏蔽的多層快取。最有影響力的指令是 stale-while-revalidate — 它將性能與新鮮度的權衡從妥協轉變為兩者兼而有之的主張。將其與精心設計的代理鍵系統配對，投資 originshield，並監控緩存命中率以不斷提高。您的用戶將感謝您提供更快的載入時間，而您的來源伺服器將感謝您減少負載。