基于校園網(wǎng)環(huán)境的ＣＤＮ架構(gòu)探索與應(yīng)用

劉曉龍　葛永興　楊雙陽

摘 要：由于國(guó)內(nèi)各ISP之間互聯(lián)互通存在網(wǎng)絡(luò)瓶頸，極大地影響了校園網(wǎng)對(duì)非教育網(wǎng)用戶訪問的響應(yīng)速度。目前國(guó)內(nèi)商用門戶網(wǎng)站解決這種問題主要采用CDN架構(gòu)，投入巨大。如果完全按照門戶網(wǎng)站的CDN架構(gòu)來建設(shè)自己的校園網(wǎng)，不符合校園網(wǎng)實(shí)際情況。因此，本文提出了基于校園網(wǎng)實(shí)際環(huán)境部署CDN的應(yīng)用方案，很好地消除了網(wǎng)絡(luò)瓶頸，使外部用戶得以快速訪問校內(nèi)資源。

關(guān)鍵詞：CDN 網(wǎng)絡(luò)瓶頸 校園網(wǎng) 響應(yīng)速度

中圖分類號(hào)：TP393.18 文獻(xiàn)標(biāo)識(shí)碼：B 文章編號(hào)：1673-8454（2009）01-0032-04

怎樣讓校外，特別是非教育網(wǎng)用戶快速地訪問教育資源網(wǎng)站一直是我們積極探索的重點(diǎn)。經(jīng)過多年的研究與改進(jìn)，逐漸摸索出了一些適合教育網(wǎng)實(shí)際情況的校園網(wǎng)架構(gòu)和訪問策略，極大地提高了訪問響應(yīng)速度。

一、現(xiàn)狀分析

我國(guó)目前的ISP主要有中國(guó)電信（下文簡(jiǎn)稱電信）、中國(guó)網(wǎng)通（下文簡(jiǎn)稱網(wǎng)通）、中國(guó)教育和科研計(jì)算機(jī)網(wǎng)（下文簡(jiǎn)稱教育網(wǎng)）等部門。由于ISP之間對(duì)彼此互訪做了限制，即在各運(yùn)營(yíng)商網(wǎng)絡(luò)內(nèi)部訪問本網(wǎng)資源不存在速度限制（用戶自身上網(wǎng)條件限制除外），但是訪問對(duì)方資源就有了速度瓶頸。舉例來說，如果網(wǎng)站服務(wù)器的接入位置處于電信網(wǎng)內(nèi)，在相同條件下，這個(gè)網(wǎng)站對(duì)電信用戶的響應(yīng)時(shí)間要比其他ISP用戶訪問它的響應(yīng)時(shí)間都要短。作為教育網(wǎng)接入單位，在整個(gè)教育網(wǎng)內(nèi)部的訪問速度基本可以接受。但是從電信或者網(wǎng)通訪問這些資源，就存在著上述的瓶頸，訪問速度一直比較緩慢，在上網(wǎng)人數(shù)比較集中的時(shí)段，在有限的帶寬條件下，響應(yīng)時(shí)間尤其不可接受。

由于瀏覽校園網(wǎng)絡(luò)資源的除了教育網(wǎng)用戶之外，非教育網(wǎng)的用戶也逐漸增多。因此，提高校園網(wǎng)絡(luò)對(duì)非教育網(wǎng)用戶的響應(yīng)時(shí)間愈發(fā)重要。但由于網(wǎng)絡(luò)的出口帶寬是一定的，不可能通過不斷地增加帶寬來提高訪問速度，一方面會(huì)增加經(jīng)費(fèi)支出，另一方面基于前面所述的我國(guó)網(wǎng)絡(luò)運(yùn)營(yíng)商狀況，即使提高了自身的帶寬，也僅僅是提高了教育網(wǎng)內(nèi)訪問速度，對(duì)于教育網(wǎng)外的訪問速度不會(huì)有明顯的改善。而最初為了解決訪問外部資源慢的問題，校園網(wǎng)增設(shè)了多個(gè)非教育網(wǎng)出口，但是數(shù)據(jù)流向僅為單向，即只有校內(nèi)用戶訪問外部資源時(shí)才能用到非教育網(wǎng)出口，外部用戶依然通過教育網(wǎng)訪問內(nèi)部網(wǎng)絡(luò)資源，從而不能充分利用非教育網(wǎng)出口。因此，在充分利用當(dāng)前軟硬件設(shè)備和網(wǎng)絡(luò)出口的指導(dǎo)思想下，我們采用了目前比較流行的CDN的網(wǎng)絡(luò)架構(gòu)，結(jié)合校園網(wǎng)絡(luò)實(shí)際情況，形成了獨(dú)具特色的基于校園網(wǎng)的CDN架構(gòu)體系，很好地解決了這一問題。[1][2][3]

