基于校园网环境的ＣＤＮ架构探索与应用

刘晓龙　葛永兴　杨双阳

摘 要：由于国内各ISP之间互联互通存在网络瓶颈，极大地影响了校园网对非教育网用户访问的响应速度。目前国内商用门户网站解决这种问题主要采用CDN架构，投入巨大。如果完全按照门户网站的CDN架构来建设自己的校园网，不符合校园网实际情况。因此，本文提出了基于校园网实际环境部署CDN的应用方案，很好地消除了网络瓶颈，使外部用户得以快速访问校内资源。

关键词：CDN 网络瓶颈 校园网 响应速度

中图分类号：TP393.18 文献标识码：B 文章编号：1673-8454（2009）01-0032-04

怎样让校外，特别是非教育网用户快速地访问教育资源网站一直是我们积极探索的重点。经过多年的研究与改进，逐渐摸索出了一些适合教育网实际情况的校园网架构和访问策略，极大地提高了访问响应速度。

一、现状分析

我国目前的ISP主要有中国电信（下文简称电信）、中国网通（下文简称网通）、中国教育和科研计算机网（下文简称教育网）等部门。由于ISP之间对彼此互访做了限制，即在各运营商网络内部访问本网资源不存在速度限制（用户自身上网条件限制除外），但是访问对方资源就有了速度瓶颈。举例来说，如果网站服务器的接入位置处于电信网内，在相同条件下，这个网站对电信用户的响应时间要比其他ISP用户访问它的响应时间都要短。作为教育网接入单位，在整个教育网内部的访问速度基本可以接受。但是从电信或者网通访问这些资源，就存在着上述的瓶颈，访问速度一直比较缓慢，在上网人数比较集中的时段，在有限的带宽条件下，响应时间尤其不可接受。

由于浏览校园网络资源的除了教育网用户之外，非教育网的用户也逐渐增多。因此，提高校园网络对非教育网用户的响应时间愈发重要。但由于网络的出口带宽是一定的，不可能通过不断地增加带宽来提高访问速度，一方面会增加经费支出，另一方面基于前面所述的我国网络运营商状况，即使提高了自身的带宽，也仅仅是提高了教育网内访问速度，对于教育网外的访问速度不会有明显的改善。而最初为了解决访问外部资源慢的问题，校园网增设了多个非教育网出口，但是数据流向仅为单向，即只有校内用户访问外部资源时才能用到非教育网出口，外部用户依然通过教育网访问内部网络资源，从而不能充分利用非教育网出口。因此，在充分利用当前软硬件设备和网络出口的指导思想下，我们采用了目前比较流行的CDN的网络架构，结合校园网络实际情况，形成了独具特色的基于校园网的CDN架构体系，很好地解决了这一问题。[1][2][3]

二、CDN

1.概述

CDN（Content Delivery Network），即内容分发网络，最主要的目的就是保证对访问其网站的终端用户的QoS。图1是典型的CDN架构体系，终端用户访问到的网站内容从中心服务器移动到了接近用户的网络边缘，即将服务内容从一台服务器复制（或镜像）到了另外一台服务器。至于转移的内容，可以根据用户的访问请求而定，也可以是根据内容发布者的发布需要来制定。

用户所访问到的内容是被复制到离用户最近的边缘服务器的内容，而不是原始存在于服务器上面的。但对于用户来说，所访问到的内容在边缘服务器上，还是中心服务器上，是未知的。典型的可以被分发到边缘的内容包括静态内容（如HTML页面，图像，文档，软件等）、流媒体（音频，实时视频）、内容服务（目录服务，电子商务服务，文件传输服务）等。最终所建立的CDN体系架构，要保证这个体系的安全性、可靠性、响应的快速性以及整体良好的性能表现。

2.层次结构

CDN的体系结构可以用分层的思想来描述，包括：基本层、通讯和连接层、内容分发层、终端用户层。

（１）基本层

基本层是CDN体系中的最底层。提供了最基本的体系资源。包括分布式计算资源，如文件服务器、索引服务器以及高速连接的网络节点。这其中每一个资源都包括系统软件，如：操作系统、分布式文件管理系统以及内容索引和管理系统。

