什麼是 CDN#

內容傳遞網路（CDN, Content Delivery Network）的核心思想是：距離會直接影響回應時間（response time）。同樣一份資源，若使用者與伺服器位於同一地理區域，可能 500 毫秒就能取得；但若得跨越大洋向遠端機房索取，回應時間有可能拉長到 3 秒以上。

為了解決這個問題，CDN 在世界各地佈建了大量的邊緣節點（Edge Node / PoP, Point of Presence）。當使用者向一個被 CDN 加速的網域發出請求時，CDN 會自動將請求導向地理位置較近、或當下負載較輕的邊緣節點。即使第一次請求時節點上還沒有快取，仍需要回到起源伺服器（Origin Server）取資料，但之後的同類請求就可以直接命中邊緣節點的快取，大幅縮短資源載入時間。

補充說明 除了快取以外，CDN 在某種程度上也提升了服務的可用性、負載分擔能力與安全性（例如降低 DDoS 攻擊對網站的衝擊）。

為什麼需要使用 CDN#

從一個網站經營者的角度來看，通常會期待網站具備以下特性：

  • 載入速度夠快
  • 能夠承受高流量
  • 不論使用者位在世界哪個角落，都能順暢且快速地造訪網站

CDN 最直接也最重要的價值，就是「加快網站的訪問速度」。除此之外，它還帶來幾項好處：

  • 跨地域全網覆蓋與節省頻寬：請求被分散到鄰近節點，避免所有流量都湧向同一台伺服器，原始主機的頻寬與負載都能大幅降低。
  • 節省成本：透過第三方 CDN 服務供應商，不必自行採購、維護伺服器，節點之間的狀態與資料同步也由供應商處理。
  • 更專注於業務邏輯：CDN 服務商通常還會提供其他周邊服務（例如 AWS CloudFront 與其他 AWS 服務的整合），讓開發者把心力放在業務本身。
  • 異地備援與高可用性：當某個節點故障時，系統會自動切換到鄰近健康的節點，盡量讓服務不中斷。
  • 提升安全性：負載平衡（Load Balancing）與分散式儲存讓網站更能抵禦惡意攻擊。

CDN 的基本架構#

最基本的 CDN 架構通常由多台 DNS 伺服器、負載平衡器與快取伺服器（cache server）組成。以下用一個假想網址 https://i-use-cdn.com 模擬使用者造訪過程：

  • 使用者輸入網址後，本地端 DNS 伺服器解析網域，並透過 CNAME 將解析權交給 CDN 專屬的 DNS 伺服器。
  • CDN 的 DNS 伺服器回傳全域負載平衡器（Global Load Balancer）的 IP。
  • 使用者向 Global Load Balancer 發出請求。
  • Global Load Balancer 依據使用者 IP 與請求內容，挑選一個區域型負載平衡器，並請使用者改向它發出請求。
  • 區域負載平衡器根據距離、資源命中狀況與當下負載，挑選一台合適的快取伺服器，把 IP 回給 Global Load Balancer，再轉交給使用者。
  • 使用者向該快取伺服器發出請求。若快取命中就直接回傳；若沒有，則往上一層或最終回到起源伺服器抓取資料，並更新快取。

常見疑問#

CDN 到底是針對什麼加速#

CDN 是針對「網域（Domain）」加速。如果一個網站擁有多個網域，只有被設定加速的那個網域會走 CDN 快取，其他網域不會受惠。

啟用 CDN 需不需要大改架構#

通常不需要修改任何程式碼，因為 CDN 是針對網域層級加速的。

哪些資源適合放上 CDN#

長時間不變動的靜態資源最適合，例如圖片、影音串流、CSS 與 JavaScript 檔案，甚至整個靜態網站。會變動的內容也可以放，但每次更新都要記得清快取，否則使用者會看到舊資料；過於頻繁變動或動態生成的內容，本身就不太適合放在 CDN。

CDN 如何處理內容更新#

只要使用快取，就一定要面對「失效」的問題。多數 CDN 服務商都提供 URL 推送（purge）功能，可以針對單一資源 URL 清除快取，也可以指定整個資料夾批次清除。

實務參考 大型電商（例如雙 11 期間需要更新大量商品圖價格）會設計專屬的快取與失效機制，研究他們的做法有助於更深入理解 CDN 架構。

如何區分要不要被快取#

頻繁變動或即時性高的資料命中率太低，放上 CDN 反而沒效益。常見做法是把網站拆成兩個網域：一個走 CDN，另一個不走，把動態內容放在沒有 CDN 的網域下。

常見 CDN 服務供應商#

  • Amazon CloudFront
  • Cloudflare
  • Google Cloud CDN
  • Azure CDN

Demo：用 AWS S3 + CloudFront 部署 React 應用#

以下示範如何將一個 React 應用佈署到 AWS S3，並接上 CloudFront 作為 CDN。整體流程在不同服務商之間概念類似，重點是體驗「綁定」這件事。

建立 React 專案#

npx create-react-app deploy-sample
cd deploy-sample
npm run start

確認 React 應用可在本機正常啟動。

設定 AWS IAM#

在 AWS Console 中開啟 IAM 服務，建立一位以「程式設計方式存取」的使用者，並指派可操作 S3 與 CloudFront 的權限。建立完成後會出現一組 Access Key 與 Secret Key，務必妥善保存（只會出現一次），未來在 CLI 或 CI/CD 流程中都會用到。

設定 AWS S3#

  • 進入 S3 主控台建立 bucket，記得取消勾選「封鎖所有公開存取權」。
  • 在 bucket 屬性中啟用「靜態網站託管」，並記下「儲存貯體網站端點」的 URL，稍後會在 CloudFront 用到。
  • 在「許可」分頁設定 bucket policy，賦予 s3:GetObject 等公開存取權限：
GET /index.html HTTP/1.1
Host: your-bucket.s3-website-region.amazonaws.com
  • 回到專案執行 npm run build，把產生的靜態檔案上傳至 bucket。

設定 AWS CloudFront#

  • 在 CloudFront 主控台建立分佈（Distribution）。
  • 「源網域名稱」填入剛才記下的 S3 靜態網站端點。
  • 「檢視器通訊協定政策」選擇「重新導向 HTTP 到 HTTPS」。
  • 「預設根物件」填入 index.html。
  • 等待狀態變為「已啟用」後，造訪 CloudFront 提供的網域，就能看到網站，且資源已透過 CDN 快取。

處理 SPA 的 404 重新導向#

由於 React 應用是 SPA，輸入不存在的路徑會出現 404。可在 S3 靜態網站託管設定中加入重新導向規則，將 404 統一導回首頁。

各種 Cache 的優先順序#

回到前面提過的四種快取機制：

  • Memory Cache
  • Disk Cache
  • Service Worker Cache
  • CDN Cache

它們的查找順序為：

Memory Cache → Service Worker Cache → Disk Cache (HTTP Cache / Browser Cache) → CDN Cache

CDN 快取明顯已經離開瀏覽器本機儲存，必須實際發出網路請求向邊緣節點要資料，因此排在最後一順位。

小結#

CDN 是現代網站效能優化裡極為關鍵的一塊。它透過「鄰近原則」加速資源傳遞，並順帶帶來成本、可用性與安全性的好處。近年也有不少 CDN 服務商開始把 Serverless 函式部署在邊緣節點上（例如 AWS Lambda@Edge、Cloudflare Workers），讓 CDN 不只是快取，更像是分散式運算平台。

原文出處#

Backward Web 前端效能優化 Code Minimize & Uglify Forward