ICN在社交網(wǎng)絡(luò)中的應(yīng)用

Information-CentricNetworking:

ANaturalDesignfor

SocialNetworkApplications

ICN在社交網(wǎng)絡(luò)中的應(yīng)用目錄一、研究背景二、CCN三、評估比較四、總結(jié)第1頁/共20頁

目前網(wǎng)絡(luò)廣泛應(yīng)用的IP包具有簡單的幀結(jié)構(gòu)，可以使網(wǎng)絡(luò)互聯(lián)成本降低，硬件互聯(lián)實現(xiàn)簡便，具有非常強(qiáng)的適應(yīng)力。

但從技術(shù)發(fā)展的角度來看，互聯(lián)網(wǎng)最初是為了追求網(wǎng)絡(luò)的互聯(lián)，以實現(xiàn)硬件資源的共享（那時硬件資源稀缺且成本較高），通過共享可以節(jié)省成本和提高效率。

然而，隨著技術(shù)的進(jìn)步和互聯(lián)網(wǎng)應(yīng)用的普及，計算機(jī)硬件和附屬器材的價格大大下降，硬件共享的必要性已經(jīng)不大。用戶關(guān)注的是信息，而不是信息的存儲位置，信息共享成為了目標(biāo)。我們所關(guān)注的重點在于內(nèi)容傳遞的速度、質(zhì)量以及安全性，達(dá)到更好的用戶體驗。

因此以信息為中心的網(wǎng)絡(luò)構(gòu)建就成為了現(xiàn)今的研究重點。1.1ICN(信息中心網(wǎng)絡(luò))

1/3第2頁/共20頁1.1ICN(信息中心網(wǎng)絡(luò))

2/3

為了適應(yīng)如今用戶對海量信息的訪問需求，應(yīng)分離計算、存儲、通信、應(yīng)用與信息的聯(lián)系，擺脫傳統(tǒng)體系結(jié)構(gòu)對信息的束縛，使信息成為體系結(jié)構(gòu)的設(shè)計中心，網(wǎng)絡(luò)通信模型為互連信息。 ICN采用以信息為中心的網(wǎng)絡(luò)通信模型，取代傳統(tǒng)的以地址為中心的網(wǎng)絡(luò)通信模型，通信模式從主機(jī)到主機(jī)演進(jìn)為主機(jī)到網(wǎng)絡(luò)，體系結(jié)構(gòu)支持主機(jī)移動，傳輸模式由傳統(tǒng)的“推”改為“拉”，解決了海量信息高效傳輸?shù)膯栴}。第3頁/共20頁1.1ICN(信息中心網(wǎng)絡(luò))

3/3ICN采用信息名字為網(wǎng)絡(luò)傳輸?shù)臉?biāo)識，IP地址不被考慮或者只作為一種底層的本地化的傳輸標(biāo)識。

傳統(tǒng)體系結(jié)構(gòu)的通信模式是主機(jī)之間的通信，通過源主機(jī)地址和目的主機(jī)地址獲取通信路徑，ICN則采用主機(jī)到網(wǎng)絡(luò)的通信模式，通過信息名字獲取源主機(jī)到網(wǎng)絡(luò)信息的通信路徑。第4頁/共20頁1.2社交網(wǎng)絡(luò) 1/1

每天都有幾百萬人通過互聯(lián)網(wǎng)進(jìn)行社交活動，社交網(wǎng)絡(luò)正重新定義我們使用網(wǎng)絡(luò)的方式：瀏覽網(wǎng)頁產(chǎn)生、分享各種類型的內(nèi)容。而隨著社交網(wǎng)絡(luò)中信息的快速病毒式的傳播，傳統(tǒng)的終端到終端（end-to-end）的通信趨于消失，讓位給一對多(one-to-many)或多對多(many-to-many)的傳播和檢索內(nèi)容。end-to-end通信模式存在明顯的不足，比如每次存取內(nèi)容，都要間接映射到內(nèi)容所在的設(shè)備。

一項最新的研究表明：網(wǎng)絡(luò)上的分享活動占了超過10％的互聯(lián)網(wǎng)流量。其中Facebook占主導(dǎo)地位(占了38％)。

因此，社交網(wǎng)絡(luò)是一個新的強(qiáng)大的傳播和查找內(nèi)容的手段。

目錄一、研究背景二、CCN三、評估比較四、總結(jié)第5頁/共20頁2.1ICN的原理 1/2IPICN通信機(jī)制在傳輸數(shù)據(jù)之前在用戶和存儲所需信息的主機(jī)間建立通信路徑，由發(fā)送者向接收者放送數(shù)據(jù)用戶不知道可以提供所需信息的主機(jī)地址，從用戶出發(fā)建立達(dá)到信息提供端的路徑，然后方向傳輸數(shù)據(jù)網(wǎng)絡(luò)功能尋找達(dá)到終端的路徑尋找匹配的內(nèi)容尋址轉(zhuǎn)發(fā)依據(jù)IP地址

內(nèi)容名稱數(shù)據(jù)和地址

耦合

分離第6頁/共20頁2.1ICN的原理 2/2

網(wǎng)絡(luò)節(jié)點擁有緩存區(qū)有時，當(dāng)我們想要獲取某項信息時，我們所獲得的結(jié)果并不一定是信息所在的服務(wù)器傳輸過來的，而可能是由最近節(jié)點中緩存?zhèn)鬏斶^來的。第7頁/共20頁2.2CCN簡介 1/1在ICN中研究熱點是內(nèi)容中心網(wǎng)絡(luò)(CCN)，CCN是2009年提出，CCN將IP作為底層網(wǎng)絡(luò)，沒有TCP層的概念，增加了策略層和安全層，策略層作為網(wǎng)絡(luò)層的下一層，為路由提供決策。在CCN中主要有兩種數(shù)據(jù)包：

內(nèi)容請求包(interestpacket)

終端節(jié)點發(fā)送，用于請求其感興趣的內(nèi)容；

根據(jù)其內(nèi)容名稱被識別；內(nèi)容數(shù)據(jù)包(datapacket)

作為內(nèi)容請求包的應(yīng)答信息；

符合需求的內(nèi)容數(shù)據(jù)包被同一內(nèi)容名稱識別；

因此，傳統(tǒng)的IP地址、轉(zhuǎn)發(fā)表都不再適合CCN。CCN解析內(nèi)容名稱而不是IP地址。第8頁/共20頁2.3CCN節(jié)點模型 1/3CCN節(jié)點承擔(dān)著數(shù)據(jù)包的存儲、轉(zhuǎn)發(fā)和路由任務(wù)。典型的CCN節(jié)點主要包含內(nèi)容存儲器（CS）、待定請求表（PIT）和前向轉(zhuǎn)發(fā)表（FIB）3個部分。CS(contentstore):CS類似于IP路由器的緩存,但是在每次通信結(jié)束后不會清空緩存的內(nèi)容，可以將該內(nèi)容用于下次通信。這是CCN非常關(guān)鍵的理念，它可以幫助減少內(nèi)容下載時延和網(wǎng)絡(luò)帶寬占用。PIT(pendinginteresttable):用于記錄經(jīng)過的請求信息的來源接口，以此實現(xiàn)所請求的內(nèi)容順利地傳回請求節(jié)點。內(nèi)容數(shù)據(jù)包按照PIT的提示，一步步轉(zhuǎn)發(fā)回內(nèi)容請求者。當(dāng)內(nèi)容傳回后，該條目從PIT中刪除。FIB(forwardinginformationbase):根據(jù)內(nèi)容名稱將請求數(shù)據(jù)包轉(zhuǎn)發(fā)至信息存在的節(jié)點（CCN不涉及目的地的概念）可以同時向多個方向轉(zhuǎn)發(fā)請求。第9頁/共20頁2.3CCN節(jié)點模型 2/3第10頁/共20頁2.3CCN節(jié)點模型 3/3CCN的轉(zhuǎn)發(fā)過程分三個步驟：1.接收到請求數(shù)據(jù)包后，首先匹配內(nèi)容緩存，如果有相關(guān)內(nèi)容，直接發(fā)送。否則在PIT中查詢。2.如果PIT中有相應(yīng)的條目，添加請求端口到列表中。在這一過程中，將請求數(shù)據(jù)包截留是為了防止同樣數(shù)據(jù)的重復(fù)請求。當(dāng)有內(nèi)容數(shù)據(jù)包回應(yīng)時，將此內(nèi)容發(fā)送給所有請求數(shù)據(jù)的端口。3.若PIT中沒有相關(guān)內(nèi)容條目，則查詢FIB。按照FIB的指示將該數(shù)據(jù)包轉(zhuǎn)發(fā)到下一CCN節(jié)點。第11頁/共20頁2.4IP-CDN-CCN網(wǎng)絡(luò)設(shè)備 1/1CDN(ContentDeliveryNetwork內(nèi)容分發(fā)網(wǎng)絡(luò))核心思想是盡可能避開互聯(lián)網(wǎng)上有可能影響數(shù)據(jù)傳輸速度和穩(wěn)定性的瓶頸和環(huán)節(jié)，使內(nèi)容傳輸?shù)母?、更穩(wěn)定。實時地根據(jù)網(wǎng)絡(luò)流量和各節(jié)點的連接、負(fù)載狀況以及到用戶的距離和響應(yīng)時間等綜合信息將用戶的請求重新導(dǎo)向離用戶最近的服務(wù)節(jié)點上。

其目的是使用戶可就近取得所需內(nèi)容，解決Internet網(wǎng)絡(luò)擁擠的狀況，提高用戶訪問網(wǎng)站的響應(yīng)速度。第12頁/共20頁2.4IP-CDN-CCN網(wǎng)絡(luò)設(shè)備 1/1IP網(wǎng)絡(luò)：用戶直接從服務(wù)器獲得內(nèi)容CDN：用戶從CDNnode中獲得數(shù)據(jù)第13頁/共20頁2.4IP-CDN-CCN網(wǎng)絡(luò)設(shè)備 1/1CCN：用戶從網(wǎng)絡(luò)節(jié)點

獲得內(nèi)容第14頁/共20頁2.4CCN在社交網(wǎng)絡(luò)中的應(yīng)用 1/1 Facebook為每個用戶提供了唯一的ID，我們可以據(jù)此來進(jìn)行CCN的命名。目錄一、研究背景二、CCN三、評估比較四、總結(jié)第15頁/共20頁3.0評估的假設(shè)、限定 1/11、以法國的Twitter用戶為例進(jìn)行仿真，Twitter服務(wù)器位于法國以外；CDN的一個CDNnode位于美國，一個CDNnode位于法國國內(nèi)網(wǎng)絡(luò)的對等點。2、為了能與ICN比較，CDN不只傳輸視頻、圖像等大塊內(nèi)容，也傳輸tweets.3、為了使效果明顯，服務(wù)器得有很多很多的內(nèi)容，這使得CDNnode不能距離終端用戶太近；4、參數(shù)（已有的文獻(xiàn)資料）：法國的tweet用戶為300萬（評估中用戶數(shù)量為0—500萬的變化范圍），平均每個用戶發(fā)送0.97條tweet/天，給定組的用戶粉絲數(shù)量服從冪律分布曲線；5、由于CS大小的限制，ICN節(jié)點不可能存儲所有用戶需求的Twitter內(nèi)容，所以設(shè)置不同的緩存命中率（5%—80%）；第16頁/共20頁3.1網(wǎng)絡(luò)負(fù)載的估計 1/2評估參數(shù)：現(xiàn)在法國的3百萬Twitter用戶每秒大約發(fā)送1250條tweets，平均每條tweet長度約為120字，所以twitter用戶產(chǎn)生的文字流量為1.2Mb/s。

其中3%的tweets為視頻或圖片分享鏈接：

視頻內(nèi)容：一個中等質(zhì)量的視頻一般編碼率為512kb/s，平均一個被分享的視頻大約持續(xù)2分鐘，產(chǎn)生60Mb流量。

圖片內(nèi)容：一張圖片大約50Kb。

包含視頻或圖片的tweets總是比純文本的更加流行，如果我們綜合考慮這些，每秒產(chǎn)生的1250條tweets的網(wǎng)絡(luò)負(fù)載約為1.13Gbs/s。第17頁/共20頁3.1網(wǎng)絡(luò)負(fù)載比較 2/2

對于一個給定的內(nèi)容，隨著用戶數(shù)量的增長，ICN的網(wǎng)絡(luò)負(fù)載相對于IP網(wǎng)絡(luò)會急劇減少。第18頁/共20頁3.2時延比較 1/1LegacyTwitter：IP網(wǎng)絡(luò)中法國的用戶從美國服務(wù)器請求內(nèi)容的時延CDNTwitter：命中時從CDNnode中請求數(shù)據(jù)，否則同上；ICNTwitter：由CCN節(jié)點組成的ICN網(wǎng)絡(luò)的請求時延；目錄一、研究背景二、CCN三、評估比較四、總結(jié)第19頁/共20頁4.1思考 1/1

Information-CentricNetworking:ANaturalDesignforSocialNetworkApplications1、信息命名是ICN的關(guān)鍵技術(shù)之一，設(shè)置合適的名字能提高整個通信的效率，降低FIB表項，而社交網(wǎng)絡(luò)自身提供了唯一的ID號區(qū)分用戶產(chǎn)生的信息，有天然的可聚合性；2、物理位置相鄰的用戶有較大的可能性擁有相似的愛好（關(guān)注相同的用戶），因此網(wǎng)絡(luò)緩存的命中率會更高；3、社交網(wǎng)絡(luò)中更容易存在時時熱點信息，使得緩存時間可以相對更短同時緩存命中率依然較高。根據(jù)社交網(wǎng)絡(luò)的特點可以設(shè)計簡便的緩存策略。

第20頁/共20頁4