CDN总结之三

3 CDN分类

如何进行CDN详细的分类，可以参考四个因素进行：CDN的组成、内容分布和管理、路由重定向和性能检测。

3.1 CDN的组成

CDN结构组成很相近。在CDN结构中，基本包含了：一系列代理服务器：组成内容交付组件，其他机制：代理服务器与其结合将请求重定向到某个代理服务器，在CDN之间的交互协议。

按CDN组成进行分类的参考特性有：CDN的组织（覆盖网形式overlay/网络形式network）、服务器（源服务器/副本服务器）、关系（客户-代理服务器-源服务器/缓存代理/内部代理（缓存代理阵列/缓存代理拓扑））、内部协议（内部网络组件交互/缓存交互）、内容/服务种类（静态内容、流媒体、服务类）

3.1.1 CDN的组织

有两种构建CDN覆盖网的方式：覆盖网形式和网络式。[16]所谓的覆盖网形式，指的是在分散的网络地点中部署专门服务于特定应用的服务器和缓存，用来处理特定种类内容的分发；其中核心网络组件在内容分发中不占据主要地位。很多商用的CDN都采用这种方式。CDN提供者将内容副本发送到分散的缓存服务器，最终用户发送请求时，这些请求会被重定向到最近的CDN服务器，从而来提升web站点的响应速度。CDN提供者不会控制底层网络设施，管理简单。网络式的构造，指的是网络组件包括路由和交换机都会执行相应的代码来识别特定的应用类型，其对请求的转发基于实现定义好的规则。这种情况下，网络组件（像路由器）在服务器之前，将内容请求转发到最近的特定应用代理服务器。

3.1.2 服务器

CDN中的两类服务器是源服务器和副本服务器或者说是代理服务器。保存完整资源的地方—源服务器，其内容是有内容提供者更新的。保存资源副本的是副本服务器，在响应用户请求的时候需要进行授权。源服务器和分布式的副本服务器进行通信，从而更新其上的副本。

3.1.3 关系

CDN组件之间的关系，副本和缓存环境的关系。关系中包含的组件有：客户、代理服务器、源服务器、代理缓存和其他。这些组件进行通信，从而在CDN中复制和缓存内容。副本建立意味着在不同计算机系统中建立和维护内容的副本。包含从源服务器中将内容推送到副本服务器中。[14]另一方面，缓存意味着通过缓存来减少响应时间、减少未来网络的带宽消耗。

在CDN中，最简单的关系就是客户端、代理服务器和源服务器之间的关系。一个客户端会向代理服务器发送请求，如果代理服务器不可用，客户端会直接和源服务器通信。用户和代理服务器之间的通信是透明的，在用户看来是和源服务器通信。

之前我们讨论过，CDN可以以网络式来组建，就是说将其逻辑部署在网络组件中（例如路由和交换机），这些网络组件会将用户请求转发到服务器或代理。其中关系牵涉到客户端、网络组件和缓存服务器/代理。其中的缓存代理之间可能会通信，一个代理缓存是在应用层缓存网络对象。代理缓存中的缓存可以被多个用户同时分享。CDN中的代理缓存和ISP控制的缓存都只是缓存内容提供者的一部分内容，其余的部分还是来自于站点。

基于内部通信机制的缓存代理[17]，缓存代理服务器的组织方式为阵列结构和网状结构。阵列结构比较紧凑，一个授权的代理作为管理节点，负责和其他缓存代理节点通信。网状结构是松散结构，缓存代理节点之间是一对一的关系。缓存节点组成的网状结构中，缓存服务器作为出口，将用户的请求转发到网状中的代理节点。

3.1.4 内部协议

内容通信可以分为两类：网络组件之间的和缓存之间的。在网络组件之间的协议有：NECP（Network element control protocol）[18]、WCCP（web cache control protocol）[18]、socks[19]；缓存之间的协议有：CARP(Cache Array Routing Protocol)[20]、ICP(Internet Cache Protocol)、HTCP(Hypertext Caching Protocol)[221]和Cache Digest[22]。