（２）通讯和连接层

这一层包括各种通讯协议，即基本网络协议（如TCP/UDP、FTP）、CDN特定的网络协议（如ICP、HTCP）以及缓存阵列路由协议（CARP）、各种认证协议（如PKI）、传输加密，对内容的缓存和传输。

（３）内容分发层

这一层包含CDN核心功能。可以被分为三个子层：CDN服务、CDN类型和所分发的内容类型。一个CDN提供的核心服务包括边缘服务器的选择、用户请求路由、缓存以及负载均衡等。

（４）终端用户层

终端用户层位于 CDN分层结构的顶层。这一层连接到CDN网络体系结构的网络用户。

3.内容分发与管理

内容分发与管理对于有效的内容分发和CDN的总体性能有着极其重要的作用。具体包括：边缘服务器的放置策略——使用户更接近所请求的内容，根据用户访问请求来选择所要传输的内容类型与传输频率。而管理则很大程度上取决于缓存技术（缓存生成、缓存维护与升级）。

（１）边缘服务器放置策略

为了减小用户获取网络资源的延迟时间和减小将复制的内容从服务器传输到客户机所消耗的网络带宽，必须指定合理的边缘服务器放置策略。在这方面提出的主要理论方法有最小K中心问题、K层次优化分割树等，这些方法都将服务器放置问题归结为中心放置问题。[4][5] 这样计算虽然可以得到很好的结果，但是有着非常高的计算复杂度。鉴于此，提出了一些启发式算法，如贪婪复制放置算法和拓扑信息放置策略算法。[6][7] 这些次优化的算法考虑了CDN中所存在的信息，比如说工作模式和网络拓扑结构等，从而使得计算量大大降低，提高了效率。

（２）内容选择和传输

有效的内容传输取决于正确的内容选择。一个合适的内容选择方法可以极大地降低用户的下载时间以及服务器的负载。总的来说，内容选择和传输可以分为两类：全站传输以及部分传输。全站传输就是将整个网站的所有内容都传输到边缘服务器上，其主要优点就是比较简单，但是缺点也比较明显，由于服务内容是需要更新的，如果服务器的网站内容庞大，则不断地更新整个网站需要的花费是可想而知。另外就是边缘服务器的成本问题，需要容纳整个网站内容。而部分传输是选择部分内容传输到边缘服务器上。至于所选择的传输内容，主要是基于网站管理员的经验，或者基于网站中内容被访问的程度，或者是静态、动态对象、或者基于内容聚类等方法来确定。[8][9] 经实验证明，这种方法的主要优点就是可以减少终端用户下载内容的时间以及服务器的负载，但缺点主要是内容选择的复杂度。

（３）缓存技术

内容管理是否合理是CDN性能好坏的关键指标，而内容管理主要依靠缓存的组织方式。缓存组织主要由所使用的缓存技术以及为了保证缓存内容的新鲜度而进行的更新频率组成。同时，缓存的组织也包括对整个CDN体系结构中缓存策略的整合，因为有效的缓存策略可以保证有效的内容管理，同时可以潜在地提高整体的性能。

（４）请求路由

请求路由系统主要负责将用户的访问请求路由到合适的、离用户最近的边缘服务器上，从而将内容快速地传递给用户。但是，最近的边缘服务器并不一定可以最快地将内容传输给用户的服务器，因此，请求路由系统需要利用诸如网络负载情况、用户访问延时、距离以及边缘服务器的负载情况等信息来将最适合于用户访问的边缘服务器内容返回给用户。在CDN体系中的请求路由系统包括两部分：所配置的请求路由算法以及所使用的请求路由机制。当收到客户端请求的时候，请求路由算法就被调用来说明怎样根据客户的请求来选择一个边缘服务器，之后使用请求路由机制来告诉用户所选择的结果。请求路由算法可以分为适应型和非适应型两类。适应型算法主要考虑当前系统的条件来选择一个边缘服务器给用户。而非适应型算法则使用一些启发式方法来选择一个缓存服务器，比如说轮盘选择法。[10] 请求路由机制主要包括统一服务负载均衡、基于域名的请求路由、HTTP请求重定向、URL重写等方法。[11][12][13]

