在雲端運算(氾濫)的時代，所有服務都講求加速再加速，傳統的單一伺服器(Server)服務多個用戶端(Client)的方法，在面臨行動網路用戶迅速增多，而造成大量資源索取時，無論是資料的傳輸、服務的回應時間，反而變得「緩不濟急」。
因此，CDN(Content Delivery Network，內容傳遞網路)的技術興起，正是運用雲端運算分散式計算的概念，加速資料的存取與降低伺服器端的負載。
|
|
|
傳統網路服務模式與CDN服務模式(取自Wiki) |
我們傳統的網路服務模式如上圖左，所有的用戶端都連線到伺服器上索取資源。但是，當用戶數量成長到百萬數量級時，伺服器的負擔便會開始變得重，回應時間慢，開始發生取不到資源的狀況。而這個現象若發生在向伺服主機業者租賃虛擬主機或是雲端主機的服務提供商(Service Provider, 這邊簡稱SP) 而言，可不是一個好兆頭。因為這些主機商會跟SP依照頻寬、IO數量與CPU運算量計價，代表著錢都還沒進來就開始付出昂貴的費用了，更不用說因為網路服務不穩、回應時間太慢造成客戶流失的慘劇。
因此，CDN的出現變成了這些服務提供商的救星。CDN網路主要是靠著分散在各地的(雲端)主機，就近提供這些服務提供商的用戶資源。
它有著巨量的頻寬與速度，只要服務提供商將主機網址(例如，http://www.example.com) 寄放給CDN，CDN業者的主機便會先到http://www.example.com 抓取靜態的資料(主要是圖檔、影片、一些雜七雜八肥大的線上存取函式庫等等)，然後將這些靜態資料派送給這一大群CDN網路內的主機。
因此，過沒多久，所有的CDN主機都有同樣的資料複本(如上圖右)，那麼使用者在跟這個SP提供的服務做連線時，在索取圖像、影片等資料時，會「就近」選擇最近的CDN。例如，台灣的使用者，連上某個美國的服務時，會先到新加坡的CDN主機進行存取，由於網路封包路由比較近，速度上會快很多。
這項技術已經被很多雲端服務業者採用，例如FB就是一個例子，它很多照片都是委託給akamaihd.net這個CDN來幫忙做圖床複本，所以大家在載入時便會快很多(但是安全性就…)。
有些小聰明的使用者，或許會問以下問題。
使用者的網路存取是怎麼自動連線CDN的？
有些興趣的使用者會在網路上Google一下做法，但是要有點DNS的知識才看得懂這在做啥？我就我知道的，從實務面來簡單講述一下基本流程：
- 身為服務提供者(SP)，為了降低頻寬，拿它的服務網址(例如，http://www.example.com) 去跟CDN業者申請一個帳號。
- CDN業者給他一個CDN對應domain，假設是cdnexample.cloudcdn.net 好了。
- CDN業者使用CDN主機去抓取http://www.example.com 的資料(通常是抓取圖片、影片等)
- 業者到自己的註冊網域服務提供者，加入一個CNAME(網域別名)，假設是media.example.com ，對應到cdnexample.cloudcdn.net。這樣子大家連到media.example.com時，便會到cdnexample.cloudcdn.net。
- 由於CDN業者僅只有抓取靜態資源(如圖片、影片)等，正式的動態產生頁面還是要SP的主機來做。因此，在程式的寫法上，如果是圖片、影片的資源提供，會寫成<img srcf=”media.example.com/01.png” />。如此一來，大家在讀取圖片或是影片時，會藉由media.example.com連到最近的CDN(cdnexample.cloudcdn.net) 取得資源。這樣子存取速度變會大幅提升，真正提供服務的主機其負擔便會降低不少。
再狠一點的話，就是把動態的網頁在生成時，全部做成HTML，這樣子服務的主機只要對CDN提供服務，不用對使用者用戶端提供服務。
這樣子，CDN整體概念可以描述成下面這張圖來理解：
參考資料