性能優化小冊 - 提升網頁響應速度:優化你的 CDN 性能

1.使用高性能 DNS

CDN 服務自己並不具有域名解析功能,而是依託於 DNS 智能解析功能,由 DNS 根據用戶所在地、所用線路進行智能分配最合適的 CDN 服務節點,而後把緩存在該服務節點的靜態緩存內容返回給用戶。

若是域名轉換爲 IP 這一過程可用性低且延遲高,那麼確定會對 CDN 性能產生不良影響。html

另外,請確保在 DNS 記錄上使用較高的 TTL(生存時間),以便解析器能夠長時間緩存記錄。webpack

2.將源點移到 CDN 附近

保持 CDN 與源之間的等待時間短暫,是 CDN 應對緩存未命中響應的有效的優化方法。web

若是沒法將源站點放在 CDN 附近,請考慮使用源防禦(origin shield)。segmentfault

Origin shieldCDN 和源之間的額外緩存層。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: RefererVary: User-AgentVary: CookieVary: User-Agent,Cookie 標頭,這些 Vary 標頭對緩存命中率和 CDN 性能有很大的負面影響。

重點:

  • 永遠不要使用 Vary: *,具備該標頭的對象將永遠不會存儲在 CDN 緩存中。
  • 始終發送 Vary: Accept-Encoding 帶有(Gzip)壓縮內容的標頭。

進一步閱讀:使用 Vary 標頭的最佳作法

分享這篇文章的緣由:我認爲原做者是一位網絡性能優化大師,他本人的 博客優化的很是棒。

同系列文章:

參考連接:

相關文章
相關標籤/搜索