CDN总结之四

3.3 路由重定向

路由重定向系统用来对用户请求转发到合适的代理节点，从而进一步进行内容分发。有的时候最近的代理节点未必就是最合适的。[30]路由转发系统通常会将一些因素例如网络上的邻接性、用户体验时延、距离、服务器负载等作为选择最合适服务器的参考。

内容的选择和分发方法对路由重定向的设计有影响。就像之前说的全站点内容选择和分发，路由重定向系统只需将请求转达到代理服务器即可，因为代理服务器存有所有的内容；当采用站点部分内容选择和分发，源服务器负责发送基本内容，而代理节点负责发送内置对象。

路由重定向系统包括两个部分：路由重定向算法和路由重定向机制。[31]路由重定向算法是当接受到用户请求时，用来选择合适边缘服务器进行响应；路由重定向机制则是在使用路由重定向算法之后，告知用户选择结果。

   如上图所示，用户对内容的请求中包含了指定的URL，请求会被发送到源服务器；源服务器接收到请求，决定自己要发送的基本内容，为了适应高带宽要求和内容访问的速率，源服务器将请求重定向到CDN提供者；采用合适的算法，CDN提供者选择合适的副本服务器作为“最近”服务器响应用户请求；副本服务器从源服务器获得内置对象，从而满足用户请求。

3.3.1 路由重定向算法

分为两类：自适应和非自适应。自适应算法考虑当前系统情况，从而选择合适缓存服务器来分发内容。当前系统情况靠的是对一些因素的考虑例如副本服务器的负载、网络连接状况。非自适应算法则是利用经验来进行选择缓存服务器而不考虑当前的具体情况。非自适应算法部署容易，自适应算法则复杂；非自适应算法运行高效，自适应算法需要系统具备健壮性。

非自适应路由重定向算法：常见的是roud-robin算法，将请求发送到CDN缓存服务器并对它们进行负载均衡[32]。该算法中，假设所有服务器拥有相似的处理能力，服务器能够处理任意请求。对于在同一地方的缓存服务器来说，这一算法简单高效，但是对于分布式系统则性能欠佳。[33]在另外的一个非自适应路由重定向算法中，所有副本服务器会通过其预测的负载进行分级。这些预测是基于服务器已经响应的用户请求数。该算法考虑了客户与服务器之间的距离，用户请求会在考虑负载均衡的情况下进行转发。采用该算法的假设就是缓存服务器的负载和用户与服务器之间的距离是影响请求响应的最主要因素。[34]还有一些其他的算法像Cisco DistributedDirector[35]；Karger提出对内容URL和服务器进行hash，隐射到同一空间，假设缓存服务器拥有超过其hash值最小的内容[36]。

自适应重定向算法：Globule[37]是一个自适应重定向算法，其通过计算网络邻接性来选择合适的缓存服务器。Globule的邻接情况是通过周期性更新路径长度获得；这样就可以把用户请求重定向到最小时延的缓存服务器。该算法具备高效性，但是由于要维护统一的网络连接DB，缺乏可扩展性。

Akamai采用的是复杂的自适应重定向算法。该算法考虑和一系列因素，包括缓存服务器的负载和带宽、用户和缓存服务器之间的负载可靠性等。

3.3.2 路由重定向机制

Global Server Load Balancing(GSLB)：采用该方法，服务节点由包含了一个GSLB网络交换机和一系列分布式的web服务器组成。服务节点拥有的两个功能使得其能够进行负载均衡：全局感知和智能授权。在GLSB中，每个服务节点都知道本地其他服务节点的负载情况和虚拟IP地址。接下来，GLSB网络交换机使得服务节点能够全局感知包括服务节点的地址。由于GLSB知道全局服务节点情况，所以能够进行合适代理节点的选择，不仅仅是选择本地服务器还包括远程服务节点；网络管理员在不增加网路设备的情况下就能使用GLSB。缺点就是需要进行服务节点的配置。

基于DNS的路由重定向：在该方法中，内容分发服务基于被修改了的DNS服务器，其保存了在代理服务器名称和其IP地址之间的一个关联（mapping），从而进行内容的分布服务。该方法用于全站点内容选择和分发。在基于DNS路由重定向中，每个域名有多个IP地址与之关联；当用户请求内容时，服务提供者的DNS服务器返回保存副本服务器的IP地址；用户DNS解析器在返回的地址列表中选择一个。为了决定选择哪一个，用户DNS解析器可能会发送探针去考察服务器的响应时间。优点就是透明性和简单性；主要的缺点就是增加了网络时延，因为增加了DNS查找的时间。CDN提供者为了克服这一缺点，通常将CDN 的DNS分为两级[38]；另外一个缺点就是没有考虑用户的IP地址。

