CDN的網絡架構

最近公司的網站上了一個CDN加速功能。對我們一個B2B網站來說。CDN加速功能的效果是否並沒有表現的淋漓盡致。開始對這個玩意真是一頭霧水。查了些資料再加上自己思考了下還是對CDN有了一個初步的理解。

 

CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是通過在現有的Internet中增加一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡"邊緣"，使用戶可以就近取得所需的內容，解決 Internet網絡擁擠的狀況，提高用戶訪問網站的響應速度。從技術上全面解決由於網絡帶寬小、用戶訪問量大、網點分佈不均等原因所造成的用戶訪問網站響應速度慢的問題。 (也就是一個服務器的內容，平均分部到多個服務器上，服務器智能識別，讓用戶獲取離用戶最近的服務器，提高速度。

 

其實最讓自己能受益的還是淘寶覈實團隊網站上的兩篇文章。先直接轉載過來：

 

CDN全局流量調度算法介紹

摘要

本文主要介紹了CDN全局流量調度系統。首先給出了全局流量調度系統的基本流程和設計目標，然後簡述了現有的流量調度系統的工作原理和方式，重點闡述了三種新開發的全局流量調度算法：基於負載能力的調度算法、基於鏈路的調度算法和基於成本的調度算法。

一、流量調度的基本流程

目前CDN系統流量調度是通過DNS解析來實現的，其基本原理如下圖1所示。

用戶想要訪問某個圖片的url，分爲四步：

1、用戶來自某個區域（如Beijing TelCom）的用戶，想訪問特定Url（如http://www.taobao.com/001.jpg），應該去哪個IP地址訪問
2、TGTM根據鏈路信息、成本信息或節點負載信息等因素，決定讓該區域的用戶訪問CDN 1節點
3、用戶根據DNS解析返回的IP地址訪問CDN 1節點，並請求該圖片的內容
4、CDN1節點接收並處理用戶的請求，然後將客戶請求的圖片返回

上面的流程是在用戶的瀏覽器或者LDNS(Local DNS)沒有對DNS解析結果進行緩存的情況下的流程，對於有緩存的系統，瀏覽器會從緩存中取到域名解析結果，因此流量調度策略無法影響已經緩存了DNS解析結果的用戶請求，這部分請求對應的訪問流量並不受調度系統的指揮，這對流量調度系統有一定的影響。

二、調度目標

CDN系統目前承載者淘寶網大約90%的流量，全局流量調度系統需要解決的問題是如何將如此大的訪問流量合理分配到分佈在各地的CDN邊緣節點。

對於全局流量調度系統而言，設計目標有兩個：

(1)提升用戶體驗
(2)節約系統成本

這兩個目標本身都包含很多的方面，但提取其最核心的要求，分別對應

(1)降低用戶訪問CDN節點的延遲
(2)降低CDN節點的帶寬成本

本文的內容就是圍繞這兩個目標來介紹的。

三、現有調度策略介紹

現有的CDN全局流量調度是通過商用的F5 BigIP GTM(以前稱爲3DNS)來實現的。F5的系統提供了Round Robin等12種局域負載均衡算法和Global Availability等15種廣域負載均衡算法，其中這些負載均衡算法按照調度策略是靜態配置還是動態生成的分爲靜態調度方法和動態調度算法。具體的內容參考F5網站上的相關文檔 F5 Networks

目前淘寶CDN系統的流量調度採用的是Topology+ratio的策略，下面對該調度策略進行具體介紹。

3.1 基本概念介紹

下面的概念摘自百科上易統整理的文檔GSLB概念介紹

• CIDR

  Classless InterDomain Routing ，是一種爲解決地址耗盡，提高地址的利用效率而提出的一種措施 218.30.29.0/25 218.30.28.0/25 218.30.27.0/25 218.30.26.0/2

• Region

  一組CIDR組合後的名稱，主要是爲了配置和檢索方便 region_db user { region { name “CDN_WangSu” “FujianTelcom” “GansuTelcom” “HainanNetcom } region { name “FujianTelcom” 218.85.157.0/24 220.162.0.0/16 211.148.224.0/19 220.160.0.0/15 }

• Topology

  用於管理從Region到Pool之間的映射關係
  topology {
  // server ldns score
  pool.”img01_WangSu_pool” user.”CDN_WangSu” 900
  pool.”img02_WangSu_pool” user.”CDN_WangSu” 900
  pool.”img03_WangSu_pool” user.”CDN_WangSu” 900
  pool.”img04_WangSu_pool” user.”CDN_WangSu” 900
  pool.”img01_guangdongtel_pool” user.” TB_CDN_GZ_1_MB ” 900
  pool.”img02_guangdongtel_pool” user.” TB_CDN_GZ_1_MB ” 900
  }

• WideIP

  客戶在使用CDN服務後將域名CNAME給CDN服務提供商的域名如image.sohu.com是用戶的域名，在使用CDN服務後會CNAME到image.sohu.chinacache.net，後者就被稱爲wideip
  wideip {
  name “img02.gslb.taobao.com”
  pool_lbmode topology
  partition “Common”
  last resort
  pool “img02_tel_pool”
  pool “img02_southcnc_pool”
  pool “img02_northcnc_pool
  }

• Pool

  爲wideip服務的一組VIP或CNAME的集合
  pool {
  name “img02_southcnc_pool”
  ttl 300
  monitor all “tcp”
  preferred rr
  partition “Common”
  member 218.108.237.202:80
  member 218.108.237.212:80
  }

• member

  供Pool調度的基本元素，在CDN系統中，member用於表示一個CDN節點
  member 218.108.237.202:80

• VIP

  Virtual IP 配置在四層交換上的公網IP和端口的組合，通過地址映射對應四層交換後一臺或多臺內網設備如果沒有四層交換，可以借指設備上直接配置的公網IP和端口的組合與member元素相對應

3.2 基本對象之間的關係

上述基本對象的關係如下圖所示

• WideIP概念

• Region，CIDR 之間關係圖

• WideIP,Pool,member之間的關係

• Pool和Region之間的Topology映射

3.3 現有的流量調度方法

現有的系統工作流程是這樣的：
（1）管理員根據經驗預先設置好用戶區域的拓撲關係，並通過設置Topology定義好爲各個區域服務的Pool
（2）當一個DNS解析請求到達時，調度系統根據用戶LDNS的IP地址來判斷出該用戶所在區域，然後根據Topology的設定找出爲該區域服務的Pool
（3）當Pool中有多個member時，所有到達該pool的請求按照各個member的ratio值來進行分配。例如，系統中有3個member，其ratio分別爲100,100,200，則到達該pool的所有請求將按照25%,25%和50%的比例分配到各個member

上述策略總體上可以看成一種靜態的調度策略，當系統中出現節點不可用、節點過載或者特定區域訪問對應的節點延遲過大等情況時，只能等到管理員發現後對配置文件進行一定的調整之後才能解決。

四、新的流量動態調度算法

根據文中第二部分提出的調度算法設計目標，爲當前系統設計了三種動態調度算法，分別是基於負載的調度算法，基於鏈路的調度算法和基於成本的調度算法。綜合考慮鏈路、成本和負載的調度算法尚未進行設計和實現。

4.1 基於負載的調度算法

4.1.1 算法原理介紹

基於負載的調度算法是最早實現的一種調度算法，考慮的是在一組節點服務特定區域的用戶時，用戶訪問這些節點的鏈路狀況接近、節點的帶寬成本也接近的前提下，如何保證訪問這些節點的流量在各個節點之間按照節點的實時負載能力來分配。

舉個例子來說，假設上海地區的電信用戶訪問cn12和cn15的鏈路狀況類似，cn12和cn15的帶寬成本也接近，如何將上海地區電信用戶的訪問流量按照cn12、cn15的實時負載能力來進行分配，以保證兩個節點的負載相對於其負載能力來說是均衡的。

基於負載的流量調度算法採用的是負反饋調度算法。負反饋是一種基於偏差的調度算法，簡而言之，當系統輸出同期望值不相等時，控制系統根據系統輸出和期望值之間的偏差來對系統施加控制作用，負反饋調度算法的框圖如下圖所示

• 當輸出大於期望值時，偏差爲正，這時給系統一個負的控制量u（減小系統輸出）
• 當輸出小於期望值時，偏差爲負，這時給系統一個正的控制量u（增大系統輸出）

可以看出，系統的控制量同偏差是一種負反饋的關係。

應用到基於負載的調度算法中來，當分配給某個節點的流量同其負載能力相比偏小時（偏差爲負），我們應該增大分配給該節點的流量，反之，則減小分配給該節點的流量。

4.1.2 調度算法實現

基於負載的調度算法是建立在能夠獲取節點的服務質量（QOS）的前提下，因此如何獲取節點的實時QOS是首先必須解決的一個問題。

目前CDN系統是通過部署在CDN節點內部的監控系統來獲取節點的實時QOS數據。QOS數據中最重要的兩項是節點的當前負載和節點的最大可用負載能力。節點的當前負載是通過統計交換機的出口流量得到的，而最大可用負載則是根據各緩存服務器的健康狀況得出的。

調度系統通過監控系統提供的Web Services接口實時查詢各個CDN節點的當前性能狀況，然後根據負反饋調度算法生成流量分配策略。

在一定誤差範圍內保持同一個pool內所有節點的ratio之和固定，記爲
RATIO_SUM，
設節點i的當前流量爲
cur_loadi
系統內當前的總流量爲
sumi=1-n(cur_load)
並設第i個ECC節點當前的負載能力（即上述的max_usable_load）記爲
max_usable_loadi，
pool內所有節點的當前負載能力之和記爲
sumi=1-n(max_usable_load)
則i節點在系統內應分擔的負載流量比例記爲
proportioni=max_usable_loadi/sumi=1-n(max_usable_load)
按照節點的當前負載能力，節點i的期望ratio是
ratioie=RATIO_SUM*proportioni
節點i的當前期望負載應爲
cur_loadie=sumi=1-n(cur_load)*proportioni
節點i的實際負載與期望負載的偏差爲
diffi=cur_loadi-cur_loadie
節點i當前ratio的調整值爲
delta_ratioi = -P*diffi/sumi=1-n(cur_load)*RATIO_SUM
同時，爲了防止流量調節過程中各節點流量出現劇烈顛簸，設置各節點ratio的調節範圍爲
[(1-Th)*ratioie, (1+Th)*ratioie]
總結一下：

ratio(n+1) = ratio(n) + delta_ratioi
= ratio(n)-P*diffi/sumi=1-n(cur_load)*RATIO_SUM
= ratio(n)-P*(cur_loadi-cur_loadie)/sumi=1-n(cur_load)*RATIO_SUM
= ratio(n)-P*(cur_loadi-sumi=1-n(cur_load)*proportioni)/sumi=1-n(cur_load)*RATIO_SUM
= ratio(n)-P*(cur_loadi-sumi=1-n(cur_load)*(max_usable_loadi/sumi=1-n(max_usable_load)))/sumi=1-n(cur_load)*RATIO_SUM
上式中的P爲負反饋比例係數，可以控制負載得到期望值的時間，P越大，（在一定誤差範圍內）達到期望值的時間越短，同時系統流量的波動也越大。P過大甚至可能造成系統的不穩定。

if(ratio(n+1) = (1+Th)*ratioie)
{
ratio(n+1) = (1+Th)*ratioie;
}

4.2 基於鏈路的調度算法

4.2.1 總體介紹

基於鏈路的調度算法的最終目標是使得全網內各區域用戶訪問淘寶的延遲最小，這個問題是一個最優化的問題，實際解決起來很困難，只能隨着對系統瞭解的不斷深入，逐步優化算法。

目前基於鏈路的調度算法的目標是儘量保證用戶訪問淘寶的延遲在給定的閾值之內，也就是說，調度的目標是對訪問延遲提供一定的保證，但並不能做到最優。

基於鏈路的基本思想是將鏈路延遲超過閾值的流量調度到鏈路延遲較好的鏈路上去，以確保所有區域的用戶訪問鏈路延遲都較好。

同基於負載的調度算法類似，基於鏈路的調度算法需要節點和網絡的QOS數據，這裏除了需要獲取各個節點的當前負載、最大可用負載數據之外，還需要獲得特定區域訪問CDN節點的鏈路延遲。

各個節點的當前負載、最大可用負載等QOS數據依然是通過部署在節點內部的監控系統獲取的，而各區域用戶訪問CDN節點的鏈路延遲數據則是通過淘寶的客戶端鏈路探測工具Aliprobe的探測結果統計得到的。

目前鏈路探測的最主要數據有ping time和ping命令的丟包率，而區域和節點之間的鏈路信息則是通過綜合部署在指定區域的所有Aliprobe探測客戶端獲取的訪問指定節點的鏈路信息統計、綜合得到的。

在基於鏈路的調度算法中，我們對每一個感興趣的調度區域，根據其地理位置和系統運維經驗爲其指定一個默認的服務節點和一組備選的服務節點，並將這些節點組成一個pool，該pool專門爲該區域的用戶服務。

基於鏈路的調度算法必須考慮到下列異常情況：
（1）CDN節點的當前負載、最大可用負載等負載類QOS數據無法獲取
（2）區域到節點的鏈路QOS數據無法獲取
（3）節點不可用
（4）節點過載

4.2.2 算法的實現

基於鏈路的調度算法流程如下：

Step 1 調度週期開始，嘗試獲取節點的健康狀況檢查結果、節點類的負載類QOS數據、區域同節點之間的鏈路類QOS數據

Step 2 遍歷所有感興趣的區域

2.1) 將當前區域的備選節點分爲以下四類：

class 1: good 節點健康、鏈路類QOS數據能得到並且鏈路延遲沒有超過給定閾值、負載類QOS數據能得到、節點沒有超載（所有good節點中鏈路延遲最小的一個節點叫做最佳備選節點）
class 2: bad 節點健康，鏈路類QOS數據能得到並且鏈路延遲超過給定閾值
class 3: unhealthy 節點不健康
class 4: other 不屬於上面三類的節點

2.2） 處理區域的默認節點
2.2.1 如果默認節點不健康，則嘗試將默認節點的所有流量調度到備選節點中
2.2.1.1 如果該區域有good備選節點存在，則將默認節點的流量均分到所有good備選節點
2.2.1.2 否則，報警
2.2.2 如果區域用戶訪問默認節點的鏈路不佳，則嘗試將默認節點的一小部分流量（比例可配）調度到最佳備選節點中
2.2.2.1 如果該區域存在最佳備選節點，將默認節點的一小部分流量調度到該最佳備選節點
2.2.2.2 否則，報警

2.3） 處理區域的多個備選節點
2.3.1） 如果備選節點不健康
2.3.1.1） 如果默認節點可以接收更多的流量，則將不健康節點的流量都切到默認節點上，否則轉下一步
2.3.1.2） 如果存在good備選節點，則將不健康節點的流量均分到good備選節點上，否則轉下一步
2.3.1.3） 報警
2.3.2） 如果備選節點鏈路不好
2.3.2.1） 如果默認節點可以接收更多的流量，則將不健康節點流量的一部分切到默認節點上，否則轉下一步
2.3.2.2） 如果存在最佳備選節點，則將不健康節點流量的一部分切到最佳備選節點上，否則轉下一步
2.3.2.3） 否則，報警
2.3.3） 如果默認節點能夠接受更多的流量
2.3.3.1） 如果存在good備選節點，則將所有good備選節點的部分流量切回默認節點
2.3.3.2） 如果存在other備選節點，則將所有other備選節點的部分流量切回默認節點

Step 3 遍歷所有過載節點

對於每一個過載節點，首先報警，然後找出其所服務區域中所有不以該節點爲默認節點的區域，嘗試將區域流量的一部分切回區域對應的默認節點。如果找不到不以該節點爲默認節點的區域，則報警

Step 4 開始新一輪的調度，轉Step 1

其中， Step 2中根據鏈路延遲進行調度的流程如下圖所示：

4.2.3 算法存在的問題

目前系統無法得知某一區域用戶的訪問流量值，所以在本調度算法中將區域訪問流量在節點之間調度時的具體流量值是無法得到的，爲了防止調度過程中流量出現大的波動，每個調度週期調度的流量都會很小，但調度幅度小必然導致調度效果顯現的時間會比較長。

另外，目前基於鏈路的調度算法中會有一個比較關鍵的閾值（最大延遲，超過該閾值會認爲鏈路差，否則認爲鏈路好），該閾值是通過經驗設置的，但實際上這個值在不同的時間段，不同的網絡狀況下應該是不同的，並且應該隨着時間的變化而變化，該閾值的設置仍有較大的改進空間。

4.3 基於成本的調度算法

4.3.1 CDN節點的帶寬成本模型

CDN的帶寬成本可以分成保底帶寬和流量成本兩部分。其中保底帶寬指的是隻要使用該節點就必須支付的費用，而流量成本指的是在保底帶寬之上，按照實際使用的流量來支付費用。節點的帶寬成本模型如下圖所示：

4.3.2 算法設計和實現

基於成本的調度算法的目標是使得系統的帶寬成本最小，這裏採用的貪婪算法來實現流量的調度

算法簡述如下：

（1）如果系統當前總的流量小於所有節點的保底帶寬之和，則將流量按照各節點的保底帶寬佔所有保底帶寬之和的比來分配流量
（2）如果系統當前流量大於所有節點的保底帶寬之和，則首先將所有節點的保底帶寬使用滿，然後依次選取各節點中帶寬成本最低的節點，將該節點的負載能力用完爲止。

算法流程如下圖所示：

在實際實現時，由於調度過程中流量有可能出現波動，所以必須保證出現波動時不會出現問題。舉例來說，如果某一節點的保底帶寬是1G，如果分配給該節點的流量就是1G，但由於流量出現波動，就會出現除了需要支付保底帶寬費用之外，還需要支付一部分超出保底帶寬的費用，這是我們所不希望看到的。因此，我們在處理保底帶寬和階梯價格上限時留有一定的裕量。

五、總結

文中首先簡要介紹了CDN全局流量調度系統的一些基本概念和基於DNS解析的流量調度實現方法，給出了CDN系統全局流量調度的目標，然後描述了現有流量調度系統的工作方式，重點介紹了三種新開發的全局動態流量調度算法：基於負載能力的調度算法、基於鏈路的調度算法和基於成本的調度算法。

調度算法的優化是一個持續的過程，現有的調度算法在準確性和最優性方面有一些欠缺，需要做更進一步的工作。

 

/******************************************************************/

CDN技術介紹

背景

Internet的高速發展，給人們的工作和生活帶來了極大的便利，對Internet的服務品質和訪問速度要求越來越 高，雖然帶寬不斷增加，用戶數量也在不斷增加，受Web服務器的負荷和傳輸距離等因數的影響，響應速度慢還是經常抱怨和困擾。解決方案就是在網絡傳輸上利 用緩存技術使得Web服務數據流能就近訪問，是優化網絡數據傳輸非常有效的技術，從而獲得高速的體驗和品質保 證。

網絡緩存技術，其目的就是減少網絡中冗餘數據的重複傳輸，使之最小化，將廣域傳輸轉爲本地或就近訪問。互聯網上傳遞的內容，大部分爲重複的Web/FTP數據，Cache服 務器及應用Caching技術的網絡設備，可大大優化數據鏈路性能，消除數據峯值訪問造成的結點設備阻塞。Cache服務器具有緩存功能，所以大部分網頁 對象(Web page object)，如html， htm， php等頁面文件，gif，tif，png，bmp等圖片文件，以及其他格式的文件，在有效期(TTL)內，對於重複的訪問，不必從原始網站重新傳送文件 實體， 只需通過簡單的認證(Freshness Validation)- 傳送幾十字節的Header，即可將本地的副本直接傳送給訪問者。由於緩存服務器通常部署在靠近用戶端，所以能獲得近似局域網的響應速度，並有效減少廣域 帶寬的消耗。據統計，Internet上超過80%的用戶重複訪問20%的信息資源，給緩存技術的應用提供了先決的條件。緩存服務器的體系結構與Web服 務器不同，緩存服務器能比Web服務器獲得更高的性能，緩存服務器不僅能提高響應速度，節約帶寬，對於加速Web服務器，有效減輕源服務器的負荷是非常有 效的。

高速緩存服務器(Cache Server)是軟硬件高度集成的專業功能服務器，主要做高速緩存加速服務，一般部署在網絡邊緣。根據加速對象不同，分爲客戶端加速和服務器加速，客戶端 加速Cache部署在網絡出口處，把常訪問的內容緩存在本地，提高響應速度和節約帶寬;服務器加速，Cache部署在服務器前端，作爲Web服務器的前置 機，提高Web服務器的性能，加速訪問速度。如果多臺Cache加速服務器且分佈在不同地域，需要通過有效地機制管理Cache網絡，引導用戶就近訪問， 全局負載均衡流量，這就是CDN內容傳輸網絡的基本思想。

什麼是CDN?

CDN的全稱是Content Delivery Network，即內容分發網絡。其目的是通過在現有的Internet中增加一層新的網絡架構，將網站的內容發佈到最接近用戶的網絡”邊緣”，使用戶可 以就近取得所需的內容，解決Internet網絡擁塞狀況，提高用戶訪問網站的響應速度。從技術上全面解決由於網絡帶寬小、用戶訪問量大、網點分佈不均等 原因，解決用戶訪問網站的響應速度慢的根本原因。

狹義地講，內容分發佈網絡(CDN)是一種新型的網絡構建方式，它是爲能在傳統的IP 網發佈寬帶豐富媒體而特別優化的網絡覆蓋層;而從廣義的角度，CDN代表了一種基於質量與秩序的網絡服務模式。簡單地說，內容發佈網(CDN)是一個經策 略性部署的整體系統，包括分佈式存儲、負載均衡、網絡請求的重定向和內容管理4個要件，而內容管理和全局的網絡流量管理(Traffic Management)是CDN的核心所在。通過用戶就近性和服務器負載的判斷，CDN確保內容以一種極爲高效的方式爲用戶的請求提供服務。總的來說，內 容服務基於緩存服務器，也稱作代理緩存(Surrogate)，它位於網絡的邊緣，距用戶僅有”一跳”(Single Hop)之遙。同時，代理緩存是內容提供商源服務器(通常位於CDN服務提供商的數據中心)的一個透明鏡像。這樣的架構使得CDN服務提供商能夠代表他們 客戶，即內容供應商，向最終用戶提供儘可能好的體驗，而這些用戶是不能容忍請求響應時間有任何延遲的。據統計，採用CDN技術，能處理整個網站頁面的 70%～95%的內容訪問量，減輕服務器的壓力，提升了網站的性能和可擴展性。

與目前現有的內容發佈模式相比較，CDN強調了網絡在內 容發佈中的重要性。通過引入主動的內容管理層的和全局負載均衡，CDN從根本上區別於傳統的內容發佈模式。在傳統的內容發佈模式中，內容的發佈由ICP的 應用服務器完成，而網絡只表現爲一個透明的數據傳輸通道，這種透明性表現在網絡的質量保證僅僅停留在數據包的層面，而不能根據內容對象的不同區分服務質 量。此外，由於IP網的”盡力而爲”的特性使得其質量保證是依靠在用戶和應用服務器之間端到端地提供充分的、遠大於實際所需的帶寬通量來實現的。在這樣的 內容發佈模式下，不僅大量寶貴的骨幹帶寬被佔用，同時ICP的應用服務器的負載也變得非常重，而且不可預計。當發生一些熱點事件和出現浪涌流量時，會產生 局部熱點效應，從而使應用服務器過載退出服務。這種基於中心的應用服務器的內容發佈模式的另外一個缺陷在於個性化服務的缺失和對寬帶服務價值鏈的扭曲，內 容提供商承擔了他們不該幹也幹不好的內容發佈服務。

縱觀整個寬帶服務的價值鏈，內容提供商和用戶位於整個價值鏈的兩端，中間依靠網絡服務提供商將其串接起來。隨着互聯網工業的成熟和商業模式的變革， 在這條價值鏈上的角色越來越多也越來越細分。比如內容/應用的運營商、託管服務提供商、骨幹網絡服務提供商、接入服務提供商等等。在這一條價值鏈上的每一 個角色都要分工合作、各司其職才能爲客戶提供良好的服務，從而帶來多贏的局面。從內容與網絡的結合模式上看，內容的發佈已經走過了ICP的內容(應用)服 務器和IDC這兩個階段。IDC的熱潮也催生了託管服務提供商這一角色。但是，IDC並不能解決內容的有效發佈問題。內容位於網絡的中心並不能解決骨幹帶 寬的佔用和建立IP網絡上的流量秩序。因此將內容推到網絡的邊緣，爲用戶提供就近性的邊緣服務，從而保證服務的質量和整個網絡上的訪問秩序就成了一種顯而 易見的選擇。而這就是內容發佈網(CDN)服務模式。CDN的建立解決了困擾內容運營商的內容”集中與分散”的兩難選擇。無疑對於構建良好的互聯網價值鏈 是有價值的，也是不可或缺的。

CDN新應用和客戶

目前的CDN服務主要應用於證券、金融保險、ISP、ICP、 網上交易、門戶網站、大中型公司、網絡教學等領域。另外在行業專網、互聯網中都可以用到，甚至可以對局域網進行網絡優化。利用CDN，這些網站無需投資昂 貴的各類服務器、設立分站點，特別是流媒體信息的廣泛應用、遠程教學課件等消耗帶寬資源多的媒體信息，應用CDN網絡，把內容複製到網絡的最邊緣，使內容 請求點和交付點之間的距離縮至最小，從而促進Web站點性能的提高，具有重要的意義。CDN網絡的建設主要有企業建設的CDN網絡，爲企業服務;IDC的 CDN網絡，主要服務於IDC和增值服務;網絡運營上主建的CDN網絡，主要提供內容推送服務;CDN網絡服務商，專門建設的CDN用於做服務，用戶通過 與CDN機構進行合作，CDN負責信息傳遞工作，保證信息正常傳輸，維護傳送網絡，而網站只需要內容維護，不再需要考慮流量問題。

CDN能夠爲網絡的快速、安全、穩定、可擴展等方面提供保障。

IDC建立CDN網絡，IDC運營商一般需要有分部各地的多個 IDC中心，服務對象是託管在IDC中心的客戶，利用現有的網絡資源，投資較少，容易建設。例如某IDC全國有10個機房，加入IDC的CDN網絡，託管 在一個節點的Web服務器，相當於有了10個鏡像服務器，就近供客戶訪問。寬帶城域網，域內網絡速度很快，出城帶寬一般就會瓶頸，爲了體現城域網的高速體 驗，解決方案就是將Internet網上內容高速緩存到本地，將Cache部署在城域網各POP點上，這樣形成高效有序的網絡，用戶僅一跳就能訪問大部分 的內容，這也是一種加速所有網站CDN的應用。

CDN 的工作原理

在描述CDN的實現原理，讓我們先看傳統的未加緩存服務的訪問過程，以便了解CDN緩存訪問方式與未加緩存訪問方式的差別:

由上圖可見，用戶訪問未使用CDN緩存網站的過程爲:

1. 用戶向瀏覽器提供要訪問的域名;
2. 瀏覽器調用域名解析函數庫對域名進行解析，以得到此域名對應的IP地址;
3. 瀏覽器使用所得到的IP地址，域名的服務主機發出數據訪問請求;
4. 瀏覽器根據域名主機返回的數據顯示網頁的內容。

通過以上四個步驟，瀏覽器完成從用戶處接收用戶要訪問的域名到從域名服務主機處獲取數據的整個過程。CDN網絡是在用戶和服務器之間增加Cache層， 如何將用戶的請求引導到Cache上獲得源服務器的數據，主要是通過接管DNS實現，下面讓我們看看訪問使用CDN緩存後的網站的過程:

通過上圖，我們可以瞭解到，使用了CDN緩存後的網站的訪問過程變爲:

1. 用戶向瀏覽器提供要訪問的域名;
2. 瀏覽器調用域名解析庫對域名進行解析，由於CDN對域名解析過程進行了調整，所以解析函數庫一般得到的是該域名對應的CNAME記錄，爲了得到實 際IP地址，瀏覽器需要再次對獲得的CNAME域名進行解析以得到實際的IP地址;在此過程中，使用的全局負載均衡DNS解析，如根據地理位置信息解析對 應的IP地址，使得用戶能就近訪問。
3. 此次解析得到CDN緩存服務器的IP地址，瀏覽器在得到實際的IP地址以後，向緩存服務器發出訪問請求;
4. 緩存服務器根據瀏覽器提供的要訪問的域名，通過Cache內部專用DNS解析得到此域名的實際IP地址，再由緩存服務器向此實際IP地址提交訪問請求;
5. 緩存服務器從實際IP地址得得到內容以後，一方面在本地進行保存，以備以後使用，二方面把獲取的數據返回給客戶端，完成數據服務過程;
6. 客戶端得到由緩存服務器返回的數據以後顯示出來並完成整個瀏覽的數據請求過程。

通過以上的分析我們可以得到，爲了實現既要對普通用戶透明(即加入緩存以後用戶客戶端無需進行任何設置，直接使用被加速網站原有的域名即可訪問)，又要 在爲指定的網站提供加速服務的同時降低對ICP的影響，只要修改整個訪問過程中的域名解析部分，以實現透明的加速服務，下面是CDN網絡實現的具體操作過程。

1. 作爲ICP，只需要把域名解釋權交給CDN運營商，其他方面不需要進行任何的修改;操作時，ICP修改自己域名的解析記錄，一般用cname方式指向CDN網絡Cache服務器的地址。
2. 作爲CDN運營商，首先需要爲ICP的域名提供公開的解析，爲了實現sortlist，一般是把ICP的域名解釋結果指向一個CNAME記錄;
3. 當需要進行sorlist時，CDN運營商可以利用DNS對CNAME指向的域名解析過程進行特殊處理，使DNS服務器在接收到客戶端請求時可以根據客戶端的IP地址，返回相同域名的不同IP地址;
4. 由於從cname獲得的IP地址，並且帶有hostname信息，請求到達Cache之後，Cache必須知道源服務器的IP地址，所以在CDN運營商內部維護一個內部DNS服務器，用於解釋用戶所訪問的域名的真實IP地址;
5. 在維護內部DNS服務器時，還需要維護一臺授權服務器，控制哪些域名可以進行緩存，而哪些又不進行緩存，以免發生開放代理的情況。

CDN的技術手段

實現CDN的主要技術手段是高速緩存、鏡像服務器。可工作於DNS解析或HTTP重定向兩種方式，通過Cache服務器，或異地的鏡像站點 完成內容的傳送與同步更新。DNS方式用戶位置判斷準確率大於85%，HTTP方式準確率爲99%以上;一般情況，各Cache服務器羣的用戶訪問流入數 據量與Cache服務器到原始網站取內容的數據量之比在2:1到3:1之間，即分擔50%到70%的到原始網站重複訪問數據量(主要是圖片，流媒體文件等 內容);對於鏡像，除數據同步的流量，其餘均在本地完成，不訪問原始服務器。

鏡像站點(Mirror Site)服務器是我們經常可以看到的，它讓內容直截了當地進行分佈，適用於靜態和準動態的數據同步。但是購買和維護新服務器的費用較高，另外還必須在各 個地區設置鏡像服務器，配備專業技術人員進行管理與維護。大型網站在隨時更新各地服務器的同時，對帶寬的需求也會顯著增加，因此一般的互聯網公司不會建立 太多的鏡像服務器。

高速緩存手段的成本較低，適用於靜態內容。Internet的統計表明，超過80%的用戶經常訪問的是20%的網站 的內容，在這個規律下，緩存服務器可以處理大部分客戶的靜態請求，而原始的WWW服務器只需處理約20%左右的非緩存請求和動態請求，於是大大加快了客戶 請求的響應時間，並降低了原始WWW服務器的負載。根據美國IDC公司的調查，作爲CDN的一項重要指標-緩存的市場正在以每年近100%的速度增長，全 球的營業額在2004年將達到45億美元。網絡流媒體的發展還將剌激這個市場的需求。

CDN的網絡架構

CDN網絡架構主要由兩大部分，分爲中心和邊緣兩部分，中心指CDN網管中心和DNS重定向解析中心，負責全局負載均衡，設備系統安裝在管理中心機房，邊緣主要指異地節點，CDN分發的載體，主要由Cache和負載均衡器等組成。

當用戶訪問加入CDN服務的網站時，域名解析請求將最終交給全局負載均衡DNS進行處理。全局負載均衡DNS通過一組預先定義好的策略，將當時最接近用 戶的節點地址提供給用戶，使用戶能夠得到快速的服務。同時，它還與分佈在世界各地的所有CDNC節點保持通信，蒐集各節點的通信狀態，確保不將用戶的請求 分配到不可用的CDN節點上，實際上是通過DNS做全局負載均衡。

對於普通的Internet用戶來講，每個CDN節點就相當於一個放置在它周圍的WEB。通過全局負載均衡DNS的控制，用戶的請求被透明地指向離他最近的節點，節點中CDN服務器會像網站的原始服務器一樣，響應用戶的請求。由於它離用戶更近，因而響應時間必然更快。

每個CDN節點由兩部分組成:負載均衡設備和高速緩存服務器

負載均衡設備負責每個節點中各個Cache的負載均衡，保證節點的工作效率;同時，負載均衡設備還負責收集節點與周圍環境的信息，保持與全局負載DNS的通信，實現整個系統的負載均衡。

高速緩存服務器(Cache)負責存儲客戶網站的大量信息，就像一個靠近用戶的網站服務器一樣響應本地用戶的訪問請求。

CDN的管理系統是整個系統能夠正常運轉的保證。它不僅能對系統中的各個子系統和設備進行實時監控，對各種故障產生相應的告警，還可以實時監測到系統中 總的流量和各節點的流量，並保存在系統的數據庫中，使網管人員能夠方便地進行進一步分析。通過完善的網管系統，用戶可以對系統配置進行修改。

理論上，最簡單的CDN網絡有一個負責全局負載均衡的DNS和各節點一臺Cache，即可運行。DNS支持根據用戶源IP地址解析不同的IP，實現 就近訪問。爲了保證高可用性等，需要監視各節點的流量、健康狀況等。一個節點的單臺Cache承載數量不夠時，才需要多臺Cache，多臺Cache同時 工作，才需要負載均衡器，使Cache羣協同工作。