二、CDN

1.概述

CDN（Content Delivery Network），即內(nèi)容分發(fā)網(wǎng)絡(luò)，最主要的目的就是保證對(duì)訪問其網(wǎng)站的終端用戶的QoS。圖1是典型的CDN架構(gòu)體系，終端用戶訪問到的網(wǎng)站內(nèi)容從中心服務(wù)器移動(dòng)到了接近用戶的網(wǎng)絡(luò)邊緣，即將服務(wù)內(nèi)容從一臺(tái)服務(wù)器復(fù)制（或鏡像）到了另外一臺(tái)服務(wù)器。至于轉(zhuǎn)移的內(nèi)容，可以根據(jù)用戶的訪問請(qǐng)求而定，也可以是根據(jù)內(nèi)容發(fā)布者的發(fā)布需要來制定。

用戶所訪問到的內(nèi)容是被復(fù)制到離用戶最近的邊緣服務(wù)器的內(nèi)容，而不是原始存在于服務(wù)器上面的。但對(duì)于用戶來說，所訪問到的內(nèi)容在邊緣服務(wù)器上，還是中心服務(wù)器上，是未知的。典型的可以被分發(fā)到邊緣的內(nèi)容包括靜態(tài)內(nèi)容（如HTML頁(yè)面，圖像，文檔，軟件等）、流媒體（音頻，實(shí)時(shí)視頻）、內(nèi)容服務(wù)（目錄服務(wù)，電子商務(wù)服務(wù)，文件傳輸服務(wù)）等。最終所建立的CDN體系架構(gòu)，要保證這個(gè)體系的安全性、可靠性、響應(yīng)的快速性以及整體良好的性能表現(xiàn)。

2.層次結(jié)構(gòu)

CDN的體系結(jié)構(gòu)可以用分層的思想來描述，包括：基本層、通訊和連接層、內(nèi)容分發(fā)層、終端用戶層。

（１）基本層

基本層是CDN體系中的最底層。提供了最基本的體系資源。包括分布式計(jì)算資源，如文件服務(wù)器、索引服務(wù)器以及高速連接的網(wǎng)絡(luò)節(jié)點(diǎn)。這其中每一個(gè)資源都包括系統(tǒng)軟件，如：操作系統(tǒng)、分布式文件管理系統(tǒng)以及內(nèi)容索引和管理系統(tǒng)。

（２）通訊和連接層

這一層包括各種通訊協(xié)議，即基本網(wǎng)絡(luò)協(xié)議（如TCP/UDP、FTP）、CDN特定的網(wǎng)絡(luò)協(xié)議（如ICP、HTCP）以及緩存陣列路由協(xié)議（CARP）、各種認(rèn)證協(xié)議（如PKI）、傳輸加密，對(duì)內(nèi)容的緩存和傳輸。

（３）內(nèi)容分發(fā)層

這一層包含CDN核心功能?？梢员环譃槿齻€(gè)子層：CDN服務(wù)、CDN類型和所分發(fā)的內(nèi)容類型。一個(gè)CDN提供的核心服務(wù)包括邊緣服務(wù)器的選擇、用戶請(qǐng)求路由、緩存以及負(fù)載均衡等。

（４）終端用戶層

