主持人 > 博客 > 管理 > [不要]使用 CDN

[不要]使用 CDN

幾乎每一篇用於優化網站速度的文章或工具都有一個溫和的條款「使用 CDN」。 通俗地講，CDN是內容傳遞網路或內容傳遞網路。 Method Lab 經常會遇到客戶關於此主題的問題；其中一些客戶啟用了自己的 CDN。 本文的目的是了解 CDN 在網站載入速度方面可以提供什麼、可能會出現什麼問題以及在哪些情況下使用 CDN 是合理的。

[不要]使用 CDN

圖中圈出的延遲是因為使用CDN造成的。

歷史上的位

與許多技術一樣，CDN 的出現也是出於需求。 隨著網友網路通路的發展，出現了線上視訊服務。 當然，與常規網站內容（圖片、文字和 CSS 或 JS 程式碼）相比，影片內容需要更多數量級的頻寬。

當嘗試從一台伺服器向多個用戶端並行廣播視訊串流時，該伺服器的 Internet 通道很可能會成為瓶頸。 通常，幾千個執行緒就足以堵塞典型的伺服器通道。 當然，可能還有其他資源限制，但目前這些都不重要。 同樣重要的是，擴展伺服器通路成本太高（有時是不可能的），而且也不切實際。 廣播期間頻道上的負載將是週期性的。

CDN完美解決了單一伺服器的通道限制問題。 客戶端不直接連接到伺服器，而是連接到 CDN 網路中的節點。 在理想情況下，伺服器將一個流傳送到 CDN 節點，然後網路使用自己的資源將該流傳送給許多使用者。 從經濟角度來看，我們只需為實際消耗的資源（可能是頻寬或流量）付費，並獲得服務的出色可擴展性。 使用 CDN 來傳送大量內容是完全合理且合乎邏輯的。 儘管值得注意的是，該領域最大的參與者（例如 Netflix）正在建立自己的 CDN，而不是使用大型商業 CDN（Akamai、Cloudflare、Fastly 等）

隨著網路的發展，網路應用程式本身也變得越來越複雜。 加載速度的問題就凸顯出來了。 網站速度愛好者很快就發現了導致網站加載緩慢的幾個主要問題。 其中之一是網路延遲（RTT - 往返時間或 ping 時間）。 延遲會影響網站載入的許多過程：建立 TCP 連線、啟動 TLS 會話、載入每個單獨的資源（映像、JS 檔案、HTML 文件等）

當使用HTTP/1.1 協定時（在SPDY、QUIC 和HTTP/2 出現之前，這是唯一的選擇），瀏覽器對一台主機開啟的TCP 連線不超過6 個，這一事實使問題變得更加嚴重。 所有這些都導致​​連接停機和通道頻寬的低效率使用。 這個問題透過域分片得到了部分解決——創建​​額外的主機來克服連接數量的限制。

這就是 CDN 的第二個能力出現的地方——減少由於點數量多且節點距離用戶較近而導致的延遲 (RTT)。 距離在這裡起著決定性的作用：光速是有限的（光纖中約為200公里/秒）。 這意味著每行駛 000 公里就會增加 1000 毫秒的延遲或 RTT 增加 5 毫秒。 這是傳輸所需的最短時間，因為中間設備也存在延遲。 由於 CDN 通常知道如何在其伺服器上快取對象，因此我們可以從透過 CDN 載入此類對像中受益。 其必要條件是：快取中存在物件、與 Web 應用程式伺服器（來源伺服器）相比，CDN 指向使用者的距離較近。 重要的是要了解 CDN 節點的地理鄰近性並不能保證低延遲。 客戶端和 CDN 之間的路由可以這樣構建，即客戶端將連接到另一個國家/地區（甚至可能位於另一個大陸）的主機。 這就是電信業者和 CDN 服務之間的關係（對等、連接、參與 IX 等）以及 CDN 本身的流量路由策略發揮作用的地方。 例如，Cloudflare 在使用兩個初始計劃（免費和便宜）時，不保證從最近的主機交付內容 - 將選擇主機以實現最低成本。

許多領先的網路公司吸引了公眾（網頁開發人員和服務所有者）對載入速度和網站效能主題的興趣。 這些公司包括雅虎（Yslow 工具）、AOL（WebPageTest）和 Google（Page Speed Insights 服務），它們正在製定自己的網站加速建議（主要與客戶端優化有關）。 後來，出現了新的網站速度測試工具，其中也提供了提高網站速度的技巧。 這些服務或外掛程式都有一個一致的建議：「使用 CDN」。 網路延遲的減少通常被用來解釋 CDN 的效果。 不幸的是，並不是每個人都準備好準確地理解 CDN 的加速效果是如何實現的以及如何衡量它，因此該建議是出於信念並用作假設。 事實上，並非所有 CDN 都是一樣的。

立即使用 CDN