NECP:在服务器和网络组件之间进行通信的轻量协议。网络组件包括：内容感知交换机和负载均衡路由器。利用该协议，网络组件能够知道服务器的可用性和能力，从而决定能否用来提供服务。同时，网络组件会收集信息用来进行负载均衡。采用TCP作为传输层协议，当服务器初始化时，通过熟知的端口和网络组件建立TCP连接。服务器和网络组件之间的消息可以是双向的。

WCCP：定义了一个或多个路由器与一个或多个web缓存之间的通信。通过一组路由器对特定的通信流进行重定向，选定的通信流会被重定向到web缓存从而增加资源利用率、减少响应时间。特定的通信流包括：用户访问WWW获得网页和地理信息。

SOCKS：在TCP和UDP中提供客户-服务器应用的结构。这个协议处于应用层和传输层之间。利用SOCKS，可在缓存代理服务器和防火墙之间建立授权的通道。

CARP：分布式缓存协议，采用了分散的代理服务器和URL哈希。

ICP：轻量级的缓存内部通信协议。缓存之间通过ICP请求/应答收集信息，用来选择合适的地方以获得对象。除了进行对象的定位，ICP消息可以用来选择副本位置。一个缓存服务器发送ICP请求给它的邻居，邻居会用ICP消息响应：如果有的话就是HIT无就是MISS。如果邻居在一定时间内未有任何响应，则视为断开或者拥塞。

3.1.5 内容/服务种类

CDN提供者能够存储第三方的内容，进行快速发送，这些内容包括：静态内容、流媒体和各种内容服务（电子商务、文件传输服务等）。不同的内容和服务有不同的应用要求、结构和技术。包含的种类有：

静态内容：静态HTML页面、图片、文件、音频文件、视频文件等。这类内容的访问频率低。所有的CND提供者都支持这种内容分发。

流媒体：流媒体分为直播和点播。

服务：CDN能够将其网络资源提供出来建立服务分发通道，从而使得增值的服务在网络架构中得到使用。目录服务是指访问数据库服务器；文件传输服务利于世界范围内软件、电影、高清图片的传输。

3.2 内容分布和管理

内容分布和管理对CDN内容分发的效率和性能至关重要。内容分布包括：代理服务器的位置（单个ISP/多个ISP）、内容的选择和分发（基于用户请求的频率和类型）、内容对外放置（协作式推送/非协作式拉取/协作式拉取）；内容管理主要依赖于缓存的组织（缓存技术/缓存更新）。

3.2.1 代理服务器位置

需要选择最合适的位置给代理服务器，其目标就是减少用户访问内容的时延、将内容从服务器传输到用户消耗的带宽减到最小。

一些理论的方法将其描述为K-中心最小化问题[23]，k-HST[23]。

代理服务器分布策略：内容分布问题、贪心策略、拓扑信息策略、热点、基于树的副本策略和可扩展的副本策略。

3.2.2 内容的选择和分发

内容分发的效率依赖于内容选择的正确性。良好的内容选择方法可以减少用户的下载时间和服务器负载。

全站点内容选择和分发。简单的方法，将源服务器整个都放置到代理服务器上。也就是说代理服务器成为了完整的副本来进行分发。在这种方法中，内容提供者配置其DNS，将所有用户的请求目的地改为存有整个副本的CDN服务器。优点就是简单，但是缺乏在大规模web对象时的可行性。

部分站点内容选择和分发。代理服务器存储部分副本，发送内置的对象（embedded object），例如：网页图片。采用该方法时，CDN提供者修改其内容，使得对特定对象的访问拥有授权CDN提供者的域名。这样，基础的HTML来源于源服务器，内置对象则来自于CDN缓存服务器。拥有更好的性能，以及更能减少服务器负载。

在部分站点内容选择的时候，还涉及到内置对象的选择，按照选择的不同，又可以细分为：经验（empirical）、热度（popularity）、对象（object）和集合（cluster）式副本。经验选取的时候，主要是合适的考虑因素。基于热度的选择，最热的对象缓存到代理服务器中，这个方法实时性要求高而且需要对象请求可靠。基于对象的方法，指的是内容以对象为单位缓存到代理服务器中，这个方法是贪心的，因为每个对象都会被缓存到代理服务器中，复杂度高。基于集合的选择方式，网页内容按照关联性分为组，这个关联性可能是基于用户浏览方式相近性的，也可能是基于URL相似度[24]的。

