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群协同工作。