終端用戶層位于 CDN分層結(jié)構(gòu)的頂層。這一層連接到CDN網(wǎng)絡(luò)體系結(jié)構(gòu)的網(wǎng)絡(luò)用戶。

3.內(nèi)容分發(fā)與管理

內(nèi)容分發(fā)與管理對(duì)于有效的內(nèi)容分發(fā)和CDN的總體性能有著極其重要的作用。具體包括：邊緣服務(wù)器的放置策略——使用戶更接近所請(qǐng)求的內(nèi)容，根據(jù)用戶訪問請(qǐng)求來選擇所要傳輸?shù)膬?nèi)容類型與傳輸頻率。而管理則很大程度上取決于緩存技術(shù)（緩存生成、緩存維護(hù)與升級(jí)）。

（１）邊緣服務(wù)器放置策略

為了減小用戶獲取網(wǎng)絡(luò)資源的延遲時(shí)間和減小將復(fù)制的內(nèi)容從服務(wù)器傳輸?shù)娇蛻魴C(jī)所消耗的網(wǎng)絡(luò)帶寬，必須指定合理的邊緣服務(wù)器放置策略。在這方面提出的主要理論方法有最小K中心問題、K層次優(yōu)化分割樹等，這些方法都將服務(wù)器放置問題歸結(jié)為中心放置問題。[4][5] 這樣計(jì)算雖然可以得到很好的結(jié)果，但是有著非常高的計(jì)算復(fù)雜度。鑒于此，提出了一些啟發(fā)式算法，如貪婪復(fù)制放置算法和拓?fù)湫畔⒎胖貌呗运惴?。[6][7] 這些次優(yōu)化的算法考慮了CDN中所存在的信息，比如說工作模式和網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)等，從而使得計(jì)算量大大降低，提高了效率。

（２）內(nèi)容選擇和傳輸

有效的內(nèi)容傳輸取決于正確的內(nèi)容選擇。一個(gè)合適的內(nèi)容選擇方法可以極大地降低用戶的下載時(shí)間以及服務(wù)器的負(fù)載?？偟膩碚f，內(nèi)容選擇和傳輸可以分為兩類：全站傳輸以及部分傳輸。全站傳輸就是將整個(gè)網(wǎng)站的所有內(nèi)容都傳輸?shù)竭吘壏?wù)器上，其主要優(yōu)點(diǎn)就是比較簡(jiǎn)單，但是缺點(diǎn)也比較明顯，由于服務(wù)內(nèi)容是需要更新的，如果服務(wù)器的網(wǎng)站內(nèi)容龐大，則不斷地更新整個(gè)網(wǎng)站需要的花費(fèi)是可想而知。另外就是邊緣服務(wù)器的成本問題，需要容納整個(gè)網(wǎng)站內(nèi)容。而部分傳輸是選擇部分內(nèi)容傳輸?shù)竭吘壏?wù)器上。至于所選擇的傳輸內(nèi)容，主要是基于網(wǎng)站管理員的經(jīng)驗(yàn)，或者基于網(wǎng)站中內(nèi)容被訪問的程度，或者是靜態(tài)、動(dòng)態(tài)對(duì)象、或者基于內(nèi)容聚類等方法來確定。[8][9] 經(jīng)實(shí)驗(yàn)證明，這種方法的主要優(yōu)點(diǎn)就是可以減少終端用戶下載內(nèi)容的時(shí)間以及服務(wù)器的負(fù)載，但缺點(diǎn)主要是內(nèi)容選擇的復(fù)雜度。

（３）緩存技術(shù)

內(nèi)容管理是否合理是CDN性能好壞的關(guān)鍵指標(biāo)，而內(nèi)容管理主要依靠緩存的組織方式。緩存組織主要由所使用的緩存技術(shù)以及為了保證緩存內(nèi)容的新鮮度而進(jìn)行的更新頻率組成。同時(shí)，緩存的組織也包括對(duì)整個(gè)CDN體系結(jié)構(gòu)中緩存策略的整合，因?yàn)橛行У木彺娌呗钥梢员ＷC有效的內(nèi)容管理，同時(shí)可以潛在地提高整體的性能。