3.2.3 内容对外放置

主要的几种方式：协作式推送/非协作式拉取/协作式拉取。

协作式推送。这个方法基于将内容预取到代理服务器中。内容从源服务器中推送带代理服务器，代理服务器之间进行协作减少副本和更新费用。CDN会维护一个内容和代理服务器之间的映射表，每个请求会被转发到最近的代理服务器，或者被发送到源服务器。

非协作式拉取。采用这种方法，用户请求被直接转发（采用DNS重定向或URL改写[24]）到代理服务器。如果代理服务器上无相应内容，代理服务器会从源服务器中拉取内容。缺点就是服务于用户的服务器可能不是最优选择。

协作式拉取。与之前协作式的区别就是代理服务器之间在缓存没有满足请求时，会进行协作。用户请求通过DNS重定向被转发到最近代理服务器，通过一个分布式的索引，代理服务器会找到最近的副本，然后请求并保存之。

3.2.4 缓存组织

内容管理对CDN性能也很关键。缓存组织包含缓存技术、缓存更新频率，此外包括缓存整合策略。对CDN性能的改进，主要体现在时延、缓存命中率。

(1)缓存技术。分为集群内缓存和集群间缓存。

集群内缓存（intra-cluster）：又分为基于请求[25]、基于digest[26]、基于目录[27]和基于hash[28]。基于请求的方式，当发生缓存未命中的时候，会通过广播请求的方式向其他服务器获得帮助。使用该方式，需要有额外通信开销和延迟。digest-based方式克服了上一个方式的泛洪引起的额外通信和延迟，每个CDN服务器维护一个内容的摘要，所谓的摘要指的是：保存了该内容的所有代理服务器信息；这些代理服务器会受到通知对内容进行更新；通过检测摘要，CDN服务器能够将内容请求转发到特定代理服务器。该方式的缺点就是需要实现的通信沟通。基于目录的方式，一个中心化的服务器保存了在一个集群中存储内容的代理服务器信息。每个CDN服务器只有当内容更新、本地请求mis的时候才会告知该目录服务器。这可能导致目录服务器成为访问瓶颈。基于hash的方式，CDN服务器有hash功能从而进行协作。将内容URL、服务器IP通过hash将内容分配给指定CDN服务器。对特定内容的请求会直接转发给指定的CDN服务器。基于hash的方式更高效，但是对本地请求和多媒体分发上却很难做到可扩展。为了克服该缺点，产生了semi-hash-based scheme[29]。

    集群间缓存：当集群内缓存失效的时候集群间缓存很重要。基于摘要和基于目录的方式不适合了，因为CDN要维护的摘要和目录过于庞大。基于请求的方式可以应用到其中，当一个集群无法响应请求时，会向其他集群请求，如果继续mis，则请求继续泛洪；而在集群内部可以采用基于hash的方式，直接访问指定服务器。

(2)缓存更新。

在代理服务器中缓存的内容需要有一个期限，以免因源内容的更新导致不一致情况的发生。最常见的缓存更新方法是周期性更新。采用该方法，源web服务器决定缓存什么、缓存多久更新一次，缓存会按照规定的周期进行更新；可能造成不必要的通信，例如更新周期较长的内容。还有一种方法是传播式更新，当内容发生改变时，会向所有缓存发送更新版本；如果内容更新频繁，更新带来的通信量十分巨大。基于需求的更新方法，指的是当有对内容的请求时才进行更新检测，如果内容更新过了，那么新版本的内容就会被发送到代理服务器从而满足用户请求。还有一种方法是不可用，当内容发生改变的时候，源服务器向所有代理服务器发送文件改变的消息，代理服务器马上终止对其访问，并从源服务器获得最新版本的内容，然后才能满足后续的用户请求。

[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.

原文地址：点击打开链接