這裡解釋內容傳遞網路（CDN）對於手機在瀏覽網頁時的影響，告訴您到底該不該將 CDN 使用在手機版的網頁上。
近年來使用行動裝置瀏覽網頁的比例與日俱增，最近 Google 也針對行動裝置的網頁搜尋規則進行了調整，讓行動裝置在使用 Google 搜尋時，可以獲得更好的結果，在未來網站的設計上，除了考慮一般的桌機版本之外，手機與平板電腦的網頁也是非常重要的一環。
有些人根據實際的測試數據，推斷傳統的 CDN 對於行動裝置平台的加速效果不彰，所以希望有一個專門設計給行動裝置平台的特殊 CDN，改善現有的問題，但是其實真正的問題不是出在 CDN 本身，而是電信公司（carrier）的網路問題。
為了釐清網路延遲的問題，我們以一個比較實際的範例情況來解釋，假設：
而用戶在發出網頁請求之後到收到回應所需要的時間，就是資料來回傳遞路徑上所有延遲時間的總和，亦即「最後一哩路」→西岸到東岸 50 ms→伺服器的反應時間 50 ms→東岸到西岸 50 ms→「最後一哩路」，以光纖網路的用戶來說，總共所花費的時間就是 18 + 50 + 50 + 50 + 18 = 186 ms。
CDN 的基本原理就是讓網頁資料的地理位置盡量靠近使用者，所以許多 CDN 公司都會在全球各處的資料中心設置很多的快取（cache）伺服器，最好的狀況就是讓快取伺服器剛好設在網際網路服務提供者（ISP）或電信公司的聯外網路出口，當使用者的請求經過「最後一哩路」的延遲之後，馬上就可以經由 CDN 的快取伺服器取得資料並回傳，將 propagation latency 降到最低，並且也可以透過快取節省伺服器的反應時間。
接續上面的範例，假設 CDN 快取伺服器設置在一個不錯的位置（可將東西岸之間的 50 ms 降至 5 ms），而起可以透過快取將賜福起反應時間降至 5 ms，對於光纖網路的用戶來說，總過花費的時間就會變成 18 + 5 + 5 + 5 + 18 = 51 ms，也就是說加上 CDN 之後，整體耗費的時間從 186 ms 下降至 51 ms，降幅達 365%。
| Last-mile | Coast-to-Coast | 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%) |
這張表格是各種網路狀況的計算結果，您可以發現真正造成行動裝置用戶網路效能差異的原因來自於「最後一哩路」的延遲，不管是一般用戶或是行動裝置用戶，透過 CDN 伺服器所減少的延遲時間都是固定的。
由於 CDN 只能降低 propagation latency 與伺服器反應時間，如果您只看行動裝置用戶在使用 CDN 前後的測量結果，會發現效果不是很好（ 3G 網路只有加速 33%），但事實上問題是出在大部份電信公司的「最後一哩路」過高，讓 CDN 效果很難凸顯出來。
至於電信公司的「最後一哩路」問題，通常還是要電信公司自己來解決，或是要看電信公司如何與 CDN 之間互相配合，這些都不是一般使用者能夠處理的範圍，我們能做的就是找一家好一點的 CDN 來使用，讓 propagation latency 與伺服器反應時間盡量降低。
總而言之，不管是一般有線網路或是行動網路，CDN 還是有加速效果的，只是對於行動網路比較不明顯而已，還是可以放心使用的。
參考資料：igvita.com