（４）請(qǐng)求路由

請(qǐng)求路由系統(tǒng)主要負(fù)責(zé)將用戶的訪問請(qǐng)求路由到合適的、離用戶最近的邊緣服務(wù)器上，從而將內(nèi)容快速地傳遞給用戶。但是，最近的邊緣服務(wù)器并不一定可以最快地將內(nèi)容傳輸給用戶的服務(wù)器，因此，請(qǐng)求路由系統(tǒng)需要利用諸如網(wǎng)絡(luò)負(fù)載情況、用戶訪問延時(shí)、距離以及邊緣服務(wù)器的負(fù)載情況等信息來將最適合于用戶訪問的邊緣服務(wù)器內(nèi)容返回給用戶。在CDN體系中的請(qǐng)求路由系統(tǒng)包括兩部分：所配置的請(qǐng)求路由算法以及所使用的請(qǐng)求路由機(jī)制。當(dāng)收到客戶端請(qǐng)求的時(shí)候，請(qǐng)求路由算法就被調(diào)用來說明怎樣根據(jù)客戶的請(qǐng)求來選擇一個(gè)邊緣服務(wù)器，之后使用請(qǐng)求路由機(jī)制來告訴用戶所選擇的結(jié)果。請(qǐng)求路由算法可以分為適應(yīng)型和非適應(yīng)型兩類。適應(yīng)型算法主要考慮當(dāng)前系統(tǒng)的條件來選擇一個(gè)邊緣服務(wù)器給用戶。而非適應(yīng)型算法則使用一些啟發(fā)式方法來選擇一個(gè)緩存服務(wù)器，比如說輪盤選擇法。[10] 請(qǐng)求路由機(jī)制主要包括統(tǒng)一服務(wù)負(fù)載均衡、基于域名的請(qǐng)求路由、HTTP請(qǐng)求重定向、URL重寫等方法。[11][12][13]

三、校園CDN的架構(gòu)

在CDN理論的基礎(chǔ)上，我們?cè)O(shè)計(jì)了基于校園網(wǎng)的CDN架構(gòu)。

內(nèi)容選擇和傳輸以及緩存由開源軟件Squid的反向代理功能來完成。Squid根據(jù)用戶點(diǎn)擊請(qǐng)求，將中心服務(wù)器的靜態(tài)內(nèi)容傳輸?shù)竭吘壏?wù)器，這樣當(dāng)后來的用戶訪問相同的內(nèi)容時(shí)便可以直接從邊緣服務(wù)器獲取，因?yàn)檫吘壏?wù)器是離用戶最近的服務(wù)器，從而達(dá)到了加速的目的。而將用戶的訪問請(qǐng)求轉(zhuǎn)到邊緣服務(wù)器的請(qǐng)求路由是通過域名服務(wù)器來完成。域名服務(wù)器是將用戶請(qǐng)求的域名解析為相對(duì)應(yīng)的IP地址，以使用戶請(qǐng)求能夠到達(dá)目的地址。通常情況下，一個(gè)網(wǎng)站對(duì)應(yīng)一個(gè)IP地址。但是我們通過域名服務(wù)器的View功能，可以使一個(gè)域名對(duì)應(yīng)多個(gè)IP地址，并且可以根據(jù)用戶的源IP地址，將用戶所要訪問網(wǎng)站的域名解析為和用戶同屬于一個(gè)ISP的地址。例如，當(dāng)網(wǎng)通用戶要訪問我校網(wǎng)絡(luò)資源的時(shí)候，域名服務(wù)器就將用戶要訪問的網(wǎng)站域名解析為相對(duì)應(yīng)的網(wǎng)通出口的IP地址，從而使用戶請(qǐng)求的數(shù)據(jù)包通過網(wǎng)通路由到達(dá)相對(duì)應(yīng)的服務(wù)器，而不需要經(jīng)過教育網(wǎng)，這就避免了不同ISP網(wǎng)絡(luò)之間的瓶頸，即用戶訪問到了離用戶最近的邊緣服務(wù)器（服務(wù)器和用戶同屬于同一ISP）。如果用戶所請(qǐng)求的內(nèi)容在邊緣服務(wù)器的緩存中，則直接返回給用戶。否則，通過邊緣服務(wù)器的內(nèi)部域名解析機(jī)制，將請(qǐng)求轉(zhuǎn)向用戶所要訪問的真正的網(wǎng)站地址，再將內(nèi)容返回給用戶。

