CDN 服務自己並不具有域名解析功能,而是依託於 DNS 智能解析功能,由 DNS 根據用戶所在地、所用線路進行智能分配最合適的 CDN 服務節點,而後把緩存在該服務節點的靜態緩存內容返回給用戶。
若是域名轉換爲 IP
這一過程可用性低且延遲高,那麼確定會對 CDN 性能產生不良影響。html
另外,請確保在 DNS 記錄上使用較高的 TTL
(生存時間),以便解析器能夠長時間緩存記錄。webpack
保持 CDN 與源之間的等待時間短暫,是 CDN 應對緩存未命中響應的有效的優化方法。web
若是沒法將源站點放在 CDN 附近,請考慮使用源防禦(origin shield
)。segmentfault
Origin shield
是 CDN 和源之間的額外緩存層。origin shield
有助於減輕源點負擔,它會在在源級別未來自多個 edge CDN 的傳入請求摺疊成一個請求,以加快緩存未命中響應的速度。瀏覽器
一個好的 origin shield
能夠減小 70%
到 80%
的源負載,即便它前面有一個性能良好的 edge CDN
。緩存
IPv6 能提升「網速」一般是指新建的 IPv6 網絡一般具備更大的帶寬(好比中國正在新建的 CERNET2 骨幹網動輒 10Gbps、100Gbps 的鏈接帶寬)、更好的流量控制、更少的 NAT 從而實現更高效的網絡拓撲結構(IP 地址資源多從而不須要對數據包進行屢次地址翻譯和轉發)。在這些方面 IPv6 確實是能提升「網速」的。
Facebook 已經對 IPv6 對性能的影響進行了大量研究,並得出了積極的效果:安全
咱們已經觀察到,與 IPv6 相比,訪問 Facebook 的速度能夠提升 10-15%。
原始服務器上的初始擁塞窗口參數(initcwnd
)的值可能爲 10
。這意味着服務器在第一次往返過程當中經過新鏈接發送了 10
個數據包。性能優化
值爲 10
不是不能夠,可是更高的 initcwnd
可能會對 TCP 性能產生明顯的積極影響,從而致使源和 CDN 之間的內容傳輸更快。服務器
一些 CDN 的 initcwnd
爲 10,其餘 CDN 的值則高得多。網絡
重要提示:請勿「簡單的」的增長服務器上的 initcwnd
值並認爲這樣會很好。
閱讀更多:
當 CDN 須要從您的源服務器中提取內容時,兩個服務器之間必須存在 TCP
鏈接。
理想狀況下,該鏈接已經存在而且能夠重複使用,從而節省了創建新的鏈接時的往返時間和寶貴的毫秒值。
CDN 或源可能會終止鏈接,您沒法控制 CDN 保持鏈接存活的時間,可是您能夠控制源上的 keep-alive
行爲。
永遠不要在源端關閉鏈接 - 擔憂許多 CDN 服務器與您的源點創建 TCP 鏈接而且該源沒法處理該問題?設置一個 Origin shield
。
您有安全的 HTTPS 來源嗎?若是是,能夠執行幾種優化來提升 CDN 性能。
舉個例子:TLS
錯誤啓動,TLS
會話恢復和 TLS
記錄大小優化。
在開始使用這些 TLS
優化以前,請檢查您的 CDN 是否須要其餘方面的幫助,才能使這些優化生效。
進一步閱讀:
減小內容的字節大小或「權重」對於加快 CDN 性能很是有效。傳輸的字節越少,內容到達用戶的速度就越快。
您能夠經過多種方法來最小化字節大小以加強 CDN 性能,壓縮是最有效且一般最容易實現的方法。
延伸閱讀兩篇減小字節大小的文章 minification 和 圖像優化。
如何使 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
秒。
推薦看本專欄這篇文章: 完全理解瀏覽器緩存機制。
瞭解有關緩存控制的更多信息:
當 CDN 收到對過時對象的請求(在高速緩存中,但已過時)時,CDN 必須先聯繫源站點,而後再向用戶發送響應。
若是緩存的對象具備Last-Modified / ETag
標頭,則 CDN
能夠經過添加 If-Modified-Since / If-None-Match
標頭來有條件地發起請求,源站點能夠決定以輕量級 304
非修改響應(只有標頭響應),仍是以 200 OK
從新返回響應(標頭和正文)。
推薦看本專欄這篇文章: 完全理解瀏覽器緩存機制。
顯然,304
非修改響應的性能要優於 200 OK
響應,由於響應的大小要小得多,所以 CDN
與源之間的往返次數更少。
將原始服務器配置爲始終發送 Last-Modified / ETag
標頭,由於這大大有助於提升緩存的性能。
你的源不該該向 CDN 提供帶有諸如 Vary: Referer
、Vary: User-Agent
,Vary: Cookie
或 Vary: User-Agent,Cookie
標頭,這些 Vary 標頭對緩存命中率和 CDN 性能有很大的負面影響。
重點:
Vary: *
,具備該標頭的對象將永遠不會存儲在 CDN 緩存中。Vary: Accept-Encoding
帶有(Gzip)壓縮內容的標頭。分享這篇文章的緣由:我認爲原做者是一位網絡性能優化大師,他本人的 博客優化的很是棒。
同系列文章:
參考連接: