【正文】 Content Delivery Network，即內(nèi)容分發(fā)網(wǎng)絡(luò)。當(dāng)用戶的請(qǐng)求到達(dá)指定節(jié)點(diǎn)時(shí)，CDN的服務(wù)器（節(jié)點(diǎn)上的高速緩存)負(fù)責(zé)將用戶請(qǐng)求的內(nèi)容提供給用戶。各部分功能見(jiàn)表21。但是Web Caching在P2P內(nèi)容緩存系統(tǒng)中是否可行呢？178。178。 Web Caching所處的位置是在網(wǎng)絡(luò)的邊緣，可以靠近客戶端，也可以接近服務(wù)器端，根據(jù)其所處的位置也有所不同?？尚行詧?bào)告結(jié)論：根據(jù)以上比較可知，Web Caching技術(shù)在不能達(dá)到P2P內(nèi)容緩存服務(wù)器設(shè)計(jì)的要求，其方案不可行。 CDN內(nèi)容分發(fā)網(wǎng)絡(luò)主要傳遞內(nèi)容為大容量的媒體文件，這與目前主流P2P文件下載應(yīng)用傳遞內(nèi)容基本一致。 CDN系統(tǒng)在實(shí)現(xiàn)效果上比較理想，性能、可伸縮性和可靠性都很好，節(jié)省了網(wǎng)絡(luò)帶寬。178。 CDN內(nèi)容分發(fā)網(wǎng)絡(luò)需要在全球各地設(shè)置服務(wù)器，成本比較高，而P2P內(nèi)容下載范圍一般沒(méi)有這么廣，不必要全球分布服務(wù)器。 本章小結(jié)在本章中，我們分別展示了Web Caching技術(shù)和CDN內(nèi)容分法網(wǎng)絡(luò)技術(shù)的技術(shù)原理以及這兩種技術(shù)的比較，同時(shí)結(jié)合目前P2P流量情況進(jìn)行分析，研究這兩種緩存技術(shù)是否適合P2P流量的需要，得到以下結(jié)論：(1) Web Caching技術(shù)和CDN技術(shù)在實(shí)現(xiàn)方式、運(yùn)營(yíng)模式、資金投入等方面不適合P2P流量的需要，不能滿足有效控制P2P流量的作用。對(duì)于ISP來(lái)說(shuō)，P2P的快速大規(guī)模的使用使ISP的利益受到了很大的影響：帶寬資源被P2P應(yīng)用耗用殆盡，無(wú)法滿足一些客戶帶寬的要求；嚴(yán)重沖擊了ISP的傳統(tǒng)業(yè)務(wù)收入。其設(shè)計(jì)目標(biāo)及要求如下：(1) 通過(guò)一定的技術(shù)手段，減少ISP出口的P2P連接數(shù)量（流量）或是適當(dāng)降低用戶信息的下載速度，實(shí)現(xiàn)P2P流量在ISP出口處的壓力，從而節(jié)省網(wǎng)絡(luò)帶寬。(5) 此系統(tǒng)設(shè)計(jì)對(duì)于網(wǎng)絡(luò)接入用戶來(lái)說(shuō)是透明的。 系統(tǒng)設(shè)計(jì)層次結(jié)構(gòu)首先，所有的P2P應(yīng)用都是屬于OSI模型的第七層——應(yīng)用層的，其次，所有的P2P 應(yīng)用都是一種通信過(guò)程，無(wú)論是通過(guò)TCP傳輸方式，還是UDP方式；最后，由于ISP需要將所有經(jīng)過(guò)ISP路由器的P2P數(shù)據(jù)檢測(cè)出來(lái)，改變其路由，轉(zhuǎn)發(fā)到設(shè)置好的P2P內(nèi)容緩存服務(wù)器中，所以，網(wǎng)絡(luò)層路由轉(zhuǎn)發(fā)策略也是系統(tǒng)中很重要的部分。同時(shí)，設(shè)計(jì)一個(gè)主動(dòng)下載P2P內(nèi)容策略，預(yù)測(cè)用戶可能需要下載的P2P內(nèi)容。另外，由于P2P內(nèi)容緩存數(shù)據(jù)庫(kù)的空間是有限的，所以本部分存在一個(gè)信息淘汰算法，淘汰一段時(shí)間內(nèi)沒(méi)有用戶請(qǐng)求下載的P2P內(nèi)容或者是該P(yáng)2P內(nèi)容發(fā)生更新的P2P內(nèi)容。初始化剩余空間有文件下載更新有無(wú)該文件更新數(shù)據(jù)庫(kù)（增）無(wú)有有等待淘汰有查詢記錄長(zhǎng)時(shí)間無(wú)下載是否無(wú)下載更新數(shù)據(jù)庫(kù)（刪）無(wú)淘汰更新數(shù)據(jù)庫(kù)（刪）圖33 文件內(nèi)容更新示意圖對(duì)數(shù)據(jù)包分類用戶數(shù)據(jù)流是不是P2P數(shù)據(jù)是不是P2P下載路由器將該數(shù)據(jù)包轉(zhuǎn)發(fā)至P2P緩存服務(wù)器正常通過(guò)ISP出口有無(wú)該種子文件有更新嗎用戶到P2P緩存服務(wù)器中下載下載種子和內(nèi)容是否無(wú)有有無(wú)下載完了嗎是否是否開(kāi)始結(jié)束（與用戶斷開(kāi)連接）圖34 系統(tǒng)工作原理圖 系統(tǒng)關(guān)鍵技術(shù)在前面幾個(gè)中，我們?cè)敿?xì)分析了系統(tǒng)設(shè)計(jì)目標(biāo)與要求和功能模塊設(shè)計(jì)，可以看出，該系統(tǒng)的關(guān)鍵是系統(tǒng)能夠在多用戶同時(shí)請(qǐng)求P2P內(nèi)容時(shí)快速響應(yīng)用戶請(qǐng)求，提供P2P內(nèi)容下載業(yè)務(wù)?？蛻舳伺c服務(wù)器端使用不同的傳輸協(xié)議socket編程是不同的，圖35為使用TCP協(xié)議socket編程流程圖。一個(gè)BT client 在下載開(kāi)始以及下載進(jìn)行的過(guò)程中，要不停的與 tracker 服務(wù)器進(jìn)行通信，以報(bào)告自己的信息，并獲取其它下載client的信息。由于本系統(tǒng)再邏輯上比較復(fù)雜，為了使系統(tǒng)更加簡(jiǎn)潔，功能更加明確，因此根據(jù)其功能將系統(tǒng)分為六個(gè)部分：178。 種子下載客戶端模塊：該模塊的任務(wù)是負(fù)責(zé)種子文件和內(nèi)容文件的下載，主要有兩種情況：用戶請(qǐng)求下載，P2P緩存服務(wù)器上沒(méi)有；P2P服務(wù)器設(shè)置一個(gè)策略，主動(dòng)搜索“熱門”種子，預(yù)測(cè)用戶可能對(duì)哪些種子感興趣，請(qǐng)求下載的種子文件和內(nèi)容文件，下載文件放在P2P緩存服務(wù)器中，等待用戶下載，并將其信息加入到種子信息數(shù)據(jù)庫(kù)中。 模擬Tracker服務(wù)器模塊：當(dāng)ISP內(nèi)peer向外部Tracker發(fā)送GET請(qǐng)求時(shí)，此模塊模擬外部Tracker向peer返回HTT GET的響應(yīng)信息。 種子信息數(shù)據(jù)庫(kù)模塊：負(fù)責(zé)對(duì)種子信息數(shù)據(jù)庫(kù)的維護(hù)（增加、刪除、修改、更新）。本方案主要由種子請(qǐng)求處理模塊、內(nèi)容請(qǐng)求處理模塊、種子自動(dòng)搜索模塊三個(gè)模塊組成，每個(gè)模塊之間相對(duì)獨(dú)立，互不干擾。l 內(nèi)容請(qǐng)求處理模塊：本模塊相當(dāng)于一個(gè)內(nèi)容服務(wù)器，響應(yīng)用戶內(nèi)容請(qǐng)求，將請(qǐng)求內(nèi)容按照某種方式傳送給客戶端。 方案比較方案一：系統(tǒng)設(shè)計(jì)功能全面，能夠支持目前主流所有P2P應(yīng)用軟件，擴(kuò)展性好，能夠解決目前ISP出口網(wǎng)絡(luò)擁塞得狀況。開(kāi)發(fā)環(huán)境采用Linux系統(tǒng)，Linux系統(tǒng)是“開(kāi)放性架構(gòu)”，支持幾乎所有的計(jì)算機(jī)平臺(tái)上，包括PC、PC服務(wù)器、UNIX服務(wù)器、中型機(jī)、大型計(jì)算機(jī)上，給用戶的應(yīng)用軟件在不同的平臺(tái)之間的移植創(chuàng)造了極為便利的條件。調(diào)試工具選擇GDB工具，它可以方便的設(shè)置斷點(diǎn)、單步跟蹤，能夠滿足全部的調(diào)試程序的需要。178。①Client與內(nèi)容緩存服務(wù)器請(qǐng)求建立連接的過(guò)程；②服務(wù)器與Client之間進(jìn)行應(yīng)用層握手的過(guò)程；③P2P內(nèi)容主進(jìn)程派生出一子進(jìn)程負(fù)責(zé)處理與Client通信；④子進(jìn)程查詢緩存服務(wù)器，找到Client請(qǐng)求內(nèi)容的過(guò)程，如果沒(méi)有請(qǐng)求內(nèi)容則需要先下載；⑤子進(jìn)程向Client發(fā)送種子文件和擁有該種子的peer列表；C1Cn內(nèi)容請(qǐng)求監(jiān)聽(tīng)進(jìn)程1內(nèi)容緩存服務(wù)器緩存數(shù)據(jù)庫(kù)S1Sn①②③④⑤Client 1Client n內(nèi)容請(qǐng)求監(jiān)聽(tīng)進(jìn)程10S’1S’n圖42 P2P內(nèi)容服務(wù)進(jìn)程工作示意圖說(shuō)明：在P2P緩存服務(wù)器上同時(shí)運(yùn)行10個(gè)P2P內(nèi)容服務(wù)進(jìn)程，10個(gè)進(jìn)程功能完全相同，只是監(jiān)聽(tīng)端口不同而已，端口為68816889這10個(gè)端口。port)子進(jìn)程父進(jìn)程連接種子服務(wù)器下載該種子，并連接原始內(nèi)容服務(wù)器下載內(nèi)容文件能取得內(nèi)容嗎？有這個(gè)種子嗎？采用P2P下載方式下載內(nèi)容文件內(nèi)容完整嗎？結(jié)束子進(jìn)程，釋放資源有無(wú)是向請(qǐng)求該種子的Client返回“無(wú)請(qǐng)求的種子”否是圖43 P2P種子下載程序流程圖建立Socket（sockfd）開(kāi)始(main)Listen客戶端請(qǐng)求內(nèi)容的連接accept 客戶端的P2P內(nèi)容請(qǐng)求使用fork()函數(shù)創(chuàng)建一子進(jìn)程等待客戶端發(fā)送主動(dòng)握手信息向Client發(fā)送被動(dòng)握手信息收到Client主動(dòng)握手信息向Client發(fā)送bitfield信息子進(jìn)程父進(jìn)程建立新socket 與客戶端通信解析握手信息，得到Info_hash收到Client的interest信息向Client發(fā)送unchock信息解析Client發(fā)來(lái)的request信息根據(jù)request信息返回piece信息傳遞內(nèi)容完整嗎？結(jié)束子進(jìn)程，釋放資源圖44 P2P內(nèi)容服務(wù)程序流程圖 數(shù)據(jù)結(jié)構(gòu)與關(guān)鍵算法分析 socketint socket ( /*返回一個(gè)整形的socket描述符 */ int family, /*指明所使用的協(xié)議簇 */ int type, /*socket的類型,UDP或是TCP */ int protocol /*指明使用協(xié)議名 */)。 /* 地址族 */　　 unsigned short int sin_port。178。 P2P種子下載進(jìn)程listenport： 3333 監(jiān)聽(tīng)客戶端連接的端口；get_dest_port： 8080 HTTP服務(wù)器監(jiān)聽(tīng)的服務(wù)器端口；content_svr_port：5555 內(nèi)容服務(wù)器監(jiān)聽(tīng)的服務(wù)端口；178。4) info_hash：元信息文件中的鍵info的20字節(jié)SHA1哈希值。a) keepalive：len=0000 keepalive消息長(zhǎng)度固定，消息長(zhǎng)度后面沒(méi)有任何數(shù)據(jù)。bitfield消息是變長(zhǎng)的，X指bitfield的長(zhǎng)度。如果長(zhǎng)度不正確，或剩余比特位有任何位置1，客戶端都應(yīng)該丟棄連接；h) request:len=0013id=6indexbeginlength request消息長(zhǎng)度固定，用于請(qǐng)求一個(gè)塊。index：4字節(jié)整數(shù)，指明片的索引號(hào)。監(jiān)聽(tīng)端口是該peer的DHT節(jié)點(diǎn)的監(jiān)聽(tīng)端口，該peer應(yīng)被插入到當(dāng)?shù)芈酚杀砩希ㄈ绻鸇HT Tracker支持的話）；說(shuō)明：在連接開(kāi)始時(shí)，Peer之間的狀態(tài)為是“阻塞”和“無(wú)興趣”狀態(tài)，即：216。 peer_interested = 0 （此peer對(duì)該客戶端感興趣） peer結(jié)構(gòu)體P2P緩存服務(wù)器向client返回的peer（結(jié)構(gòu)體）列表（列表中包含N個(gè)peer信息），列表中包含4個(gè)字節(jié)的IP地址，2個(gè)字節(jié)的Port端口號(hào)。 HTTP GET請(qǐng)求格式每個(gè)HTTP請(qǐng)求都包含兩個(gè)部分：1) HTTP請(qǐng)求行，為GET；2) HTTP請(qǐng)求中的可選消息頭，這些消息頭會(huì)由于使用的HTTP客戶端瀏覽器或客戶端瀏覽器配置選項(xiàng)的不同而不同。 數(shù)據(jù)定義178。系統(tǒng)配置表見(jiàn)41，網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)[14]見(jiàn)圖45。另外，它主要用于TCP連接，而在UDP連接中則無(wú)此必要。經(jīng)查閱資料發(fā)現(xiàn)，Linux系統(tǒng)下提供了兩個(gè)用于關(guān)閉進(jìn)程的函數(shù)[9]exit()和_exit()，當(dāng)程序執(zhí)行到exit和_exit時(shí)，進(jìn)程會(huì)無(wú)條件地停止剩下所有的操作，清楚包括PCB在內(nèi)的各種數(shù)據(jù)結(jié)構(gòu)，并終止本進(jìn)程的運(yùn)行。 文件I/O操作過(guò)程本系統(tǒng)中使用的文件I/O操作均是不帶緩存在I/O操作，主要涉及到5個(gè)函數(shù)[9]，open、read、write、lseek、close。經(jīng)仔細(xì)檢查，發(fā)現(xiàn)在打開(kāi)文件時(shí)，open函數(shù)代入了一個(gè)參數(shù)O_TRUNC，這個(gè)參數(shù)的代表：當(dāng)打開(kāi)文件存在時(shí)，并且以只讀或只寫方式成功打開(kāi)時(shí)，首先全部刪除文件原有數(shù)據(jù)，再對(duì)文件進(jìn)行操作，因此才會(huì)發(fā)現(xiàn)原文件大小變?yōu)?。為了解決問(wèn)題，將文件打開(kāi)方式中的追加方式去掉，在將接受到數(shù)據(jù)寫入到文件之前，利用lseek函數(shù)將移動(dòng)文件指針，將指針移到存放該數(shù)據(jù)的首地址。 文件寫操作時(shí)，追加與覆蓋的區(qū)別當(dāng)使用P2P方式下載文件時(shí)，由于文件采取分片傳輸?shù)姆绞剑虼艘啻螌⑹艿降臄?shù)據(jù)寫入到文件中，文件傳送方式是順序的，在打開(kāi)文件時(shí)，就將文件打開(kāi)發(fā)式設(shè)置為追加方式，在用戶正常下載文件時(shí)運(yùn)行很正常。其中每個(gè)函數(shù)都有規(guī)定好的參數(shù)，代入不同的參數(shù)，得到不同的結(jié)果。最大的區(qū)別就在于exit()函數(shù)在調(diào)用exit系統(tǒng)之前要檢查文件打開(kāi)情況，把文件緩沖區(qū)中的內(nèi)容寫回文件，而_exit()則不執(zhí)行此操作。經(jīng)查找，發(fā)現(xiàn)IP地址設(shè)置為INADDR_ANY(即為本地IP地址)，端口選擇8080端口，而8080端口被WWW服務(wù)占用，所以綁定出錯(cuò)，改成3333后綁定成功。 系統(tǒng)測(cè)試時(shí)遇到的問(wèn)題 socket通信中bind問(wèn)題在使用socket通信中，bind()是一個(gè)很重要的函數(shù)，一般在服務(wù)器端程序中使用。 P2P內(nèi)容服務(wù)進(jìn)程LISTENNUM 1000 P2P內(nèi)容服務(wù)進(jìn)程監(jiān)聽(tīng)連接的最大數(shù)；MAXREAD 4096 從文件中讀取到緩沖區(qū)read_buf中數(shù)據(jù)的最大字節(jié)數(shù)，也是每片 的最大數(shù)；MAXMSG 5109 客戶端與服務(wù)器之間進(jìn)行交換信息的最大字節(jié)數(shù)，也即是支持最大 每片為4M字節(jié)的文件下載；SERVERPORT 68816889 P2P內(nèi)容服務(wù)進(jìn)程監(jiān)聽(tīng)端口； 系統(tǒng)軟件測(cè)試 系統(tǒng)測(cè)試環(huán)境由于本系統(tǒng)是面向ISP開(kāi)發(fā)和使用的，但是由于條件限制，不能再真實(shí)的ISP出口處進(jìn)行測(cè)試，因此選擇在局域網(wǎng)內(nèi)測(cè)試。這里可以看到客戶端能夠接收的類型有g(shù)if、bitmap、jpeg等等。 /* IP地址 */ unsigned short int sin_port。 am_interested = 0　 （am_interested：該客戶端對(duì)此peer感興趣）216。block：塊數(shù)據(jù)，是指定索引的片的子集；j) cancel:len=0013id=8indexbeginlength cancel消息固長(zhǎng)，負(fù)載和request消息的一樣。begin：4字節(jié)整數(shù)，指明片內(nèi)的字節(jié)偏移量。最后剩余的比特位置0。該消息通常每?jī)煞昼姲l(fā)送一次；b) chock：len=0001id=0 chock消息長(zhǎng)度固定，且沒(méi)有負(fù)載；c) unchock：len=0001id=1 unchock消息長(zhǎng)度固定，且沒(méi)有負(fù)載；d) interested：len=0001id=2 interested消息長(zhǎng)度固定，且沒(méi)有負(fù)載；e) not interested:len=0001id=3 not interested消息長(zhǎng)度固定，且沒(méi)有負(fù)載；f) have:len=0005id=4piece index have消息長(zhǎng)度固定，負(fù)載是一個(gè)片的索引，該索引從零開(kāi)始，是成功下載并且通過(guò)哈希驗(yàn)證的；g) bitfield：len=0001+Xid=5bitfield bitfield消息可能只在握手系列完成后立刻發(fā)送，在這之前沒(méi)有其他任何消息發(fā)送。 消息流message的格式[13]長(zhǎng)度前綴消息 ID負(fù)載。2) pstr:協(xié)議的字符串標(biāo)志（通常為BitTorrent protocol）。router_addr： 路由器將P2P數(shù)據(jù)報(bào)轉(zhuǎn)發(fā)給P2P緩存服務(wù)器的sockaddr；getclient_addr： 請(qǐng)求種子的客戶端的sockaddr；seedserver_addr： 種子服務(wù)器的sockaddr；cont