大多校園網(wǎng)都接入教育網(wǎng)、電信和網(wǎng)通等作為網(wǎng)絡(luò)出口。為了突破各個(gè)運(yùn)營(yíng)商之間的瓶頸限制，主要是將教育網(wǎng)的內(nèi)容分發(fā)到網(wǎng)通和電信出口，從而可以使網(wǎng)通和電信的用戶也可以快速地訪問教育網(wǎng)資源。在充分利用現(xiàn)有設(shè)備的基礎(chǔ)上，通過給部分機(jī)器添加網(wǎng)卡，配置合適的路由，利用DNS軟件的View功能和代理軟件的反向代理功能，從而實(shí)現(xiàn)了校園CDN，如圖2所示，以網(wǎng)通用戶的訪問請(qǐng)求為例來說明。原始服務(wù)器（1，2，…，n）為放置在教育網(wǎng)內(nèi)的各單位、院系內(nèi)的服務(wù)器，配置有一塊網(wǎng)卡，通過反向代理，將這些服務(wù)器的靜態(tài)內(nèi)容（HTML網(wǎng)頁(yè)、圖像）分發(fā)放置在電信、網(wǎng)通網(wǎng)段的緩存服務(wù)器中，當(dāng)一個(gè)網(wǎng)通用戶要訪問服務(wù)器1的內(nèi)容時(shí)，分為如下幾步：（1）用戶發(fā)起訪問教育網(wǎng)服務(wù)器1的DNS請(qǐng)求；（2）DNS服務(wù)器根據(jù)用戶的IP地址來源，將網(wǎng)通出口的緩存服務(wù)器地址返回給用戶，從而使用戶訪問指向?yàn)榫W(wǎng)通緩存服務(wù)器；（3）用戶向網(wǎng)通出口緩存服務(wù)器發(fā)起內(nèi)容請(qǐng)求。（4）緩存服務(wù)器根據(jù)用戶的訪問請(qǐng)求，向教育網(wǎng)源服務(wù)器1發(fā)起內(nèi)容請(qǐng)求；（5）教育網(wǎng)源服務(wù)器1將請(qǐng)求的內(nèi)容分發(fā)給緩存服務(wù)器；（6）緩存服務(wù)器將內(nèi)容返回到用戶終端。經(jīng)過第一次訪問，當(dāng)以后再有網(wǎng)通用戶訪問相同的內(nèi)容時(shí)，訪問縮短為（1）、（2）、（3）、（6），這樣就大大加快了請(qǐng)求內(nèi)容返回的響應(yīng)速度，從而達(dá)到加速的目的。

四、實(shí)驗(yàn)設(shè)置及應(yīng)用前后對(duì)比

為了測(cè)試應(yīng)用CDN前后的連接速度是否真正達(dá)到了加速的目的，我們進(jìn)行了連接速度測(cè)試。

實(shí)驗(yàn)主要測(cè)試了網(wǎng)通的連接速度，在校外選擇一個(gè)網(wǎng)通連接地點(diǎn)，利用下面所示的連接代碼（部分）來計(jì)算將整個(gè)網(wǎng)站的網(wǎng)頁(yè)下載到客戶端所花費(fèi)的時(shí)間。

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;