為了評估使用 CDN 的有用性，需要對它們進行分類。 現在在實務上可以發現什麼（當然，括號中的範例並不詳盡）：

  1. 用於分發 JS 庫的免費 CDN（MaxCDN、Google.Yandex）。
  2. 用於客戶端優化的服務 CDN（例如，用於字體的 Google Fonts、用於圖像的 Cloudinary、Cloudimage）。
  3. 用於 CMS 中的靜態和資源最佳化的 CDN（可在 Bitrix、WordPress 等中使用）。
  4. 通用 CDN（StackPath、CDNVideo、NGENIX、Megafon）。
  5. 用於網站加速的 CDN（Cloudflare、Imperva、Airi）。

這些類型之間的主要區別在於有多少流量通過 CDN。 類型 1-3 只傳送部分內容：從一個請求到數十個請求（通常是圖片）。 類型 4 和 5 是透過 CDN 完全代理流量。

實際上，這意味著用於載入網站的連線數。 對於 HTTP/2，我們使用與主機的單一 TCP 連線來處理任意數量的請求。 如果我們將資源劃分為主主機（來源）和CDN，那麼就需要跨多個網域分發請求並建立多個TCP連線。 最糟的情況是：DNS (1 RTT) + TCP (1 RTT) + TLS (2-3 RTT) = 6-7 RTT。 此公式不考慮行動網路中啟動設備無線電通道（如果未啟動）的延遲以及手機訊號塔上的延遲。

以下是網站載入瀑布圖的樣子（連接 CDN 的延遲以 RTT 150 毫秒突出顯示）：

[不要]使用 CDN

如果CDN覆蓋了所有站點流量（第三方服務除外），那麼我們可以使用單一TCP連接，從而節省連接到其他主機的延遲。 當然，這適用於 HTTP/2 連線。

進一步的差異取決於特定 CDN 的功能 - 對於第一種類型，它僅託管靜態文件，對於第五種類型，它會出於優化的目的更改幾種類型的網站內容。

CDN 網站加速能力

讓我們描述用於加速站點的全方位 CDN 功能，而不考慮各個類型 CDN 的功能，然後看看每種 CDN 中實現了什麼。

1.文本資源的壓縮

這是最基本、最容易理解的功能，但往往實施得不好。 所有 CDN 都聲明壓縮作為其加速功能。 但如果你仔細觀察，缺點就會變得很明顯：

  • 可以使用動態壓縮的低度數 - 5-6（例如，對於 gzip，最大值為 9）；
  • 靜態壓縮（快取中的檔案）不使用附加功能（例如，等級為 11 的 zopfi 或 brotli）
  • 不支援高效的 brotli 壓縮（與 gzip 相比節省約 20%）。

如果您使用 CDN，則值得檢查以下幾點：獲取來自 CDN 的文件，記錄其壓縮大小並手動壓縮以進行比較（您可以使用一些支援 brotli 的線上服務，例如 vsszhat.rf).

2.設定客戶端快取頭

還有一個簡單的加速功能：新增客戶端（瀏覽器）內容快取的標頭。 最新的標頭是cache-control，過時的標頭是expires。 此外，還可以使用 Etag。 最主要的是cache-control的max-age足夠大（一個月或更長時間），如果你準備盡可能地快取資源，你可以添加immutable選項。

CDN 可以降低 max-age 值，迫使使用者更頻繁地重新載入靜態內容。 目前尚不清楚這與什麼有關：希望增加網路流量或增加與不知道如何重置快取的網站的兼容性。 例如，預設的 Cloudflare 標頭快取時間為 1 小時，這對於不可變的靜態資料來說非常低。

3.影像優化

由於CDN承擔了快取和服務圖片的功能，因此在CDN側進行最佳化並以這種形式將其服務給使用者是合乎邏輯的。 我們馬上預約一下，該功能僅適用於 CDN 類型 2、3 和 5。

您可以透過多種方式優化影像：使用進階壓縮格式（例如 WebP）、更有效率的編碼器 (MozJPEG)，或只是清理不必要的元資料。

一般來說，此類最佳化有兩種類型：有品質損失和無品質損失。 CDN 通常會努力使用無損優化，以避免客戶對影像品質變化可能發生的投訴。 在這種情況下，收益將是最小的。 實際上，JPEG 品質等級通常比必要的要高得多，您可以安全地以較低的品質等級重新壓縮，而不會影響使用者體驗。 另一方面，很難確定所有可能的 Web 應用程式的品質等級和設置，因此與考慮上下文（影像的目的、Web 應用程式的類型）而應用的設定相比，CDN 使用更保守的設置， ETC。 ）

4. 優化TLS連接

如今，大多數流量都透過 TLS 連線傳輸，這意味著我們需要花費額外的時間進行 TLS 協商。 最近，新技術的開發加速了這個過程。 例如，這是EC加密、TLS 1.3、會話快取和票證、硬體加密加速（AES-NI）等。正確設定TLS可以將連線時間減少到0-1 RTT（不包括DNS和TCP）。

