Google web性能優(yōu)化工程師和開發(fā)大使、《High-Performance Browser Networking》作者Ilya Grigorik近日發(fā)布了一篇名為《為什么CDN對移動客戶端加速“沒有”效果》的博客，描述了移動(無線)網(wǎng)絡的特殊性，以及如何建設一個適用于移動CDN的構想。

Ilya首先吐槽了目前的CDN在移動客戶端加速方面的不給力。從他們的移動客戶端性能監(jiān)控數(shù)據(jù)來看，傳統(tǒng)CDN的優(yōu)化效果非常不明顯，所以他希望有一個對移動網(wǎng)絡支持更好的、特殊的移動CDN網(wǎng)絡。

對于傳統(tǒng)CDN在無線網(wǎng)絡上的效果，Ilya認為人們普遍有兩種誤解：1、傳統(tǒng)CDN對移動客戶端和對寬帶網(wǎng)絡的絕對優(yōu)化效果差不多;2、這不是要不要“無線CDN”的問題，而是運營商網(wǎng)絡的問題。

Ilya首先提供了一個參考數(shù)據(jù)，用于分析無線網(wǎng)絡延遲的主要組成部分：

客戶端位于西海岸;服務端位于東海岸。

美國東西海岸之間的網(wǎng)絡延遲是50ms。

服務端的響應延遲是50ms。

共享客戶端Last-mile延遲為：光纖約18ms，電纜約26ms，DSL約44ms。

無線客戶端Last-mile延遲為：4G約50ms，3G約200ms。

注： Last-mile 最后一公里，通信行業(yè)經(jīng)常使用“最后一公里”來指代從通信服務提供商的機房交換機到用戶計算機等終端設備之間的連接。

下圖顯示使用CDN時用戶訪問流程和延遲信息

使用一個CDN做內(nèi)容分發(fā)加速

CDN加速需要在世界各地對等點的各種數(shù)據(jù)中心部署CDN高速緩存服務器，并盡可能的將數(shù)據(jù)部署在離用戶最近的地方。換句話說，在最理想的情況下，CDN服務器會立即定位客戶端所在的ISP/運營商網(wǎng)絡，客戶端發(fā)起請求，所引發(fā)的last-mile延遲時長為：客戶端斷開ISP/運營商網(wǎng)絡和命中時CDN服務器立即返回的響應時間。因此：

CDN減少了propagation latency;在緩存了靜態(tài)資源的情況下，CDN還減少了server response time;繼續(xù)前面的例子，假設CDN服務器進行了網(wǎng)絡優(yōu)化配置(東海岸到西海岸的延遲時間不是50ms而是5ms)和我們請求CDN未命中源站的情況下客戶端到CDN節(jié)點的延遲是5ms。對于采用光纖的客戶端，新的總時間為last-mile往返加CDN響應時間的總和：18+5+5+5+18，即51ms。因此，增加CDN的好處就是將我們總的請求時間由186ms降低到了51ms：在總延遲上有365%的改善。

我們可以來看下不使用CDN和使用CDN加速時相關的性能數(shù)據(jù)，如下表所示：

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網(wǎng)絡之外，這就意味著節(jié)點的選擇非常有意義

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

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

在邊緣節(jié)點上的運營和業(yè)務維護成本

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

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

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

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

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

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

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

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

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

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