所選擇的加速網(wǎng)站為純靜態(tài)型（以HTML網(wǎng)頁(yè)、圖像為主）、動(dòng)態(tài)型（包括asp、php、jsp），第一個(gè)測(cè)試時(shí)間段為早上9點(diǎn)到10點(diǎn)之間，因?yàn)檫@個(gè)時(shí)間段我校上網(wǎng)人數(shù)少，出口路由器負(fù)載低。第二個(gè)測(cè)試時(shí)間段為晚上7點(diǎn)到8點(diǎn)之間，在這個(gè)時(shí)間段正好是上網(wǎng)高峰時(shí)期。測(cè)試方法為在每個(gè)時(shí)間段內(nèi)每隔20分鐘進(jìn)行1次，總計(jì)3次的HTTP連接測(cè)試，每次測(cè)試都順序訪問以下10個(gè)測(cè)試網(wǎng)站，首先為直接訪問，其次為通過CDN架構(gòu)訪問。表1為上午9：00至10：00的三次測(cè)試結(jié)果。表2為19：00至20：00的測(cè)試結(jié)果。表格內(nèi)訪問時(shí)間的單位均為ms。

從表1、表2中我們可以看到，響應(yīng)時(shí)間的提高幅度方面：在白天網(wǎng)絡(luò)不繁忙的情況下，總計(jì)30次的測(cè)試中，響應(yīng)時(shí)間在1000毫秒以下的有20次，占到了訪問總數(shù)的67%，而其余10次響應(yīng)時(shí)間在1000毫秒以上的也都屬于可接受的范圍。總計(jì)在測(cè)試中訪問這些網(wǎng)站的時(shí)間，平均三次測(cè)試的提高幅度達(dá)到了7.8倍。而在晚上上網(wǎng)高峰的時(shí)候，響應(yīng)時(shí)間在1000毫秒以下的有16次，占到了訪問總數(shù)的53%。響應(yīng)時(shí)間在1000毫秒到3000毫秒之間的有9次，占到了30%，剩余測(cè)試中最慢的響應(yīng)時(shí)間為5262毫秒，處于用戶可以接受的時(shí)間范圍之內(nèi)。雖然響應(yīng)時(shí)間較白天有些下降，但是和直接訪問相比，平均這三次響應(yīng)速度的提高幅度，達(dá)到了12.4倍。

從以上的測(cè)試數(shù)據(jù)來看，單純從提高響應(yīng)速度來看，有了很大改善，但是由于受限于現(xiàn)有的硬件資源，存在的不足之處在于：（1）將多臺(tái)教育網(wǎng)站的內(nèi)容緩存到一臺(tái)反向代理服務(wù)器上面，如果這臺(tái)服務(wù)器出現(xiàn)問題，將導(dǎo)致它所緩存的所有網(wǎng)站無法訪問；（2）并沒有在每一個(gè)出口都放置一臺(tái)邊緣服務(wù)器，而是給一臺(tái)服務(wù)器增加網(wǎng)卡，通過這種方式來達(dá)到邊緣的目的，增加了服務(wù)器的負(fù)擔(dān)。解決上述問題的方法就是在資金充足的時(shí)候，適當(dāng)?shù)卦黾舆吘壏?wù)器的數(shù)量，從而減少每一臺(tái)邊緣服務(wù)器上緩存的網(wǎng)站數(shù)量，或者使用負(fù)載均衡策略，提高服務(wù)器的穩(wěn)定性。

五、結(jié)論與應(yīng)用展望

校園CDN的成功應(yīng)用，很好地解決了網(wǎng)絡(luò)瓶頸、服務(wù)器響應(yīng)慢等問題，使得校園網(wǎng)絡(luò)資源對(duì)外訪問的響應(yīng)時(shí)間大大縮短，極大地提高了校外用戶訪問我校資源（特別是在網(wǎng)絡(luò)繁忙時(shí)段）的響應(yīng)速度，對(duì)外網(wǎng)絡(luò)環(huán)境大大改善。在我國(guó)大力提倡建設(shè)節(jié)約型社會(huì)的背景下，不管是從實(shí)際應(yīng)用效果上，還是經(jīng)濟(jì)上，對(duì)于各高校改善校園網(wǎng)對(duì)外響應(yīng)速度都有著很好的應(yīng)用前景。

參考文獻(xiàn)：

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