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服務器立即返回的響應時間。因此：

CDN減少了propagation latency;在緩存了靜態資源的情況下，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-mileCoast-to-Coast (low)Server ResponseTotal (ms)Improvement

Fiber185050186

Cable265050202

DSL445050238

4G505050250

3G2005050550

CDN + Fiber185551-135 ms (365%)

CDN + Cable265567-135 ms (301%)

CDN + DSL4455103-135 ms (231%)

CDN + 4G5055115-135 ms (217%)

CDN + 3G20055415-135 ms (133%)

采用同樣的方法重復計算每個連接的基本信息，就可以得到一個不幸的趨勢：

last-mile的延遲最高，CDN的相對有效性越差

考慮到CDN服務器一般都放置在ISP網絡之外，這就意味著節點的選擇非常有意義

CDN對于改善last-mile的延遲還是有一定效果的

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

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

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

對等點的數量相對比較少，CDN只能部署在世界各地眾所周知的幾十個位置。然而，移動服務器到運營商網絡內部需要與每個運營商單獨結算，所以，通常情況下，服務器部署在共享數據中心(對等點)。

我們假設CDN已經和某個ISP達成某種協議，理想情況下盡可能將服務器部署靠近他們的客戶(在無線電天線塔和其它信號聚合點)的位置。這樣做將需要大量硬件設備，這將導致維護和升級成為運維的惡夢，并打開了一個安全問題。例如，你將要部署一個第三方的TLS終端節點來操作網絡，解決你不能直接訪問網絡的問題。總之，這是一個成本、安全和物流的惡夢。

許多互聯網運營商長期以來一直在嘗試提升“檔次”并提供CDN服務。然而，運營商也存在不同的問題：很難簽訂客戶，因為大多數網站對于和每個運營商單獨簽署協議絲毫不感興趣。

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

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

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

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

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

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