效能優化小冊 - 提高網頁響應速度：優化你的 CDN 效能

破曉L發表於2020-05-21
優化網頁

1.使用高效能 DNS

CDN 服務本身並不具備域名解析功能，而是依託於 DNS 智慧解析功能，由 DNS 根據使用者所在地、所用線路進行智慧分配最合適的 CDN 服務節點，然後把快取在該服務節點的靜態快取內容返回給使用者。

如果域名轉換為 IP 這一過程可用性低且延遲高，那麼肯定會對 CDN 效能產生不良影響。

另外，請確保在 DNS 記錄上使用較高的 TTL（生存時間），以便解析器可以長時間快取記錄。

2.將源點移到 CDN 附近

保持 CDN 與源之間的等待時間短暫，是 CDN 應對快取未命中響應的有效的優化方法。

如果無法將源站點放在 CDN 附近，請考慮使用源防護（origin shield）。

Origin shield 是 CDN 和源之間的額外快取層。origin shield 有助於減輕源點負擔，它會在在源級別將來自多個 edge CDN 的傳入請求摺疊成一個請求，以加快快取未命中響應的速度。

一個好的 origin shield 可以減少 70% 到 80% 的源負載，即使它前面有一個效能良好的 edge CDN。

3.具有 IPv6 連線

IPv6 能提高「網速」通常是指新建的 IPv6 網路通常具有更大的頻寬（比如中國正在新建的 CERNET2 骨幹網動輒 10Gbps、100Gbps 的連線頻寬）、更好的流量控制、更少的 NAT 從而實現更高效的網路拓撲結構（IP 地址資源多從而不需要對資料包進行多次地址翻譯和轉發）。在這些方面 IPv6 確實是能提高「網速」的。

Facebook 已經對 IPv6 對效能的影響進行了大量研究，並得出了積極的效果：

我們已經觀察到，與 IPv6 相比，訪問 Facebook 的速度可以提高 10-15％。

4.調整您的 initcwnd

原始伺服器上的初始擁塞視窗引數（initcwnd）的值可能為 10。這意味著伺服器在第一次往返過程中通過新連線傳送了 10 個資料包。

值為 10 不是不可以，但是更高的 initcwnd 可能會對 TCP 效能產生明顯的積極影響，從而導致源和 CDN 之間的內容傳輸更快。

一些 CDN 的 initcwnd 為 10，其他 CDN 的值則高得多。

重要提示：請勿「簡單的」的增加伺服器上的 initcwnd 值並認為這樣會很好。

閱讀更多：

5. 讓連線永遠存活

當 CDN 需要從您的源伺服器中提取內容時，兩個伺服器之間必須存在 TCP 連線。

理想情況下，該連線已經存在並且可以重複使用，從而節省了建立新的連線時的往返時間和寶貴的毫秒值。

CDN 或源可能會終止連線，您無法控制 CDN 保持連線存活的時間，但是您可以控制源上的 keep-alive 行為。

永遠不要在源端關閉連線 - 擔心許多 CDN 伺服器與您的源點建立 TCP 連線並且該源無法處理該問題？設定一個 Origin shield。

6. 減少 TLS 連線時間

您有安全的 HTTPS 來源嗎？如果是，可以執行幾種優化來提高 CDN 效能。

舉個例子：TLS 錯誤啟動，TLS 會話恢復和 TLS 記錄大小優化。

在開始使用這些 TLS 優化之前，請檢查您的 CDN 是否需要其他方面的幫助，才能使這些優化生效。

進一步閱讀：

7. 最小化位元組大小

減少內容的位元組大小或「權重」對於加快 CDN 效能非常有效。傳輸的位元組越少，內容到達使用者的速度就越快。

您可以通過多種方法來最小化位元組大小以增強 CDN 效能，壓縮是最有效且通常最容易實現的方法。

延伸閱讀兩篇減少位元組大小的文章 minification 和 影像優化。

8. 成為快取控制大師 - 強制快取

如何使 CDN 儘可能長時間地快取物件並最大化快取命中率？

開箱即用，大多數或所有 CDN 都將遵循源伺服器通過 Cache-Control 標頭髮送的快取指令，這是提高 CDN 效能的非常有效的工具。

一些例子：
Cache-Control: max-age=86400 告訴 CDN 和瀏覽器該物件可能被快取 86400 秒。

Cache-Control: max-age=3600, s-maxage=86400 通知 CDN 它可能將物件快取 24 小時，而瀏覽器應將物件快取不超過 1 小時。注意：s-maxage 預設情況下，並非所有 CDN `都支援。

Cache-Control: max-age=86400, stale-while-revalidate=300 指示 CDN 和瀏覽器將物件快取 24 小時，然後在這 24 小時結束時，當從原始位置獲取新內容時，CDN 可以提供陳舊的響應長達 300 秒。

推薦看本專欄這篇文章：徹底理解瀏覽器快取機制。

瞭解有關快取控制的更多資訊：

9. 啟用條件請求 - 協商快取

當 CDN 收到對過期物件的請求（在快取記憶體中，但已過期）時，CDN 必須先聯絡源站點，然後再向使用者傳送響應。

如果快取的物件具有Last-Modified / ETag 標頭，則 CDN 可以通過新增 If-Modified-Since / If-None-Match 標頭來有條件地發起請求，源站點可以決定以輕量級 304 非修改響應（只有標頭響應），還是以 200 OK 重新返回響應（標頭和正文）。

推薦看本專欄這篇文章：徹底理解瀏覽器快取機制。

顯然，304 非修改響應的效能要優於 200 OK 響應，因為響應的大小要小得多，因此 CDN 與源之間的往返次數更少。

將原始伺服器配置為始終傳送 Last-Modified / ETag 標頭，因為這大大有助於提高快取的效能。

10. 注意 Vary 標頭

你的源不應該向 CDN 提供帶有諸如 Vary: Referer、Vary: User-Agent，Vary: Cookie 或 Vary: User-Agent,Cookie 標頭，這些 Vary 標頭對快取命中率和 CDN 效能有很大的負面影響。

重點：

  • 永遠不要使用 Vary: *，具有該標頭的物件將永遠不會儲存在 CDN 快取中。
  • 始終傳送 Vary: Accept-Encoding 帶有（Gzip）壓縮內容的標頭。

進一步閱讀：使用 Vary 標頭的最佳做法

分享這篇文章的原因：我認為原作者是一位網路效能優化大師，他本人的部落格優化的非常棒。

同系列文章：

參考連結：

相關文章