三、校园CDN的架构

在CDN理论的基础上，我们设计了基于校园网的CDN架构。

内容选择和传输以及缓存由开源软件Squid的反向代理功能来完成。Squid根据用户点击请求，将中心服务器的静态内容传输到边缘服务器，这样当后来的用户访问相同的内容时便可以直接从边缘服务器获取，因为边缘服务器是离用户最近的服务器，从而达到了加速的目的。而将用户的访问请求转到边缘服务器的请求路由是通过域名服务器来完成。域名服务器是将用户请求的域名解析为相对应的IP地址，以使用户请求能够到达目的地址。通常情况下，一个网站对应一个IP地址。但是我们通过域名服务器的View功能，可以使一个域名对应多个IP地址，并且可以根据用户的源IP地址，将用户所要访问网站的域名解析为和用户同属于一个ISP的地址。例如，当网通用户要访问我校网络资源的时候，域名服务器就将用户要访问的网站域名解析为相对应的网通出口的IP地址，从而使用户请求的数据包通过网通路由到达相对应的服务器，而不需要经过教育网，这就避免了不同ISP网络之间的瓶颈，即用户访问到了离用户最近的边缘服务器（服务器和用户同属于同一ISP）。如果用户所请求的内容在边缘服务器的缓存中，则直接返回给用户。否则，通过边缘服务器的内部域名解析机制，将请求转向用户所要访问的真正的网站地址，再将内容返回给用户。

大多校园网都接入教育网、电信和网通等作为网络出口。为了突破各个运营商之间的瓶颈限制，主要是将教育网的内容分发到网通和电信出口，从而可以使网通和电信的用户也可以快速地访问教育网资源。在充分利用现有设备的基础上，通过给部分机器添加网卡，配置合适的路由，利用DNS软件的View功能和代理软件的反向代理功能，从而实现了校园CDN，如图2所示，以网通用户的访问请求为例来说明。原始服务器（1，2，…，n）为放置在教育网内的各单位、院系内的服务器，配置有一块网卡，通过反向代理，将这些服务器的静态内容（HTML网页、图像）分发放置在电信、网通网段的缓存服务器中，当一个网通用户要访问服务器1的内容时，分为如下几步：（1）用户发起访问教育网服务器1的DNS请求；（2）DNS服务器根据用户的IP地址来源，将网通出口的缓存服务器地址返回给用户，从而使用户访问指向为网通缓存服务器；（3）用户向网通出口缓存服务器发起内容请求。（4）缓存服务器根据用户的访问请求，向教育网源服务器1发起内容请求；（5）教育网源服务器1将请求的内容分发给缓存服务器；（6）缓存服务器将内容返回到用户终端。经过第一次访问，当以后再有网通用户访问相同的内容时，访问缩短为（1）、（2）、（3）、（6），这样就大大加快了请求内容返回的响应速度，从而达到加速的目的。

四、实验设置及应用前后对比

为了测试应用CDN前后的连接速度是否真正达到了加速的目的，我们进行了连接速度测试。

实验主要测试了网通的连接速度，在校外选择一个网通连接地点，利用下面所示的连接代码（部分）来计算将整个网站的网页下载到客户端所花费的时间。

long starttime=System.currentTimeMillis ();

try{

URL pageUrl=new URL();

URLConnection urlConnection=pageUrl.openConnection();

BufferedReader reader = new BufferedReader(new InputStreamReader(pageUrl.openStream()));

String line;

while((line=reader.readLine())!= null){

}

}catch(Exception e){

}

long endtime=System.currentTimeMillis ();

long eclapsetime=endtime-starttime;

所选择的加速网站为纯静态型（以HTML网页、图像为主）、动态型（包括asp、php、jsp），第一个测试时间段为早上9点到10点之间，因为这个时间段我校上网人数少，出口路由器负载低。第二个测试时间段为晚上7点到8点之间，在这个时间段正好是上网高峰时期。测试方法为在每个时间段内每隔20分钟进行1次，总计3次的HTTP连接测试，每次测试都顺序访问以下10个测试网站，首先为直接访问，其次为通过CDN架构访问。表1为上午9：00至10：00的三次测试结果。表2为19：00至20：00的测试结果。表格内访问时间的单位均为ms。

