CDN 是一群地理分散的共用 HTTP 快取。本篇用「一個請求在邊緣節點上發生的事」貫穿：先算 Cache Key，再決定 HIT／MISS／回源，最後才談過期、失效與誰去打 origin。

應用層快取（Redis、本地 LRU）服務的是你自己的服務：key 是你定的，失效是你 DEL 的。CDN 服務的是HTTP 表徵：它站在瀏覽器與 origin 之間，讀 Cache-Control、算一把從 URL 與選定標頭組出來的 key，把同一份回應賣給同一個 PoP 上的下一個陌生人。兩者都能降延遲、都能打穿 origin，但契約完全不同。

一個 GET 落到邊緣之後，生命週期幾乎總是這四步。後面每一章對應其中一步，不跳著講產品功能清單。

flowchart LR
    C["Client GET"] --> P["就近 PoP"]
    P --> K["算 Cache Key"]
    K --> L["查快取"]
    L -->|HIT| C
    L -->|MISS| O["回源 / Shield"]
    O --> C
  

看「查快取」分出的兩條邊：HIT 那條直接折返 Client，origin 完全不知道這次請求；只有 MISS 那條才往右走到回源或 Shield，而且回來之後還要寫進邊緣的 store。

命中率幾乎總是先被 key 設計殺死，而不是被 TTL 殺死。進 key 的每一個位元組，都在複製一份快取物件。

邊緣看到的不是「/hero.jpg 這張圖」，而是一把由 URL 與選定請求欄位組出來的字串。同一張圖，十種 query 排列就可能變成十份物件——每一份都 miss 一次、佔一份記憶體、過期一次。

正規化的工作是刪掉不改變表徵的維度，留下真正會讓回應不同的維度。排序 query、去掉空值、主機名小寫，是免費的；難的是決定哪些欄位「算內容」。

1 · Query 參數：內容 vs 追蹤

左右兩欄的判準只有一條：這個參數會不會改變回應的 bytes。會改變的留下（左欄），只改變觀測的丟掉（右欄）。

2 · Header 與 Cookie

共用快取預設不該把 Cookie 放進 key。Session cookie 幾乎每人一把，key 基數 ≈ 活躍用戶數，命中率趨近於 0，還有把 A 的私人頁面賣給 B 的風險——後者該用 Cache-Control: private／no-store 直接禁止共用，而不是「用 cookie 當 key 假裝隔離」。

若產品真的需要「登入／未登入兩份 HTML」，正確做法是把身分正規化成一個低基數維度（例如 logged_in=0|1），而不是整段 Cookie 原樣進 key。

3 · Vary 的帳單

Vary 告訴共用快取：「這份回應還依哪些請求標頭而變」。它不是註解，是 key 的乘法器。

Vary 每加一個高基數標頭，命中率就按那個基數相除。面試被問「為什麼上了 CDN 命中率只有 20%」，先把 Cache Key 攤開，十次有八次答案在這裡。

key 算完之後，邊緣只有三種工作：把已有的表徵賣掉、去 origin 取一份，或掛在別人正在取的那一趟上。

使用者被導到哪個 PoP，只在這一步有意義：快取是地理分片的。東京 HIT 幫不到倫敦 MISS。Anycast 或 Geo-DNS 把請求送到「近」的節點，於是熱門物件在每個 PoP 各自暖機一份；冷門物件則在很多 PoP 上永遠是 miss。解析過程本身交給 DNS 篇，這裡只留下這個後果：全球命中率 ≠ 單一 PoP 命中率，purge 也必須扇出到所有分片。

兩欄是同一條 URL、同一把 key，結果卻相反——快取是地理分片的，所以全球命中率永遠低於單一 PoP 的命中率，purge 也必須扇出到每一片。

HIT / MISS / 回源