HTTP重定向：需要缓存服务器对HTTP头部进行设定。HTTP协议允许web服务器响应用户请求时通过特殊消息告知用户重新将请求发送到其他服务器。HTTP重定向可用于全站点内容选择和分发和站点部分内容选择和分发。该机制可以建立专门的web服务器用来响应用户请求，选择合适服务器响应并使得用户将请求重新发送到缓存服务器。采用HTTP重定向需要增加外的头部。优点就是简单和适用，其次还有很好的粒度，因为每个网页可以看作一个粒度。显著的缺点就是不具备透明性。

URL重写：主要用于站点部分内容选择和分发。源服务器通过动态产生网页的URL连接，将用户请求重定向到不同代理服务器。URL的改写分为主动和被动两种方式：主动方式指的是在源服务器中就会对内置对象的URL进行改写；被动方式则是当用户请求到达源服务器的时候，才会进行改写。优点就是用户不会被绑定在固定代理服务器、具备更好的粒度；缺点就是需要进行URL分析增加时延，而且代理服务器上的内容修改无法保存。

任播：任播分为两种，一种是IP任播一种是应用级别的任播。IP任播由Partridge et al. [39]提出，对多个主机分配同一个IP，每个IP路由器在路由表中刚保存了到达该IP的最近路径。这样，不同的IP路由通过路径能够到达由统一IP表示的不同主机。IP任播可以用于路由重定向和服务定位。缺点就是必须分配IP地址用于任播。Fei et al. [40]提出了应用级任播，服务依赖于一系列的任播解析器，任播解析器在任播域名和IP地址之间建立关联。用户向任播解析器发送任播请求，任播解析器处理请求并返回响应；有一个状态数据库，保存了缓存服务器的性能。应用级组播有更好的灵活性，但是需要对客户端和服务器同时进行改造。

    对等CDN。P2P网络是在主机之间建立系统级连接。对等CDN拥有相似的行为和特性。通常内容提供者只是和一个CDN联系，然后该CDN再和其他CDN联系。对等CDN具备更好的容错性。为了方便在对等CDN中内容的定位，采用的方法有：中心化目录模型、DHT、请求泛洪模型(flooded request model)和文档路由模型（document routing model）。在中心化目录模型中，节点从中心化目录获得其它节点发布的共享内容，当有多个节点满足用户请求时，会基于一些因素（例如：网络邻接性、带宽、消耗、能力）进行选取；待从中心目录进行返回后，请求节点会和返回节点进行通信获得内容。缺点就是有单点失败，系统可扩展性差。请求泛洪模型，是将来自节点的请求泛洪给与其直接连接的节点；这些节点会继续泛洪请求，直到请求得到响应。缺点就是会产生不必要的网络通信量，需要带宽；由于受到网络大小的限制，可扩展性差。文档路由模型，请求发送给一个授权的节点进行查询。每个节点都会完善查询结果，最后查询会发送到离请求者最近的且可能响应请求的节点。优点就是步骤简单、性能也不错。

3.4 性能检测

CDN性能检测是检测CDN满足用户内容分发和服务的能力。检测主要是通过硬件和软件检测结合，主要考虑的因素有：

Ø  缓存命中率：定义为缓存内容在总请求内容中占的比例。

Ø  节省带宽：源服务器使用的带宽。

Ø  时延：用户等待的响应间隔。

Ø  代理服务器使用：指的是代理服务器保持忙碌的时间碎片。

Ø  可靠性：丢包率

4 现有CDN

4.1 商用CDN

CDN Name	服务类型	覆盖范围	产品/方案
Accellion(www.accellin.com)	大型文件分发服务	广告/媒体，医疗，制造业，高等教育=	大型文件传输的安全性；在线桌面和服务器恢复方案
Akamai(www.akamai.com)	CDN服务	占有85%市场，20000多台服务器；处理20%的互联网流量	处于网络边缘的平台处理静态和动态内容；边缘管理应用
AppStream(www.appstream.com)	提供软件分发和软件许可管理	和前1000的企业合作，以及教育机构和政府
EdgeStream(www.edgestream.com)	在公网中提供分离的视频应用	在全球范围内提供在电缆或ADSL猫连接之上的视频分发	点播和IPTV
Globix(www.globix.com)	提供互联网结构和网络服务	拥有IP骨干网；拥有将近1200用户
Limelight Networks	提供点播和直播形式的视频、音乐、游戏和下载	代理节点分布在世界的72个地区
Mirror Image	提供内容分发，流媒体，网络计算和报告服务	代理节点分布在22个国家
Netli	在NetliOne平台上提供商业级别的网络服务	主机集群分布在世界的13个城市
SyncCast	提供分发数字内容和相关数据的解决方案	图片公司、媒体产品、音乐公司

 

 

 

4.2 学术CDN

CDN Name	服务类型	覆盖范围	产品/方案
CoDeeN	提供内容的缓冲和HTTP重定向	建立在PlanetLab之上的学术内容分发测试网络
COMODIN	提供协作的多媒体服务	是一个学术的媒体CDN
Coral	提供基于内容热度的缓冲	是一个免费得对等CND
Globule	内容缓存、服务器监管、用户请求重定向到可用副本	开源的

 

 

 

 

 

参考文献：

[1]Y.Hao,L.Xuening, M.Geyong and L.Chuang. “Content Delivery Networks: A Bridge betweenEmerging Applications and Future IP Networks”, IEEE Network, July/August 2010.

[2] http://www.internetworldstats.com/top20.htm

[3]Licklider,J.C.R., and Clark, W. “On-Line-Man-Computer Communication”, Aug, 1962.

[4]M.S.Blumenthaland D.D.Clark, “Rethinking the Design of the Internet: The End-to-End argumentsvs. the Brave New World”, ACM Trans. Internet Tech, vol.1, no.1, Aug.2001,pp.70-109.

[5]A. Feldmann, “InternetClean-Slate Design: What and why?” ACM SIGCOMM Comp. Commun. Rev., vol.37,no.3, July 2007, pp.59-64.

[6]Vakali, A. and Pallis, G. “Content delivery networks: Status andtrends”. IEEE Internet Computing 7,6(Nov./Dec.2003), 68-74.

[7]G. Pallis, and A. Vakali, “Insight and Perspectives for ContentDelivery Networks”, Communications of the ACM, Vol.49, No.1, ACM Press, NY,USA, pp.101-106. Jan, 2006.

[8]M. Hofmann, and L.R.Beaumont, Content Networking: Architecture,Protocols and Practice, Morgan Kaufmann Publishers, San Fransico, CA, USA,pp.129-134, 2005.

[9]C. Huang et al. “Understanding Hybrid CDDNP2P: Why Limelight Needsits Own Red Swoosh”, Proc. NOSSDAV, May 2008, pp.75-80.

[10] M. Hofmann, and L. R. Beaumont, Content Networking: Architecture,Protocols, and Practice, Morgan Kaufmann Publishers, San Francisco, CA, USA,pp. 129-134, 2005.

[11] http://www.accustreamresearch.com/cdn.html

[12] http://www.akamai.cn/enzs/html/perspectives/index.html

[13]AkamaiTechnologies Inc., “Akamai-The Business Internet - A Predictable Platform forProfitable E-Business”, 2004.

[14] R. Brussee, H.Eertink, W. Huijsen, B. Hulsebosch, M. Rougoor, W. Teeuw, M. Wibbels, and H.Zandbelt, “Content Distribution Network State of the Art,” TelematicaInstituut, June 2001.

[15] B. Molina, C. E.Palau, and M. Esteve, “Modeling Content Delivery Networks and theirPerformance,” Computer Communications, Vol. 27, Issue 15, pp. 1401-1411,September 2004.

[16] I. Lazar, and W.Terrill, “Exploring Content Delivery Networking,” IT Professional, Vol. 3, No.4, pp. 47-49, 2001.

[17] I. Cooper, I.Melve, and G. Tomlinson, “Internet Web Replication and Caching Taxonomy,”Internet Engineering Task Force RFC 3040, January 2001. www.ietf.org/rfc/rfc3040.txt

[18] M Cieslak, DFoster, G Tiwana, and R Wilson, “Web Cache Coordination Protocol Version 2,” http://www.webcache.com/Writings/Internet-Drafts/draft-wilson-wrec-wccp-v2-00.txt

[19] M. Leech, M.Ganis, Y. Lee, R. Kuris, D. Koblas, and L. Jones, “SOCKS Protocol Version 5,”Internet Engineering Task Force RFC 1928, March 1996. www.ietf.org/rfc/rfc1928.txt

[20] V. Valloppillil,and K. W. Ross, “Cache Array Routing Protocol v1.0,” Internet Draft, February1998.

[21] P. Vixie, and D.Wessels, “Hyper Text Caching Protocol (HTCP/0.0),” Internet Engineering TaskForce RFC 2756, January 2000. www.ietf.org/rfc/rfc2756.txt

