為什麼CDN對移動客戶端加速“沒有”效果

InfoQ發表於2014-09-04

Google web效能優化工程師和開發大使、《High-Performance Browser Networking》作者Ilya Grigorik近日釋出了一篇名為《為什麼CDN對移動客戶端加速“沒有”效果》的部落格,描述了移動(無線)網路的特殊性,以及如何建設一個適用於移動CDN的構想。

Ilya首先吐槽了目前的CDN在移動客戶端加速方面的不給力。從他們的移動客戶端效能監控資料來看,傳統CDN的優化效果非常不明顯,所以他希望有一個對行動網路支援更好的、特殊的移動CDN網路。

對於傳統CDN在無線網路上的效果,Ilya認為人們普遍有兩種誤解:1、傳統CDN對移動客戶端和對寬頻網路的絕對優化效果差不多;2、這不是要不要“無線CDN”的問題,而是運營商網路的問題。

Ilya首先提供了一個參考資料,用於分析無線網路延遲的主要組成部分:

  • 客戶端位於西海岸;服務端位於東海岸。
  • 美國東西海岸之間的網路延遲是50ms。
  • 服務端的響應延遲是50ms。
  • 共享客戶端Last-mile延遲為:光纖約18ms,電纜約26ms,DSL約44ms。
  • 無線客戶端Last-mile延遲為:4G約50ms,3G約200ms。

注: Last-mile 最後一公里,通訊行業經常使用“最後一公里”來指代從通訊服務提供商的機房交換機到使用者計算機等終端裝置之間的連線。

下圖顯示使用CDN時使用者訪問流程和延遲資訊

使用一個CDN做內容分發加速

CDN加速需要在世界各地對等點的各種資料中心部署CDN快取記憶體伺服器,並儘可能的將資料部署在離使用者最近的地方。換句話說,在最理想的情況下,CDN伺服器會立即定位客戶端所在的ISP/運營商網路,客戶端發起請求,所引發的last-mile延遲時長為:客戶端斷開ISP/運營商網路和命中時CDN伺服器立即返回的響應時間。因此:

  1. CDN減少了propagation latency;
  2. 在快取了靜態資源的情況下,CDN還減少了server response time;

繼續前面的例子,假設CDN伺服器進行了網路優化配置(東海岸到西海岸的延遲時間不是50ms而是5ms)和我們請求CDN未命中源站的情況下客戶端到CDN節點的延遲是5ms。對於採用光纖的客戶端,新的總時間為last-mile往返加CDN響應時間的總和:18+5+5+5+18,即51ms。因此,增加CDN的好處就是將我們總的請求時間由186ms降低到了51ms:在總延遲上有365%的改善。

我們可以來看下不使用CDN和使用CDN加速時相關的效能資料,如下表所示:

Last-mile Coast-to-Coast (low) Server Response Total (ms) Improvement
Fiber 18 50 50 186
Cable 26 50 50 202
DSL 44 50 50 238
4G 50 50 50 250
3G 200 50 50 550
CDN + Fiber 18 5 5 51 -135 ms (365%)
CDN + Cable 26 5 5 67 -135 ms (301%)
CDN + DSL 44 5 5 103 -135 ms (231%)
CDN + 4G 50 5 5 115 -135 ms (217%)
CDN + 3G 200 5 5 415 -135 ms (133%)

採用同樣的方法重複計算每個連線的基本資訊,就可以得到一個不幸的趨勢:

  1. last-mile的延遲最高,CDN的相對有效性越差
  2. 考慮到CDN伺服器一般都放置在ISP網路之外,這就意味著節點的選擇非常有意義
  3. CDN對於改善last-mile的延遲還是有一定效果的

CDN幫助減少資料傳播和服務端響應延遲時間。如果你衡量優化前後的對比,就會發現CDN幾乎沒有做移動客戶端的優化:例如,3G使用者普遍獲得33%的優化效果。

在邊緣節點上的運營和業務維護成本

一個很明顯的策略是:移動快取伺服器到更靠近客戶的位置以提高終端到終端的延遲,而不是將節點部署在運營商網路之外。那麼,我們是否可以將節點部署在運營商內部?原則上是可以的,現在許多運營商已經部署了自己的快取伺服器。然而在現實中,存在如下問題:

  1. 對等點的數量相對比較少,CDN只能部署在世界各地眾所周知的幾十個位置。然而,移動伺服器到運營商網路內部需要與每個運營商單獨結算,所以,通常情況下,伺服器部署在共享資料中心(對等點)。
  2. 我們假設CDN已經和某個ISP達成某種協議,理想情況下儘可能將伺服器部署靠近他們的客戶(在無線電天線塔和其它訊號聚合點)的位置。這樣做將需要大量硬體裝置,這將導致維護和升級成為運維的惡夢,並開啟了一個安全問題。例如,你將要部署一個第三方的TLS終端節點來操作網路,解決你不能直接訪問網路的問題。總之,這是一個成本、安全和物流的惡夢。
  3. 許多網際網路運營商長期以來一直在嘗試提升“檔次”並提供CDN服務。然而,運營商也存在不同的問題:很難簽訂客戶,因為大多數網站對於和每個運營商單獨簽署協議絲毫不感興趣。

最近的新聞報導說Verizon收購了EdgeCast,如果能將其應用於生產環境,這將有利於Verizon的客戶解決這個問題。

除了業務和運營成本之外,CDN在移動客戶端上沒有任何特殊的優化。問題的根源在於:移動運營商的last-mile延遲是很糟糕的。這才是我們需要解決的問題,而不是推動將快取伺服器部署在靠近使用者的邊緣。我們需要公開地進行網路的優化,我們需要更多的運營商參與競爭,從根本上解決last-mile效能問題。

在國內,運營商環境更為複雜,大大小小運營商有很多家,其中以北方網通、南方電信、移動為主。但伴隨著網際網路的發展,小型運營商通過控制入口並以2、3級城市為主逐漸擴大了規模,例如:電信通、華數科技、長城寬頻等。還包括一些都會網路,這些我們通常統稱為小運營商。

由於各運營商之間存在著網間費用結算,因此運營商會想盡一切辦法將內容存在自己的網內,這就造就了現在市場上比較混亂的”劫持”,而劫持技術也是越發越”高科技”。

國內的CDN環境競爭也日益加劇,幾大CDN廠家如網宿科技、藍訊、快網、帝聯也紛紛與運營商進行合作。例如:藍汛與中國電信宣佈共建CDN網路,而網宿科技則是釋出MAA移動應用加速解決方案,正式宣佈進軍移動網際網路市場。再加上大公司自建CDN的加入,並有公司將CDN與雲服務進行整合加入競爭,使得市場愈發激烈。

環境的複雜,導致使用者訪問的問題更加難以解決。有些觀點表示,只有等到網際網路關於運營商的改革,這些局面才會得以改善,但我認為只要各大運營商與公司緊密合作,合作更加深入,使用者的訪問質量肯定會節節攀升。

相關文章