借助現代軟體，您自己實現此類實踐並不困難。

並非所有 CDN 都實作 TLS 最佳實務；您可以透過測量 TLS 連線時間來檢查這一點（例如，在 Webpagetest 中）。 非常適合新連接 - 1RTT、2RTT - 平均水平，3RTT 等 - 差。

還應該注意的是，即使在 CDN 層級使用 TLS，具有我們 Web 應用程式的伺服器也必須處理 TLS，但是是從 CDN 端處理，因為伺服器和 CDN 之間的流量通過公共網路。 在最壞的情況下，我們將得到雙倍 TLS 連線延遲（第一個延遲到 CDN 主機，第二個延遲在 CDN 主機和我們的伺服器之間）。

對於某些應用程序，值得關注安全問題：流量通常在 CDN 節點上解密，這是流量攔截的潛在機會。 頂級資費計劃中通常提供不披露流量的工作選項，但需支付額外費用。

5. 減少連線延遲

大家都在談論的 CDN 的主要好處是：CDN 主機和使用者之間的低延遲（更短的距離）。 透過建立地理分散式網路架構來實現，其中主機位於用戶集中點（城市、流量交換點等）

實際上，不同網路的優先順序可能位於特定區域。 例如，俄羅斯 CDN 將在俄羅斯擁有更多存在點。 美國公司首先會在美國發展網絡。 例如，最大的CDN之一Cloudflare在俄羅斯只有2個點——莫斯科和聖彼得堡。 也就是說，與直接放置在莫斯科相比，我們最多可以節省約10毫秒的延遲。

大多數西方 CDN 在俄羅斯根本沒有站點。 透過連接到他們，您只會增加俄羅斯觀眾的延遲。

6.內容優化（縮小、結構變化）

最複雜、技術最先進的一點。 在交付過程中更改內容可能非常危險。 即使我們進行縮小：減少原始程式碼（由於額外的空格、不重要的結構等）也會影響其效能。 如果我們談論更嚴重的變更 - 將 JS 程式碼移至 HTML 末端、合併文件等 - 破壞網站功能的風險甚至更高。

因此，只有某些類型 5 CDN 會這樣做。 當然，不可能自動執行加快速度所需的所有更改，需要手動分析和最佳化。 例如，刪除未使用或重複的程式碼是一項手動任務。

通常，所有此類最佳化均由設定控制，並且預設會停用最危險的最佳化。

支援CDN類型的加速能力

那麼讓我們來看看不同類型的 CDN 提供了哪些潛在的加速機會。

為了方便起見，我們重複分類。

  1. 用於分發 JS 庫的免費 CDN（MaxCDN、Google.Yandex）。
  2. 用於客戶端優化的服務 CDN（例如，用於字體的 Google Fonts、用於圖像的 Cloudinary、Cloudimage）。
  3. 用於 CMS 中的靜態和資源最佳化的 CDN（可在 Bitrix、WordPress 等中使用）。
  4. 通用 CDN（StackPath、CDNVideo、NGENIX、Megafon）。
  5. 用於網站加速的 CDN（Cloudflare、Imperva、Airi）。

現在我們來比較一下CDN的特徵和類型。

機會
1型
2型
3型
4型
5型

文字壓縮
+–
-
+–
+–
+

快取標頭
+
+
+
+
+

圖片
-
+–
+–
-
+

TLS
-
-
-
+–
+

延誤
-
-
-
+
+

內容
-
-
-
-
+

本表中，「+」表示完全支持，「-」表示不支持，「+-」表示部分支持。 當然，現實中可能與此表存在偏差（例如，某些通用 CDN 會實現優化圖像的功能），但對於一般想法來說它是有用的。

結果

希望在閱讀本文後您能夠更清楚地了解「使用 CDN」建議來加速您的網站。

與任何行業一樣，您不能相信任何服務的營銷承諾。 效果需要在真實條件下測量和測試。 如果您已經在使用 CDN，請使用本文中所述的標準檢查其有效性。

現在使用 CDN 可能會減慢網站的載入時間。

作為一般建議，我們可以專注於以下內容：研究您的受眾，確定其地理範圍。 如果您的主要受眾集中在 1-2 公里的半徑內，則不需要 CDN 來實現其主要目的 - 減少延遲。 相反，您可以將伺服器放置在更靠近用戶的位置並正確配置它，從而獲得本文中描述的大部分優化（免費且永久）。

如果您的受眾確實分佈在不同的地理位置（半徑超過 3000 公里），那麼使用優質 CDN 確實會很有用。 但是，您需要提前了解您的 CDN 到底可以加速什麼（請參閱功能表及其描述）。 然而，網站加速仍然是一項複雜的任務，無法透過連接 CDN 來解決。 除了上述優化之外，CDN背後最有效的加速手段是：伺服器部分的優化、客戶端部分的高級更改（刪除未使用的程式碼、優化渲染過程、處理內容、字體、適應性等）。 ）

來源： www.habr.com

添加評論