作為技術決策者在選擇使用 CDN 服務時最關心的三個問題是:一,哪家的 CDN 更快(速度快,用戶體驗好)。二, 哪家 CDN 功能最全,即使現在用不到也不會給將來業務發展挖坑。三,怎么付費最劃算。本文通過分析對國內 CDN 市場占有率靠前的十家服務商的網絡環境和技術服務,希望給大家提供一些啟發和建議。
哪家的 CDN 更快?
CDN 服務商經常引用獨立第三方公司的撥測數據來證明自己的 CDN 服務更好。雖然這些數據在某個區域或時間段也許是準確的,實際卻是盲人摸象,無法證明全時段和全網 CDN 服務的真實性能。也許從 CDN 服務商所處的網絡環境和提供的技術功能入手,會是更科學和公平的對比方法。
國內用戶普遍使用互聯網提供商 (ISP) 的寬帶上網,具體訪問流程如下圖:
圖 1
用戶終端訪問 CDN 的過程分兩個步驟, 一是用戶通過 DNS 找到最近的 CDN 邊緣節點 IP; 二是數據在網絡中的送達用戶終端。整個過程中,有三個方面會影響用戶訪問 CDN 的體驗。
一,擁有 DNS 優化策略的 CDN 提供商,會有更好的用戶體驗。
從圖 1 可見, 客戶終端的 DNS Resolver 負責告訴瀏覽器到哪里去找 CDN 的資源。理論上 ISP 的 DNS 服務器會選擇離用戶最近 CDN 節點 IP 并返回給用戶,但是實際情況并不是這么簡單。國內的大城市的 ISP 業務,除了一些區域性的 ISP,基本被聯通、電信和移動這樣的大運營商所壟斷。由于各運營商之間存在著網間費用結算,運營商會想盡一切辦法將用戶的訪問在自己的網內解決掉。比如,廣州聯調寬帶的用戶想訪問的內容在聯通北京的 CDN 節點, 盡管在廣東移動的 CDN 節點有用戶想訪問的資源,聯通的 DNS 還是會返回聯通北京 CDN 節點的 IP。
另外,一些 ISP 為了節省網間流量,未經 CDN 服務商同意,自己針對一些 CDN 文件做了一層 CDN 緩存,通過“DNS 劫持”把用戶訪問 CDN 資源的請求都指到自己網內的非法 CDN 緩存服務器。很多時候這些緩存的內容不能及時和 CDN 節點同步更新,會造成使用該 ISP 的用戶終端出現訪問 CDN 資源緩慢,失敗等現象。同時,國內嚴重的 DNS 污染問題也影響了用戶的上網體驗。
因此,如果能使用一些技術優化用戶 DNS 查詢,會大幅度提高用戶的體驗。目前優化 DNS 的技術主要是:
HttpDNS :客戶端基于 Http 協議向 CDN 服務商指定的 DNS 服務器發送域名解析請求,從而避免 LocalDNS 造成的域名劫持和跨網訪問。如圖 2
圖 2
Http 302 跳轉: CDN 廠商維護 CDN 域名 IP 庫,根據用戶訪問終端的 IP 和 CDN 邊緣節點的狀態,選擇最合適的 CDN 節點,發出 HTTP 的 302 返回碼,將用戶的請求跳轉到合適的 CDN 邊緣節點。例如騰訊的下載直通車就使用類似技術。 圖 3
圖 3
二,擁有自治系統(Autonomous system, AS)的 CDN 提供商,數據包跨越最少的網絡邊界,能獲得更快的傳輸速度。
在 BGP 協議中,IP 包從一個 AS 向另一個 AS 傳輸時,需要經過邊界路由器,如果由于網絡問題造成 IP 包不可達,則需要邊界路由器重新規劃線路。如果 CDN 服務商自己擁有自治系統,AS 內部擁有同樣的選路策略,數據就能在 CDN 服務商自己的 AS 中高效傳輸,理論上最終送達用戶所花的時間也會最小。 就好比我們開車在省內玩,肯定要比跨多個省經過多個收費站耗時要少。
三, CDN 服務商所在自治系統 AS 的相鄰 AS 越多,離運營商骨干網越近,數據傳輸也會更有優勢。
CDN 服務商所在的 AS 離運營商骨干網 AS 越近,理論上數據包傳輸所花時間也越少。另外, CDN 廠商如果同時租用了多個運營商品牌的帶寬線路,其服務器的 IP 就會同時屬于這幾家運營商的 AS,跨運營商的數據傳輸時間也會比只有一個運營商的相對快些。就如同有多個高速公路的通行證,數據在傳輸過程中從一家的路面后就可直達用戶,而不用來回在多個道路上切換,避免了不必要的時間損耗。
對比結果
選取 IDC 評述網排名前十的 CDN 服務商,采用以下方法收集數據:
瀏覽 CDN 服務商的網站,收集關于 CDN 加速的功能介紹,得到對比項一。
通過 nslookup 查詢他們域名對應的 IP,使用美國 Hurricane Electric 公司提供的網頁工具查尋 AS 號碼和其相關聯的相鄰域所屬的運營商得到對比項二和三。
以上數據收集方法存在如下假設:
CDN 廠商把自己的主站建在和自己 CDN 同一個 AS 內,沒有租用其它廠商的主機。如果廠商連自己的主站都不使用自己的產品,只能說明他們對自己的產品都沒有信心。
CDN 廠商把對于 DNS 優化的功能都公布在互聯網上。在競爭激烈的 CDN 行業,廠商都希望對外宣傳自己的亮點,不存在酒香不怕巷子深的說法。
注:第 9 位的世紀互聯的網站對其 CDN 服務的介紹很少,無法獲取需要的信息,增補了第 11 位的京東云。
對比結果如下表 1:
表 1
阿里云,騰訊云和網宿科技由于支持 HttpDNS 在技術上有領先優勢,可以列為第一梯隊。第二梯隊的是百度云,藍訊,Ucloud 和網易云。它們所在 AS 和兩個以上運營商主干網 AS 相鄰,也具有一定優勢。剩下的金山云,七牛云和京東云排在第三梯隊。金山云所在 AS 只和電信骨干網 AS 相連,使用其它運營商的用戶訪問其 CDN 節點理論上會相對電信的慢一些。七牛云和京東云其網絡屬于北京電信通的 AS,需要穿過兩個 AS 才接入骨干網,理論上速度也會比其他 CDN 服務商稍慢。
哪家 CDN 功能最全
CDN 服務的功能點非常多,為了比較方便選擇了 11 個常用的功能,主要覆蓋加速優化,監控和安全三個方面:
加速優化
HTTP2.0 加速
HTTP2.0 和現在的 HTTP1.1 相比,做了很大的改動和優化,例如頭部壓縮、服務端推送等。因為它要求服務器端和瀏覽器端都得支持 HTTP2.0 協議,所以在國內獲得普遍支持還有一段時間。不過作為互聯網下一代 HTTP 協議,即使我們現在用不上,也應考慮為將來的系統升級留下余地。
文件壓縮
目前 CDN 節點使用的 WEB 服務器端普遍支持 GZIP 協議的壓縮, 當用戶瀏覽器訪問靜態資源,并且支持 Gzip 壓縮時, 服務器端可以把資源壓縮打包發送給瀏覽器,由瀏覽器進行解壓, 減少文件在互聯網傳輸的數據量和時間。
源站推送
為了避免傳統的 CDN 節點同時去源站拉數據,造成訪問洪峰壓垮源站的帶寬和服務器。 CDN 廠商使用源站推送功能將源站內容提前推送給邊緣 CDN 節點,提前進行刷新預熱。
點播加速
CDN 對音視頻等流媒體文件進行加速,其背后是一套復雜的技術方案,包括上傳,轉碼,分發,以及 CDN 邊緣節點根據用戶終端支持協議的情況下發合適的流媒體格式。不同 CDN 服務商對點播加速的技術實現方案不同,不好做量化比較,只用是否支持播加速功能來比較。
直播加速
直播加速如何解決播放延時、連麥時多路音視頻的合并、以及突發熱點對帶寬的沖擊等這些技術挑戰,對 CDN 服務商的技術、硬件和網絡條件都有很高的要求。也用是否支持直播加速來比較。
監控統計
實時監控
CDN 服務商提供圖形化工具,對 CDN 的使用情況,例如點擊量,命中率,公網下行流量等進行統計和監控。方便客戶對于 CDN 使用效率和結果進行評估,及時發現問題和調整網絡帶寬預算。
原始日志
提供所有客戶終端訪問 CDN 服務的原始日志 (access log),這些日志看似沒用,其實很有價值。例如,可以通過分析原始日志的數據包總量估算出 CDN 實際的下行流量,作為支付 CDN 服務費的參考。也可以通過分析這些日志的響應時間,結合客戶端 IP,評估各地區終端用戶實際訪問 CDN 的情況。
安全
防盜鏈
CDN 服務商防盜鏈的手段很多,例如常用的 http Referer 防盜鏈,其原理是利用 http header 中的 referer 屬性,判斷用戶提交信息的網站 IP 地址,然后和真正的源站端的地址相比較,如果一致則表明是站內提交,或者為自己信任的站點提交,否則視為盜鏈。
IP 黑白名單
黑白名單是我們可以根據業務需要對用戶請求的源 IP 訪問進行管理,為我們提供了主動防御的能力。使用 IP 黑名單的功能,可以有效的幫助我們阻止盜鏈,和惡意攻擊。
SNI ( 服務器名稱指示 Server Name Indication )
網站使用 SSL/TSL 協議校驗是目前防止盜鏈,和解決 “DNS 劫持”最好的方式。目前國內外大型網站都已經換成了基于該協議的 HTTPS 通信方式。早期的 SSL 協議默認每個 IP 地址上只能用一個證書。TLSv1z 增加了服務器名稱指示(SNI)功能,通過發送虛擬主機名作為 TLS 協商的一部分這使得服務器可以在握手階段選擇正確虛擬域,并發送對應證書。這樣每個 IP 上可以部署多張證書,對于運行很多虛機和域名的用戶會非常節省資源。如果 CDN 服務商支持該項功能,說明 CDN 服務支持 HTTPS 和 TSL v1 以上版本。
OCSP 裝訂(OCSP STAPLING)
使用 SSL 認證時,客戶端會在 TLS 握手階段,去發證機構對實時查詢 OCSP (Online Certificate Status Protocol,在線證書狀態協議)接口,來判斷服務器端的證書是否作廢。在獲得獲得 OCSP 結果前會阻塞后續流程,通常發證機構都在國外,客戶端的訪問會延遲整個 TLS 握手的時間。而 OCSP Stapling 功能,是指服務端在證書鏈中封裝了發證書機構對證書的 OCSP 查詢結果,從而讓客戶端瀏覽器跳過自己去驗證的過程。如果 CDN 服務商支持該功能,說明其 CDN 服務支持 HTTPS 加速比較好。
對比結果
對前文的十家 CDN 服務商進行打分,結果如下表:
表 2
騰訊云和網宿科技得分最高,其它廠商各有優劣。 9 分以上的廠商占了前 50%,分別是騰訊云,網宿科技,阿里云,百度云藍汛。后 50% 的廠商分數在 8-7 分之間。
哪家的性價比更高
計費方式:
目前業內普遍使用的 CDN 計費方式有兩種:每按帶寬峰值和按流量。
帶寬峰值計費
每 5 分鐘統計一個帶寬峰值(單位 Mbps),每日得到 288 個峰值,取當日帶寬峰值作為結算標準。計費周期普遍采用按日計費,每日零點扣費。
按流量計費
按照每月使用的實際流量作為結算標準。價格普遍采用階梯定價。計費周期普遍采用按月計費,每月最后一天零點扣費。也有一些廠商采用按日計費或按小時計費和扣費。
對比結果
各廠商收費標準如下表:
表 3
注:有些 CDN 廠商會對包月的大客戶提供優惠,本文不做對比。
按峰值計費 10 家廠商有 6 家支持,3 家不支持,1 家網上沒有公開價格。500M-5G 帶寬平均市場價格在 0.69 元 Mbps。峰值帶寬計費低于 0.69 元的廠商有 4 家,分別是阿里云,騰訊云,百度云和金山云。按流量計費的 9 家支持,1 家網上沒有公開價格,10T-50T 階梯的平均流量價格是 0.25 元 /G。流量計費低于 0.25 元 /G 的廠家有 5 家,分別是阿里云,騰訊云,藍汛,金山云和七牛云。
哪種計費方式更合算
以 1Mbps 帶寬作為計算如下:
1Mbps = 128KB/s.
128KB/s = 7680KB/minute (7.5MB/minute)。
7680KB/minute = 460800KB/hour (450MB/hour)。
460800KB/hour = 11059200KB/day (10.54gb/day)
通過計算,1Mbps 帶寬的網絡,一天 24 小時跑滿的話可以消耗約 10.5G 的流量。以網絡利用率占峰值的 10%,20%,25%, 30% 為參數計算使用峰值帶寬和按流量計費的花費對比,結果如下表:
表 4
通常大家都會選擇按流量計費。但是如果帶寬的實際利用率大于 30% 后,實際花費的錢是小于實際消耗的流量計費模式的。 例如我們使用 50Mbps 峰值帶寬每天花費 34.5 元。 如果 CDN 利用率大于 30%,使用的實際流量為 131.25G 對應流量計費要花費 39.38 元,按峰值寬帶計費會更劃算。
單鏈鏈接限速
使用峰值寬帶計費大家普遍的擔心是被惡意攻擊造成短時間內巨大的峰值,以峰值來計算整天的費用非常不劃算。使用單鏈接限速可以避免這樣的問題。所謂單鏈接限速,就是在 CDN 邊緣節點的 WEB 服務器上,設置限制單連接的下載速度,使其最高速度限定在預設值內。該功能可在保障用戶訪問體驗的同時,在一定程度上平滑帶寬值,合理節省帶寬成本。不過國內現在只有網宿科技宣稱支持該功能,其它 CDN 廠商還不支持。
總結
回答了關于 CDN 服務商的速度、功能和價格三個問題,哪家的性價比最高呢?最后做一個綜合比較:
速度評分中,第一梯隊的記 3 分,以此類推第二梯隊 2 分,第三梯隊 1 分。
功能評分中,大于 9 分的 CDN 服務商得 1 分,其他不得分。
價格評分中,峰值帶寬計費 500M-5G 帶寬低于平均市場價格 0.69 元的 CDN 服務商得 1 分,流量計費低于 0.25 元 /G 的得 1 分。
結果如下:
表 5
阿里云和騰訊云 6 分并列第一,在 CDN 服務上優勢明顯。百度,網宿科技,藍訊都是 4 分并列第二,百度價格有優勢,網宿科技在訪問速度上有勢,藍訊各方面比較平均。金山云列第三。其他 CDN 服務商得分小于 3 分,不到總分(6 分)的 50%,在 CDN 行業的競爭中處于劣勢。
評論