• HIT（fresh）：物件在、且仍在 TTL 內。邊緣直接回 200，origin 完全不知道這次請求。
• MISS：這把 key 在這個 PoP 上沒有。邊緣成為 origin 的 HTTP 客戶端，取回後寫入自己的 store，再回給使用者。
• Expired + revalidate：物件在，但過期了。邊緣帶 If-None-Match 問 origin；304 則刷新新鮮度、body 沿用，200 則換新表徵。

邊緣側的請求合併（Request Collapsing）

同一 PoP、同一把 key、同一瞬間的一群 miss，不必每人打一趟 origin。第一個成為 in-flight 的請求去回源，後來者掛在同一趟結果上。這是邊緣版的 Singleflight：範圍是這一台邊緣節點（或這一個 PoP），不是全球。

左欄是 collapsing 真正收掉的東西——單一 PoP 內併發 miss 的乘數；右欄是它的射程邊界，跨 PoP 與 key 碎片化都不在裡面。

過期不是一扇關上門。邊緣可以在「新鮮」「過期但仍可賣」「origin 掛了仍可賣」三個窗口裡做不同的事。

共用快取看的新鮮度，主要來自回應上的 s-maxage（沒有才退到 max-age）與物件進入快取後累計的 Age。當 Age < TTL，物件是 fresh，請求連 origin 的門都不敲。TTL 到期之後，預設行為是先驗證再賣——使用者付一次 RTT。兩個擴充指令把這扇門打開一條縫。

stale-while-revalidate：先賣舊的，背景更新

物件剛過期、但仍在 SWR 秒數內：邊緣立刻把舊表徵回給使用者（狀態仍是 200），同時對 origin 發一趟條件式 GET。更新成功就換新物件，失敗就繼續持有舊的直到窗口結束。

使用者看到的內容，與背景正在抓的內容，在這一秒內是故意分叉的。這就是 Demo 時間軸要對的帳：讀路徑的延遲被壓成 HIT，新鮮度落後最多一個 SWR 窗口。

右欄第一條就是採用 SWR 的前提：產品說不出「最多舊幾秒可以接受」，這個窗口就不該開。

stale-if-error：origin 掛了仍賣舊的

SWR 處理的是「過期但 origin 還活著」。SIE 處理的是「origin 5xx／連不上」。在 SIE 窗口內，邊緣可以在驗證失敗時繼續回舊表徵，而不是把 origin 的 502 轉發給全世界。

這是邊緣對 origin 故障的降級，不是應用層雪崩防護的替代品。雪崩篇用 TTL 抖動與 Singleflight 保護 origin 自己；這裡是 origin 已經倒了，邊緣決定還要不要把最後一份已知良好的 bytes 賣出去。

三個數字要一起設：TTL 決定平常多久打一次 origin，SWR 決定過期瞬間還能不能零延遲賣，SIE 決定 origin 事故時還能撐多久。

上尺是 age 域：上下兩條泳道分別是 origin 正常與 origin 故障時的行為，同一個 age 在兩條泳道落在不同的窗——這就是 SWR 與 SIE 的差別。下圖是時間域：每一根棒的高度是那次請求的回應延遲，圓點顏色是它落在哪個窗，▽ 是物件被重新填入的時刻。

邊緣是共用快取，也是 origin 的客戶端。標頭同時管「能不能存」與「過期後怎麼問」。

HTTP 篇已經區分過新鮮度（不發請求）與驗證（發請求但省 body）。這裡只補共用快取會踩到的差異：瀏覽器看到的 max-age，跟 CDN 看到的 s-maxage，常常不是同一個數字；邊緣拿著 ETag 去問 origin，跟瀏覽器拿著 ETag 去問 CDN，是兩段獨立的驗證。

共用快取真正會看的指令

一條經驗：HTML 入口短 TTL 或 no-cache；雜湊資產 s-maxage 一年 + immutable；帶身分的回應不要進 CDN。

ETag 在邊緣是「origin 的驗證器」

物件過期後，邊緣帶著手上那份的 ETag 向 origin 送 If-None-Match: "v7"，origin 只會有兩種回答：

該看「省下什麼」欄：驗證成功時省的是 body，不是往返；兩列付出的 RTT 相同。

304 的意義是省 origin 出口頻寬與產生成本，不省 RTT。邊緣到 origin 往往已經在骨幹上，RTT 不是零；所以能靠 SWR 讓使用者不排隊的，就不要讓使用者路徑去等 304。304 適合「必須確認新舊、但內容十次有九次沒變」的 API 與 HTML。

瀏覽器對 CDN 也可以再做一次同樣的對話。那是另一跳：CDN HIT 時，瀏覽器的 If-None-Match 由邊緣回答 304，origin 仍不參與。兩段驗證不要畫成一條。

改了內容之後，要嘛換 URL 讓舊物件自己過期，要嘛去每個 PoP 把舊物件殺掉。回源路徑上再加一層父快取，用來收斂全球 miss。

1 · 版本化 URL（不可變資產）

建置時把內容雜湊寫進檔名：app.a1b2c3.js。這把 URL 永遠對應那一串 bytes，於是可以：

• Cache-Control: public, s-maxage=31536000, immutable
• 不需要 Purge。舊檔名沒人再請求，自然從 LRU 裡掉下去
• 發布 = 上傳新檔 + 改 HTML 裡的引用。HTML 本身必須短 TTL 或 no-cache，否則使用者會拿到「舊 HTML 指向舊 hash」——這是版本化能成立的那一條繩

2 · 主動 Purge

URL 不能改時（CMS 文章、頭圖、功能開關 JSON），只能叫 CDN 把物件作廢。實作上是對 PoP 扇出的失效訊息，不是單一原子操作。

右欄三條都是 purge 的隱藏成本；決定要不要 purge 之前，先看你的失效需求能不能被左欄的 tag 模型收斂。

預設選版本化。Purge 留給「URL 就是契約」的那類物件，且把 blast radius 限制在 tag，而不是 /*。

3 · Origin Shield 與分層快取

每個 PoP 都是獨立的葉子快取。一個新資產、一次全球 purge、一個短 TTL 的熱 JSON，會讓每個未命中的 PoP 各打 origin 一次。Origin Shield 是靠近 origin 的父快取：葉子 miss 先問 Shield，Shield HIT 就結束，Shield MISS 才真正進 origin。

該看最後一欄：Shield 把「每個 PoP 各打一次」收斂成「全球打一次」，多出的那一跳只出現在 miss 的兩列。

這是跨 PoP 的 collapsing。單一 PoP 內的 in-flight 合併處理「這一棟樓的電梯」；Shield 處理「整座城市只派一輛卡車去倉庫」。多一跳的代價發生在 miss 路徑上：HIT 仍由葉子直接回，不經過 Shield。

把一條真實 URL 攤開：每一段標「進 key／被丟棄／被正規化成什麼」，再用一批帶噪音的樣本請求，算出這組規則的唯一 key 數、回源次數與命中率上限。

上半的段位移圖看兩件事：打叉的段垂到丟棄槽（那些位元組沒進 key），以及保留段的連線是否交叉——交叉就代表排序正規化把它搬了位置。下半的乘法塔是碎片的來源，熱度表最後一列越長，代表碎片化的冷 key 尾巴越重。

Edge Compute 接在「算 key 之前或 HIT 之後」的那一層。它能改請求、能改回應，但兩頭改錯都會把快取改壞：改壞請求，第 2 節的 Cache Key 正規化白做；改壞回應，每一次 HIT 都把錯的表徵回給所有人。

邊緣運算（Workers／Functions at the edge）讓你在 PoP 上跑一小段請求／回應邏輯：驗 JWT、補地理標頭、依 Cookie 做 A/B、改圖片尺寸、擋 bot。它不是把 origin 應用搬去 300 個城市。

兩欄的分界是「會不會動到權威狀態」：不動權威的正規化與門禁可以放邊緣，動權威的寫入一律留在 origin。