[22] M. Hamilton, A.Rousskov, and D. Wessels, “Cache Digest Specification – version 5,” December1998. http://www.squid-cache.org/CacheDigest/cache-digest-v5.txt

[23] S. Jamin, C. Jin,Y. Jin, D. Raz, Y. Shavitt, and L. Zhang, “On the placement of InternetInstrumentation,” In Proceedings of IEEE INFOCOM, Tel-Aviv, Israel, pp.295-304, March 2000.

[24] N. Fujita, Y.Ishikawa, A. Iwata, and R. Izmailov, “Coarse-grain Replica ManagementStrategies for Dynamic Replication of Web Contents,” Computer Networks: TheInternational Journal of Computer and Telecommunications

Networking, Vol.45, Issue 1, pp. 19-34, May 2004.

[25] D. Wessels, and K.Claffy, “Internet Cache Protocol (ICP) version 2,” Internet Engineering TaskForce RFC 2186, September 1997. www.ietf.org/rfc/rfc2186.txt

[26] A. Rousskov, andD. Wessels, “Cache Digests,” Computer Networks and ISDN Systems, Vol. 30, No.22-3, pp. 2155-2168, November 1998.

[27] S. Gadde, M.Rabinovich, and J. Chase, “Reduce, Reuse, Recycle: An Approach to BuildingLarge Internet Caches,” In Proceedings of 6th Workshop on Hot Topics inOperating Systems, pp.93-98, April 1997.

[28] V. Valloppillil,and K. W. Ross, “Cache Array Routing Protocol v1.0,” Internet Draft, February1998.

[29] J. Ni, and D. H.K. Tsang, “Large Scale Cooperative Caching and Application-level Multicast inMultimedia Content Delivery Networks,” IEEE Communications, Vol. 43, Issue. 5,pp. 98-105, May 2005.

[30] C. M. Chen, Y.Ling, M. Pang, W. Chen, S. Cai, Y. Suwa, O. Altintas, “Scalable Request-Routingwith Next-Neighbor Laod Sharing in Multi-Server Environments,” In Proceedingsof the 19th International Conference onAdvanced Information Networking andApplications, IEEE Computer Society, Washington, DC, USA, pp. 441-446, 2005.

[31] S.Sivasubramanian, M. Szymaniak, G. Pierre, and M. Van Steen, “Replication of WebHosting Systems,” ACM Computing Surveys, Vol. 36, No. 3, ACM Press, NY, USA,2004.

[32] L. Wang, V. S.Pai, and L. Peterson, “The Effectiveness of Request Redirection on CDNRobustness,” In Proceedings of 5th Symposium on Operating Systems Design andImplementation, Boston, MA, USA, pp. 345-360, December 2002.

[33] V.S. Pai, M. Aron,G. Banga, M. Svendsen, P. Druschel, W. Zwaenepoel, E. Nahum, “Locality-AwareRequest Distribution in Cluster-Based Network Servers,” ACM SIGPLAN Notices,Vol. 33, No. 11, ACM Press, NY, USA, pp. 205-216, 1998.

[34] A. Aggarwal, andM. Rabinovich, “Performance of Dynamic Replication Schemes for an InternetHosting Service,”Technical Report, HA6177000-981030-01-TM, AT&T ResearchLabs, Florham Park, NJ, USA, October 1998.

[35] K. Delgadillo,“Cisco DistributedDirector,” Cisco White Paper, Cisco Systems, Inc., June 1997.

[36] D. Karger, A.Sherman, A. Berkheimer, B. Bogstad, R. Dhanidina, K. Iwamoto, B. Kim, L.Matkins, and Y. Yerushalmi, “Web Caching with Consistent Hashing,” ComputerNetworks, Vol. 31, No. 11-16, pp. 1203-1213, 1999.

[37] G. Pierre, and M.van Steen, “Globule: A Collaborative Content Delivery Network,” IEEECommunications, Vol. 44, No. 8, August 2006.

[38] B. Krishnamurthy,C. Willis, and Y. Zhang, “On the Use and Performance of Content DistributionNetwork,” In Proceedings of 1st International Internet Measurement Workshop,ACM Press, pp. 169-182, 2001.

[39] C. Partridge, T.Mendez, and W. Milliken, “Host Anycasting Service,” Internet Engineering TaskForce RFC 1546, November 1993. www.ietf.org/rfc/rfc1546.txt

[40] Z. Fei, S.Bhattacharjee, E. W. Zugura, and M. H. Ammar, “A Novel Server SelectionTechnique for Improving the Response Time of a Replicated Service,” InProceedings of IEEE INFOCOM, San Francisco, California, USA, pp.783-791, March1998.

原文地址：点击打开链接