从表1、表2中我们可以看到，响应时间的提高幅度方面：在白天网络不繁忙的情况下，总计30次的测试中，响应时间在1000毫秒以下的有20次，占到了访问总数的67%，而其余10次响应时间在1000毫秒以上的也都属于可接受的范围。总计在测试中访问这些网站的时间，平均三次测试的提高幅度达到了7.8倍。而在晚上上网高峰的时候，响应时间在1000毫秒以下的有16次，占到了访问总数的53%。响应时间在1000毫秒到3000毫秒之间的有9次，占到了30%，剩余测试中最慢的响应时间为5262毫秒，处于用户可以接受的时间范围之内。虽然响应时间较白天有些下降，但是和直接访问相比，平均这三次响应速度的提高幅度，达到了12.4倍。

从以上的测试数据来看，单纯从提高响应速度来看，有了很大改善，但是由于受限于现有的硬件资源，存在的不足之处在于：（1）将多台教育网站的内容缓存到一台反向代理服务器上面，如果这台服务器出现问题，将导致它所缓存的所有网站无法访问；（2）并没有在每一个出口都放置一台边缘服务器，而是给一台服务器增加网卡，通过这种方式来达到边缘的目的，增加了服务器的负担。解决上述问题的方法就是在资金充足的时候，适当地增加边缘服务器的数量，从而减少每一台边缘服务器上缓存的网站数量，或者使用负载均衡策略，提高服务器的稳定性。

五、结论与应用展望

校园CDN的成功应用，很好地解决了网络瓶颈、服务器响应慢等问题，使得校园网络资源对外访问的响应时间大大缩短，极大地提高了校外用户访问我校资源（特别是在网络繁忙时段）的响应速度，对外网络环境大大改善。在我国大力提倡建设节约型社会的背景下，不管是从实际应用效果上，还是经济上，对于各高校改善校园网对外响应速度都有着很好的应用前景。

参考文献：

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

[2]A. Vakali, and G. Pallis, “Content Delivery Networks: Status and Trends,” IEEE Internet Computing, IEEE Computer Society, pp. 68-74, November-December 2003.

[3] G. Peng, “CDN: Content Distribution Network,” Technical Report TR-125, Experimental Computer Systems Lab, Department of Computer Science, State University of New York, Stony Brook, NY, 2003.

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

[5]Y. Bartal, “Probabilistic Approximation of Metric Space and its Algorithmic Applications,” In Proceedings of 37th Annual IEEE Symposium on Foundations of Computer Science, October 1996.

[6]P. Krishnan, D. Raz, and Y. Shavitt, “The Cache Location Problem,” IEEE/ACM Transaction on Networking, Vol. 8, No. 5, 2000.

[7]S. Jamin, C. Jin, A. R. Kure, D. Raz, and Y. Shavitt, “Constrained Mirror Placement on the Internet,” In Proceedings of IEEE INFOCOM, Anchorage, Alaska, USA, April 2001.

[8]N. Fujita, Y. Ishikawa, A. Iwata, and R. Izmailov, “Coarse-grain Replica Management Strategies for Dynamic Replication of Web Contents,” Computer Networks: The International Journal of Computer and Telecommunications Networking, Vol. 45, Issue 1, pp. 19-34, May 2004.

[9]Y. Chen, L. Qiu, W. Chen, L. Nguyen, and R. H. Katz, “Efficient and Adaptive Web Replication using Content Clustering,” IEEE Journal on Selected Areas in Communications, Vol. 21, Issue 6, pp. 979-994, August 2003.

[10]M. Szymaniak, G. Pierre, and M. van Steen, “Netairt: A DNS-based Redirection System for Apache,” In Proceedings of International Conference WWW/Internet, Algrave, Portugal, 2003.

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

[12]A. Vakali, and G. Pallis, “Content Delivery Networks: Status and Trends,” IEEE Internet Computing, IEEE Computer，Society, pp. 68-74, November-December 2003.

[13]F. Douglis, and M. F. Kaashoek, “Scalable Internet Services,” IEEE Internet Computing, Vol. 5, No. 4, 2001, pp. 36-37.