應用層網(wǎng)絡介紹

應用層網(wǎng)絡Application-layerOverlayNetworks覆蓋網(wǎng)絡（OverlayNetwork）網(wǎng)絡：一群互連的、可以相互通信的計算機，定義了主機間通信所使用的編址、路由及服務模型。覆蓋網(wǎng)絡：建立在一個或多個已有網(wǎng)絡之上的邏輯網(wǎng)絡；改變底層網(wǎng)絡的一個或幾個特性，以實現(xiàn)底層網(wǎng)絡所不能提供的某種網(wǎng)絡服務。替代覆蓋網(wǎng)絡的方案：修改已有網(wǎng)絡因特網(wǎng)是一個覆蓋網(wǎng)絡因特網(wǎng)是建立在眾多物理網(wǎng)絡及電信線路上的邏輯網(wǎng)絡增加了一個在網(wǎng)間尋址及路由的IP層實現(xiàn)數(shù)據(jù)包跨物理網(wǎng)絡的傳輸覆蓋網(wǎng)絡的應用路由（如路由覆蓋網(wǎng)絡）尋址（如對等網(wǎng)絡）安全（如VPN）多播（如MBone）移動（如移動IP）……覆蓋網(wǎng)絡的優(yōu)點和缺點優(yōu)點：一般不需要部署新的設備，不修改或很少修改已有的軟件/協(xié)議（但需要在已有軟件上部署新的軟件）。不需要在每一個節(jié)點上都部署新軟件。缺點：協(xié)議棧中增加了一個層次，增加了包頭及包處理開銷節(jié)點的負擔加重了擴放性問題應用層網(wǎng)絡應用層網(wǎng)絡是在因特網(wǎng)上構建的一個完全位于應用層的網(wǎng)絡系統(tǒng)。應用層網(wǎng)絡由分布在因特網(wǎng)上的一組主機組成：為一個或多個應用程序提供下層基礎設施（網(wǎng)絡服務）采用與目前因特網(wǎng)不同的方法轉發(fā)和處理應用程序的數(shù)據(jù)由第三方運營和管理，不是當前因特網(wǎng)體系結構的一部分。應用層網(wǎng)絡實際上是基于因特網(wǎng)的大規(guī)模分布式應用，因借助網(wǎng)絡層的一些技術來進行成員之間的尋址和路由而具有了網(wǎng)絡層的某些特征。典型的應用層網(wǎng)絡系統(tǒng)路由覆蓋網(wǎng)絡應用層組播內容分發(fā)網(wǎng)絡P2P系統(tǒng)1路由覆蓋網(wǎng)絡因特網(wǎng)路由策略僅反映ISP對開銷和運行效率的考慮，端用戶和應用程序無法參與。對于有些應用來說，因特網(wǎng)路由協(xié)議（OSPF/RIP、BGP）所選的路由不能滿足其要求。路由覆蓋網(wǎng)絡的目的是為上層應用提供更好的路由服務，滿足其特殊的應用需求。1.1彈性覆蓋網(wǎng)絡

ResilientOverlayNetworks（RON）RON是為解決BGP路由失效恢復慢的問題而提出的，其設計目標為：快速檢測和恢復路由失效20秒內檢測到路由失效（停運或性能下降）并恢復緊密集成路由選擇與應用允許應用定義路由失效和對失效的響應允許應用選擇適合自己的路徑度量來選擇路徑靈活的策略路由允許針對單個用戶或主機定義路由策略

RON概述RON是建立在已有因特網(wǎng)路由結構上的一個應用層覆蓋網(wǎng)絡。RON節(jié)點監(jiān)視在它們之間的因特網(wǎng)路徑的質量，使用這些信息決定直接使用因特網(wǎng)的路由結構，還是將數(shù)據(jù)包路由到其它RON節(jié)點，以優(yōu)化應用特定的路由度量。RON體系結構模型RON客戶通過管道（conduit）與RON節(jié)點交互Probes負責探測虛鏈接狀態(tài)Router實現(xiàn)路由協(xié)議Forwarder提供分組轉發(fā)功能性能數(shù)據(jù)庫保存虛鏈接狀態(tài)信息（延遲、分組丟失率、鏈路吞吐量）RON節(jié)點RON節(jié)點是運行了RON軟件的主機，實現(xiàn)和路由器類似的功能。任意兩個RON節(jié)點之間維護一條由下層因特網(wǎng)鏈路構成的路徑（虛鏈接）。每個節(jié)點及時探測到其余節(jié)點的虛鏈接狀態(tài)，保存在本地的性能數(shù)據(jù)庫中。RON的設計目標是為一組RON客戶（使用RON轉發(fā)數(shù)據(jù)的應用程序）提供更可靠的IP路由機制。RON工作過程第一個RON節(jié)點（入節(jié)點）對分組進行分類，決定分組要使用的路徑類型（低延遲或高吞吐率等），為其選擇一條路由。若下一跳為一個RON節(jié)點，入節(jié)點為分組封裝一個RON報頭（包含一個流標簽），發(fā)送到下一個RON節(jié)點。入節(jié)點對后續(xù)到達的屬于同一個客戶的分組標上相同的流標簽，直接查找流緩存表轉發(fā)。后續(xù)RON節(jié)點根據(jù)目的地址和流標簽決定下一跳（不再進行分類）。最后一個RON節(jié)點（出節(jié)點）將分組交給RON客戶。RON路由的特點支持不同的路由策略：使用不同的鏈路度量參數(shù)維護多條路徑根據(jù)RON客戶程序的需要選擇最合適的路徑RON路由的工作要點路徑評估：節(jié)點使用停運檢測（outagedetection）算法，主動探測到其它RON節(jié)點之間的虛鏈路是否工作。針對每一種路徑度量（延遲、丟包率、吞吐率），給出表明路徑有多“好”的數(shù)值。鏈路狀態(tài)傳播：節(jié)點周期性地從本地性能數(shù)據(jù)庫中取出到其它節(jié)點的各種路徑度量的匯總信息，通過RON本身的網(wǎng)絡發(fā)送。路由表構成針對每一種路由策略計算一組路由表，每一個路由表針對一種路徑度量計算得到。路由表的層次結構：每個策略標簽指向一個路由偏好表。每個路由偏好對應一種路徑度量的路由表。RON轉發(fā)轉發(fā)器檢查每個到來分組的RON報頭，確定要發(fā)給本地客戶還是一個遠程節(jié)點：如果去往本地客戶，利用RON報頭中的packettype將數(shù)據(jù)包交給對應的RON客戶。如果flowID匹配流緩存表中的一個表項，使用表項中的路由信息。如果flowID不匹配流緩存表中的任何表項，利用RON報頭查找路由表。RON報頭結構路由表查找過程路由表查找分三步完成：基于策略類型查找基于路由偏好查找基于目的地址查找1.2服務覆蓋網(wǎng)絡

ServiceOverlayNetworks（SON）每個ISP只關心自己網(wǎng)絡的性能，并只對自己的用戶提供服務保證。BGP只能找到一條可達的路由，無法保證端-端應用性能。SON是為了在因特網(wǎng)上提供端-端服務質量（QualityofService，QoS）而提出的，以方便創(chuàng)建和部署QoS敏感的增值業(yè)務。SON的實現(xiàn)基礎SON服務商通過雙邊服務協(xié)議（ServiceLevelAgreement，SLA）從各個ISP購買具有一定QoS保證的帶寬，在已有因特網(wǎng)上構造一個邏輯的端-端服務投送網(wǎng)絡。用戶通過業(yè)務合同，直接向SON服務商付費來使用SON提供的增值服務。SON體系結構SON由服務網(wǎng)關連接而成兩個服務網(wǎng)關之間的邏輯連接由底層ISP提供，帶寬和服務質量由雙邊SLA保證。SON的優(yōu)點引入一個新的流量聚合層次（服務聚合）：ISP按流量所屬的SON進行流量聚合。解除了應用服務與網(wǎng)絡服務的耦合：ISP根據(jù)SLA設置數(shù)據(jù)傳輸服務（粗粒度）。SON采用與服務相關的帶寬管理、流量工程和QoS保證機制，確保服務的端-端服務質量（細粒度）。減小了管理和控制網(wǎng)絡服務的復雜性允許靈活地創(chuàng)建和部署新的增值服務1.3面向服務的因特網(wǎng)

ServiceOrientedInternet（SOI）

覆蓋網(wǎng)絡的缺點：由于完全不考慮網(wǎng)絡層，一定程度的低效率是不可避免的。有些覆蓋網(wǎng)絡提供的服務需要底層網(wǎng)絡的支持才能發(fā)揮作用。有些功能在多個覆蓋網(wǎng)中重復實現(xiàn)。服務覆蓋網(wǎng)下面需要一個底層基礎架構，解決覆蓋網(wǎng)的低效問題，并支持新的應用需求。SOI概述SOI在邏輯上分離數(shù)據(jù)傳輸網(wǎng)絡和服務覆蓋網(wǎng)絡：數(shù)據(jù)傳輸網(wǎng)絡：大致對應當前的自治系統(tǒng)，為服務覆蓋網(wǎng)提供比特管道服務。服務覆蓋網(wǎng)絡：由服務提供商運營，向訂戶（服務訂購者）提供特殊的增值服務。服務覆蓋網(wǎng)絡被抽象成服務云，在多個地方與數(shù)據(jù)傳輸網(wǎng)絡接口。用戶請求在數(shù)據(jù)網(wǎng)絡上被路由到某個服務云的最近（或最合適）入口，由服務云中的某個主機服務。SOI體系結構SOI概述（續(xù)）數(shù)據(jù)網(wǎng)絡與服務網(wǎng)絡邏輯分離的好處：允許這兩種網(wǎng)絡獨立進化，在支持已有服務的同時方便未來因特網(wǎng)服務的靈活部署。實現(xiàn)邏輯獨立性的機制：徹底分離數(shù)據(jù)網(wǎng)絡與服務網(wǎng)絡的編址、路由和轉發(fā)機制每個服務云可以獨立實現(xiàn)自己的編址、路由和轉發(fā)機制SOI的抽象SOI是建立在已有IP網(wǎng)絡之上、為靈活部署新的因特網(wǎng)服務而提供的一個公共平臺。SOI架構基于三個重要的抽象：服務云面向服務的編址方案（服務云，云中的對象）服務層（服務網(wǎng)關，服務存在點）（1）服務云服務云是一群部署在因特網(wǎng)上、相互協(xié)作向用戶提供應用服務的服務實體（如服務器、代理、緩存、內容交換機等）。服務云是一個虛擬的服務覆蓋網(wǎng)絡，依靠下層網(wǎng)絡域在因特網(wǎng)范圍傳輸數(shù)據(jù)。服務云和因特網(wǎng)的接口稱為服務存在點，數(shù)據(jù)對象進出服務云只能通過服務存在點。（2）面向服務的編址方案SOI的編址方案提供服務云及服務云中對象的位置無關標識：每個服務云被分配一個固定長度（32位）的ID（稱sid），由一個中央權威機構管理。服務云中的對象用一個對象ID（稱oid）標識，其語法和語義由各個服務云定義，只在服務云內部使用。命名與名字解析服務云的命名與解析：每個服務云大致對應了目前具有兩層或三層域名的一個機構（如），機構的域名就作為服務名?？梢灾赜肈NS或建一個類似的名字解析系統(tǒng)，將服務名解析為sid。對象的命名與解析：服務云根據(jù)自己的商業(yè)需要定義對象的命名和編址系統(tǒng)。服務云提供對象解析的功能。將兩級地址的解析分開，增加了靈活性和安全性。（3）服務層SOI架構的基礎是位于IP層之上的一個服務層，包含兩個網(wǎng)絡單元：服務網(wǎng)關：可看成是下層網(wǎng)絡域的擴展，通常部署在網(wǎng)絡域邊緣，負責穿過網(wǎng)絡域的路由和服務交付。服務存在點：服務云與網(wǎng)絡域接口的地方，邏輯上是服務云的一部分，負責在服務云內部交付對象。進出服務云的數(shù)據(jù)都要經(jīng)過服務網(wǎng)關，服務網(wǎng)關提供服務區(qū)分、識別和跟蹤服務云流量的功能。服務層在協(xié)議棧中的位置服務層協(xié)議數(shù)據(jù)單元（服務對象）服務對象頭部分為sid部分和oid部分服務修正符由服務云定義，對服務對象的轉發(fā)有影響。服務網(wǎng)關（ServiceGateway）數(shù)據(jù)面功能：根據(jù)目的sid（或目的sid+源sid）及相關的服務修正符，將服務對象轉發(fā)到去往目的服務云的下一跳（相鄰的S-POP或另一個SG）?？刂泼婀δ埽哼\行服務網(wǎng)關路由協(xié)議，建立服務路由表。服務路由表包含目的sid（及相關的服務修正符）到下一跳SG/S-POP（用IP地址表示）的映射。服務存在點（S-POP）服務存在點有兩個主要功能：與服務網(wǎng)關合作，為它所代理的服務云路由和轉發(fā)服務對象（發(fā)往服務云外部）。和服務云中的其它S-POP合作，在服務云內部路由和轉發(fā)服務對象。（服務云內部機制）為實現(xiàn)第一個功能：控制面：參與服務網(wǎng)關路由協(xié)議，建立（部分的）服務路由表，表中包含從sid空間到相鄰SG的映射。數(shù)據(jù)面：利用服務路由表，將服務對象轉發(fā)到服務云外。服務網(wǎng)關路由協(xié)議服務網(wǎng)關路由協(xié)議主要負責建立服務路由表，包括兩個部分：S-POP注冊和公告：S-POP向本地服務網(wǎng)關注冊，通告其存在、所代表的服務云sid、能夠處理的流量類型（一組服務修正符）。傳播服務可達性：從鄰居服務網(wǎng)關學習路徑和向它們發(fā)布路徑（類似BGP）。參考文獻ResilientOverlayNetworks.SOSP2001.ServiceOverlayNetworks:SLAs,QoSandBandwidthProvisioning.ICNP’02.ServiceOrientedInternet.2應用層組播IP組播體系結構：路由器采用分布式算法構造一棵數(shù)據(jù)轉發(fā)樹；組播分組沿轉發(fā)樹轉發(fā)時，在樹的分支節(jié)點處由路由器進行復制。IP組播協(xié)議：MOSPF、DVMRP等。IP多播骨干網(wǎng)：MBoneIP組播是實現(xiàn)組播轉發(fā)的最有效方法，可使全網(wǎng)范圍的分組復制數(shù)量最少。IP組播的缺點路由器必須為每個組播組單獨保存狀態(tài)，路由表和轉發(fā)表也需要為每個組播組維護一個地址項（組播地址不能聚合），擴展性很差。要求所有路由器支持組播功能，給IP組播的推廣使用帶來很大困難。試圖用一種統(tǒng)一的組播模型來適應所有的應用，給組播算法的設計造成很大困難。組播組的管理開銷大。在IP組播中實現(xiàn)可靠性和擁塞控制非常困難。在經(jīng)濟方面，尚沒有針對組播的流量計費機制。應用層組播在應用層上，依靠端系統(tǒng)之間的單播實現(xiàn)組播。優(yōu)點：不需要改變現(xiàn)有路由器，能夠很快進入應用。單播技術較成熟，基于單播實現(xiàn)的應用層組播易于實現(xiàn)差錯控制、流量控制、擁塞控制等。缺點：延遲較大：應用層組播不考慮網(wǎng)絡本身的拓撲結構。效率不如IP組播：應用層組播會產(chǎn)生較多數(shù)據(jù)冗余。

應用層組播研究如何構造并維護高效率的覆蓋網(wǎng)絡。應用層組播的例子：OvercastOvercast網(wǎng)絡用于單源組播，由以下幾個部分組成：一個源服務器任意數(shù)目分布在因特網(wǎng)上的中間節(jié)點（有永久存儲的PC機）分布在因特網(wǎng)上的標準HTTP客戶（Web瀏覽器）分發(fā)樹建立協(xié)議：將中間節(jié)點組織成一棵以源為根的分發(fā)樹。多播組的命名Overcast借用HTTPURL表示多播組：hostname指出一個Overcast網(wǎng)絡的根，源相同的所有組共享一棵分發(fā)樹。Path指示該網(wǎng)絡中的一個多播組。標準的HTTP客戶都可以加入這些多播組。使用URL作為多播組的名字空間有以下好處：分層的名字空間解決了多播組地址空間缺乏的問題。基于HTTP的應用不加修改就能使用到多播。URL結構豐富，表達能力強。Overcast的應用：視頻分發(fā)系統(tǒng)系統(tǒng)由一個studio和在一些合適位置放置的appliance組成，appliance和studio協(xié)作組織成一棵分發(fā)樹。studio存儲內容，并根據(jù)需要調度內容到appliance上。內容發(fā)布者生成一個web頁，發(fā)布內容的鏈接。用戶點擊內容的URL后，瀏覽器根據(jù)hostname將請求發(fā)送到studio。Studio根據(jù)path將請求發(fā)送到客戶附近的appliance。節(jié)點初始化節(jié)點初始化（節(jié)點配置和注冊）：確定節(jié)點進行一般IP連接所需要的IP地址和網(wǎng)關地址（DHCP服務或手工配置）。向一個全局的、熟知的注冊機構發(fā)送自己的序列號。注冊機構提供給節(jié)點一個應當加入的Overcast網(wǎng)絡列表、一個可選的永久IP配置、應當服務的網(wǎng)絡區(qū)域、應當執(zhí)行的訪問控制。建立分發(fā)樹Overcast建立轉發(fā)樹的原則是，最大化從根（源服務器）到所有中間結點的帶寬：將節(jié)點放置在盡可能遠離根的地方，同時不犧牲到根的帶寬。得到一棵較深的分發(fā)樹，節(jié)點在分發(fā)樹上得到的帶寬不低于其直接從根獲取內容得到的帶寬。分發(fā)樹的建立過程當有一個新節(jié)點向根注冊時，啟動分發(fā)樹建立過程：設根為“當前節(jié)點”；新節(jié)點檢測直接到“當前節(jié)點”的帶寬，以及經(jīng)過“當前節(jié)點”的各個孩子節(jié)點到達“當前節(jié)點”的帶寬；如果經(jīng)由某個孩子節(jié)點到“當前節(jié)點”的帶寬和從它直接到達“當前節(jié)點”的帶寬一樣高，該孩子節(jié)點成為“當前節(jié)點”，繼續(xù)探測。如果有多個孩子節(jié)點滿足條件，距離新節(jié)點最近（跳數(shù)最少）的孩子節(jié)點成為“當前節(jié)點”。如果沒有一個孩子節(jié)點滿足條件，“當前節(jié)點”成為父節(jié)點，搜索過程結束。分發(fā)樹的自適應調整節(jié)點周期性地重新評估它在樹中的位置：如果到某個兄弟節(jié)點的帶寬不低于到父節(jié)點的帶寬，將自己置于該兄弟節(jié)點之下。如果直接到祖父節(jié)點的帶寬大于到父節(jié)點的帶寬，將自己置為當前父節(jié)點的兄弟節(jié)點。Overcast網(wǎng)絡容忍非根節(jié)點的失效：當節(jié)點發(fā)現(xiàn)父節(jié)點不可達時，將自己連接到祖父節(jié)點下。如果祖父節(jié)點不可達，節(jié)點繼續(xù)沿系譜往上移，直到找到一個當前活躍的節(jié)點。網(wǎng)絡維護每個節(jié)點維護一張表，記錄在樹中低于自己的節(jié)點的信息，根節(jié)點的信息表包含樹中所有節(jié)點的最新信息。每個節(jié)點周期性地向父節(jié)點報告自己的存在：如果一個孩子節(jié)點在預定的時間間隔內沒有報告，父節(jié)點在表中記錄該孩子及其子孫節(jié)點“死了”。節(jié)點還會報告其觀察到或被告知的信息，如錯過報告時間的孩子和新增的孩子等。

加入多播組web客戶發(fā)送一個包含該多播組URL的HTTPGET請求，URL的hostname指出分發(fā)樹的根，path指出多播組。根節(jié)點使用path、用戶位置以及當前狀態(tài)數(shù)據(jù)庫決定將用戶從樹的哪個位置接入。用Overcast實現(xiàn)多播數(shù)據(jù)在父節(jié)點和子節(jié)點之間通過TCP傳輸：內容可能會流水地通過樹上的幾代節(jié)點。一個大文件或一段長時間的實時流可能會同時在幾十個不同的TCP流中傳輸。如果出現(xiàn)路徑失效：重建分發(fā)樹；節(jié)點檢查日志，重新啟動未完成的傳輸。參考文獻Overcast:ReliableMulticastingwithanOverlayNetwork.OSDI2000.

3內容分發(fā)網(wǎng)絡

ContentDeliveryNetworks（CDN）提高Web服務性能主要圍繞網(wǎng)絡傳輸和服務器兩個方面：提高單臺web服務器的性能：增加更多的內存和磁盤空間，使用更高速的處理器（或多處理器），使用緩存來減少讀盤次數(shù)等。性能提高有限，響應延遲受網(wǎng)絡擁塞影響大。建立服務器集群（serverfarm）：多個web服務器分擔對同一個web站點的訪問請求。響應延遲受網(wǎng)絡擁塞影響大。提高Web服務性能的方法（續(xù)）建立分級的web緩存機制：將用戶最近訪問過的網(wǎng)頁保留在高速緩存中，使用一個代理（proxy）來管理緩存。瀏覽器配置為向代理請求網(wǎng)頁，若本地緩存沒有，向上一級代理或源服務器請求。提高Web服務性能的方法（續(xù)）建立內容分發(fā)網(wǎng)絡：在因特網(wǎng)的不同地方設置鏡像服務器，將用戶請求重定向到最近的服務器。有助于減小網(wǎng)絡傳輸和服務器負載對請求響應時間的影響。

CDN涉及的主體內容提供商（customer）：提供內容服務的機構或公司，其內容保存在源服務器（originserver）。CDN提供商：擁有CDN架構，為內容提供商提供快速可靠的內容遞送服務。端用戶（client）：從內容提供商的網(wǎng)站上訪問內容的實體。內容分發(fā)環(huán)境CDN的內容CDN一般保存靜態(tài)內容：如圖像、視頻、媒體剪輯、廣告、動態(tài)網(wǎng)頁中的嵌入式對象等。在CDN的上下文中，內容泛指任何數(shù)字形式的數(shù)據(jù)資源，主要包括兩大部分：經(jīng)過編碼的媒體。元數(shù)據(jù)：用來標識、發(fā)現(xiàn)和管理媒體數(shù)據(jù)的內容描述。CDN的客戶CDN的客戶一般是媒體和因特網(wǎng)廣告公司、數(shù)據(jù)中心、ISP、在線音樂零售商、移動運營商、消費電子生產(chǎn)商等。CDN客戶希望可靠而及時地在因特網(wǎng)上向端用戶發(fā)布和投送內容。CDN提供商根據(jù)投送給端用戶的內容（即流量）向內容提供商收費。CDN的體系結構基礎結構：提供基礎設施資源，由通過高速網(wǎng)絡連接的分布式計算資源和網(wǎng)絡基礎設施組成。通信和連接：提供核心的互連網(wǎng)協(xié)議、CDN特定的協(xié)議、認證協(xié)議、安全通信協(xié)議SSL。CDN：CDN核心功能。端用戶：web用戶，在web瀏覽器上給出內容提供商網(wǎng)站的URL連接到CDN。CDN提供的服務和功能內容存儲和管理在代理服務器間分發(fā)內容緩存管理靜態(tài)、動態(tài)和流內容投送備份和災難恢復解決方案監(jiān)視、測量和報告性能內容簡介從以下三個方面介紹CDN：CDN組成內容分發(fā)和管理請求路求參考文獻：

ATaxonomyandSurveyofContentDeliveryNetworks.Http:///reports/CDN-Taxonomy.pdf

3.1CDN的組成CDN的任務是結合網(wǎng)絡條件和緩存服務器負載等動態(tài)信息，在多個反向代理（surrogate）之間重定向請求和平衡負載。在一個CDN中，通常使用一組反向代理來建立內容分發(fā)設施，使用一些機制將用戶請求重定向到一個反向代理，各單元之間使用特定的協(xié)議進行通信。Surrogate和ProxyProxy用于代理內部網(wǎng)絡對因特網(wǎng)的連接請求?？蛻魴C將本來要直接發(fā)送到外部服務器上的服務請求發(fā)送到代理服務器，由代理服務器中繼服務請求。Surrogate用于代理外部網(wǎng)絡上的主機訪問內部網(wǎng)絡，此時Surrogate對外表現(xiàn)為一個web服務器。反向代理可以增強web服務器的安全性，和作為后端服務器集群的負載均衡器。反向代理方式和普通代理方式?jīng)]有沖突，可以在防火墻設備中同時使用。

CDN的結構特性3.1.1CDN的組織方式網(wǎng)絡方法：在路由器和交換機等網(wǎng)絡組件上安裝相關軟件，將內容請求重定向到本地緩存或特定的內容服務器。覆蓋方法：使用放置于網(wǎng)絡中多個地方的應用特定服務器（反向代理，高速緩存服務器）處理特殊內容（web內容、流媒體等）的分發(fā)。除了提供基本的網(wǎng)絡連接和QoS保證外，核心網(wǎng)絡組件在內容分發(fā)過程中不發(fā)揮積極作用。3.1.2CDN服務器源服務器（originserver）：存放資源的權威版本，由內容提供商更新。復制服務器（replicaserver）：存放資源的拷貝，并被授權響應用戶的請求。通過源服務器進行內容更新。CDN的復制服務器CDN的復制服務器可以作為媒體服務器、web服務器或高速緩存服務器：媒體服務器（mediaserver）：提供數(shù)字編碼的內容，安裝有媒體服務器軟件，用音頻或視頻素材響應用戶的請求。Web服務器：包含到流媒體的鏈接，以及CDN希望提供的其它基于web的內容。高速緩存服務器（cacheserver）：在網(wǎng)絡邊緣復制內容，以減少對源服務器的訪問。流媒體應用的實現(xiàn)音/視頻文件存儲在媒體服務器上，元文件存儲在Web服務器上。媒體播放器和媒體服務器之間通過RTP/UDP傳輸音/視頻流，使用RTSP進行交互性操作。3.1.3CDN組件之間的關系CDN的各個組件通過相互協(xié)作來實現(xiàn)CDN內部的內容復制和高速緩存：復制：在不同的計算機系統(tǒng)上創(chuàng)建和維護內容拷貝，典型地是將內容從源服務器“推送”到復制服務器。（Push）緩存（caching）：將可緩存的響應保存在本地，以便將來響應相同的請求。（Pull）用戶-反向代理-源服務器內容投遞的基本關系是在用戶、反向代理服務器和源服務器之間：用戶一般同反向代理服務器通信。反向代理服務器用本地緩存的內容響應用戶請求，或作為源服務器的網(wǎng)關。用戶-網(wǎng)元-高速緩存代理（cachingproxy）在網(wǎng)絡方法中，網(wǎng)元（路由器、交換機）上的控制邏輯將用戶請求轉發(fā)到相應的高速緩存代理（代理陣列）。高速緩存代理-高速緩存代理根據(jù)高速緩存代理之間的通信方式，高速緩存代理可以組織成代理陣列或代理網(wǎng)：Proxyarray：緊耦合結構，有一個權威代理作為主代理，與其它代理通信。Proxymesh：松耦合結構，每個代理都和其它代理有聯(lián)系，構成代理網(wǎng)。Proxymesh需要一個高速緩存服務器作為網(wǎng)關，轉發(fā)來自用戶本地緩存代理的請求。代理陣列和代理網(wǎng)3.1.4協(xié)議CDN中的通信協(xié)議分為兩類：網(wǎng)元交互協(xié)議：用于將用戶請求重定向到一個合適的服務器，涉及路由器、內容交換機/負載均衡器、服務器等實體。高速緩存交互協(xié)議：用于在分布式高速緩存中確定所請求的內容在哪個高速緩存中。網(wǎng)元-服務器（NECP）運行在服務器（源服務器、攔截代理）與其前端設備（內容交換機、負責均衡路由器）之間的控制協(xié)議：服務器啟動時，與網(wǎng)元的熟知端口建立TCP連接，在TCP連接上進行雙向消息交換。網(wǎng)元通過消息交換了解服務器的能力、可用性、可以獲得哪些內容等，作為重定向用戶請求的依據(jù)。重定向路由器-攔截代理（WCCP）運行在重定向路由器和攔截代理之間，建立和維護用戶請求的透明重定向：若干攔截代理和若干重定向路由器組成一個服務組，指定一個代理（IP地址最?。┳鳛槭最I，負責在代理群之間分配負載，并將負載分配方法在組內傳播。通過該協(xié)議，路由器知道如何重定向用戶請求；攔截代理知道如何管理高速緩存中的內容。防火墻安全會話轉換協(xié)議SOCKSSOCKS是為客戶-服務器應用安全通過防火墻而提供的一個通用框架。當內網(wǎng)用戶想訪問外網(wǎng)服務器時，首先與SOCKS代理服務器建立連接，進行認證。若認證通過，SOCKS代理服務器與外網(wǎng)服務器建立連接，并中繼用戶請求；否則終止與用戶的連接。SOCKS代理服務器只是簡單地傳遞包，而不關心是何種應用協(xié)議，因此SOCKS是一種通用的服務，在概念上位于應用層和傳輸層之間。InternetCacheProtocol（ICP）Cache被組織成層次結構：用戶請求發(fā)送到本地緩存。若本地緩存沒有，本地緩存向同伴緩存廣播請求。若同伴均回復沒有或超時，本地緩存向父緩存請求。若父緩存沒有，父緩存或本地緩存向源服務器請求。ICP基于查詢/應答實現(xiàn)，通信開銷大，延遲大。CacheDigest每個節(jié)點保存其它節(jié)點中所緩存的內容的摘要：本地緩存收到用戶請求后，檢查本地緩存的內容和其它節(jié)點的緩存內容摘要；若本地緩存有內容，直接響應用戶的請求；若有緩存內容摘要，向相應的緩存節(jié)點請求；若沒有緩存內容摘要，向源服務器請求內容。優(yōu)點：不需要發(fā)送查詢消息到其它緩存節(jié)點。缺點：存儲摘要的代價很高，節(jié)點之間需要更新摘要。

Cachearrayroutingprotocol（CARP）瀏覽器利用cache陣列成員表、一個查找函數(shù)和用戶請求的URL，就能確定最合適的cache服務器。Cache陣列成員表定義在一個可公開獲取的文本文件中，文件中列出了每臺代理服務器的名字、IP地址和負載因子（管理員指定）。瀏覽器需要下載Cache陣列成員表和一個查找函數(shù)（JavaScript函數(shù)）。CARP（續(xù)）查找函數(shù)實現(xiàn)CARP算法：使用指定的哈希函數(shù)計算URL的散列值及每個成員名字的散列值，兩個值結合得到每個成員對該URL的一個分值。將該分值與成員的負載因子結合，得到每個成員對該URL的總分。總分最高的cache服務器選中。

優(yōu)點：沒有緩存冗余，緩存命中率高。緩存節(jié)點間不需要通信，沒有查詢和更新開銷。3.1.5內容/服務類型CDN提供的內容/服務有三類：靜態(tài)內容，流媒體，各種內容服務。靜態(tài)內容：HTML頁、圖片、文檔、軟件補丁、音/視頻文件等。更新頻率很低，易于緩存。所有CDN提供商都支持靜態(tài)內容的投遞。流媒體流媒體包括：現(xiàn)場音/視頻：內容從編碼器立即送到媒體服務器，然后送給媒體用戶。點播音/視頻：內容預先被編碼，作為流媒體文件保存在媒體服務器中，用戶請求時投送。流媒體服務需要專門的流式服務器，使用特定軟件實現(xiàn)流媒體在IP網(wǎng)絡中的傳輸。投送流媒體內容對于CDN是一個挑戰(zhàn)。內容服務將CDN作為服務分發(fā)渠道，允許增值服務提供商在上面提供增值服務（內容服務），如：目錄服務：將用戶的查詢請求定向到包含請求內容的數(shù)據(jù)庫服務器，并將頻繁請求的查詢結果緩存在CDN的邊緣服務器上。網(wǎng)頁壓縮服務：提供對網(wǎng)頁的實時壓縮，并對源服務器和用戶透明。電子商務服務：比如在CDN的邊緣服務器上保存和維護購物車、進行在線交易等，減輕源站的壓力。3.2內容分發(fā)和管理內容分發(fā)：反向代理放置：確定反向代理服務器的放置位置及數(shù)量，最小化用戶訪問延遲和網(wǎng)絡帶寬消耗。內容選擇和投送：正確選擇要復制到CDN的內容，減少用戶下載時間和服務器負載。內容外包：如何將選擇的內容復制到放置好的反向代理服務器？復制到哪一個反向代理服務器？內容管理：高速緩存組織：緩存技術、緩存更新、緩存策略。3.2.1反向代理服務器的放置目標：確定反向代理服務器的個數(shù)和放置位置。問題模型：給定一個圖G（V,E）和要放置的中心數(shù)量k，確定中心的位置，使得所有節(jié)點到最近中心的最大距離最小化。理論算法：計算復雜度大。啟發(fā)式算法：利用來自CDN的一些信息，如負載模式、網(wǎng)絡拓撲等，以較低的計算代價獲得次優(yōu)解。啟發(fā)式算法（1）Greedyreplicaplacement：前提：知道網(wǎng)絡中所有用戶的位置，以及每一對節(jié)點間的距離。算法思想：從N個可能的站點中選擇訪問代價最小的M個站點放置反向代理。過程：第一輪計算每個站點的代價，計算時假定所有用戶的訪問都匯聚到該站點，代價最小的站點被選中。結合已選中的站點，第二輪搜索代價第二小的站點。依次類推，直至M個站點選出來。啟發(fā)式算法（2）Topology-informedplacementstrategy：假設：有較大出度的節(jié)點可用較小的延遲到達更多的節(jié)點。算法基本思想：使用自治域一級的拓撲，每個節(jié)點代表一個AS，每一條鏈路對應一對BGP對等體。按節(jié)點出度的降序選擇M個節(jié)點放置反向代理。改進的算法：用路由器一級的拓撲代替AS一級的拓撲，與路由器相連的每個局域網(wǎng)都可以放置一個反向代理。啟發(fā)式算法（3）Hotspot算法：按照產(chǎn)生流量的大小對站點進行排序；將M個反向代理放置在生成流量最大的M個站點上。確定反向代理服務器的數(shù)量單ISP方法：僅在CDN提供商的網(wǎng)絡邊緣放置反向代理服務器。放置策略：在ISP覆蓋的區(qū)域內，每個大城市放置一個或兩個反向代理服務器。缺點：反向代理服務器可能離用戶很遠。多ISP方法：在盡可能多的互聯(lián)網(wǎng)入網(wǎng)點（ISPPointsofPresence）上放置反向代理服務器。優(yōu)點：反向代理服務器位于請求用戶的ISP上。缺點：建設成本及復雜性高，服務器使用率低。

3.2.2內容選擇和投送正確選擇要復制到CDN的內容，以減少用戶下載時間和服務器負載。兩類方法：全站點內容選擇和投送：將源服務器上的全部對象外包給反向代理服務器。部分站點內容選擇和投送：只將源服務器上的部分內容復制到反向代理服務器。全站點內容選擇和投送內容提供商配置其DNS，令所有對其web站點的請求都由一個CDN服務器解析，這樣全部內容都由CDN投送。優(yōu)點：簡單。缺點：不具有可行性（邊緣服務器不可能擁有足夠的存儲空間，更新也很難做到）。部分站點內容選擇和投送反向代理服務器只投送內置于網(wǎng)頁的對象（如圖片）。內容提供商修改其內容，將特定對象URL中的hostname改為CDN提供商權威域中的域名。HTML基礎網(wǎng)頁從源服務器獲取，內嵌的對象從CDN反向代理服務器獲取。優(yōu)點：降低了對反向代理服務器的存儲容量需求；只投送靜態(tài)的或更新較慢的內容，減輕更新壓力。部分站點方法（1）基于實證的（empirical-based）方法：管理員依據(jù)經(jīng)驗選擇復制到反向代理服務器的內容。缺點：選擇正確經(jīng)驗的不確定性?；诹餍械模╬opularity-based）方法：最流行的對象被復制到反向代理服務器。缺點：耗時（要對對象的流行程度進行評估和排序）難以得到可靠的對象請求統(tǒng)計信息（流行性變化大）新內容的統(tǒng)計信息得不到部分站點方法（2）基于對象的（object-based）方法：內容以對象為單位復制到反向代理服務器。在滿足存儲容量的前提下，每復制一個對象到反向代理服務器都試圖最大化性能增益（貪婪算法）。優(yōu)點：可獲得最佳性能缺點：實現(xiàn)復雜度高部分站點方法（3）基于聚類的（cluster-based）方法：web內容依據(jù)相關性或訪問頻度分組，并以內容聚類為單位進行復制?；谟脩魰挼膬热菥垲悾豪脀eb日志文件，確定具有關聯(lián)內容的網(wǎng)頁組?；赨RL的內容聚類：依據(jù)web站點的拓撲來匯聚web內容，從一個web站點中識別出最流行的對象，然后按URL之間的相關距離進行聚類。這類方法可以減少用戶下載時間和服務器負載，但實施的復雜度高。3.2.3內容外包（contentoutsourcing）如何將選擇的內容復制到一組放置好的反向代理服務器上？cooperativepush-based（內容預?。簝热輳脑捶掌魍扑偷椒聪虼矸掌?，反向代理服務器通過相互協(xié)作來降低復制和更新代價。CDN維護內容和反向代理之間的映射，用戶請求被定向到最近的反向代理服務器或源服務器。適合采用全局貪婪啟發(fā)式算法在合作的反向代理服務器之間進行復制決策。該方法還處于實驗階段，未被任何CDN提供商使用?；凇袄钡膬热萃獍椒∟on-cooperativepull-based：用戶請求被定向到最近的反向代理服務器；如果緩存不命中，反向代理從源服務器取內容。大多數(shù)流行的CDN提供商使用該方法。Cooperativepull-based：用戶請求被定向到最近的反向代理服務器；如果緩存不命中，反向代理使用一個分布式索引在附近找到所請求內容的拷貝。外包內容的最佳放置問題：外包內容復制到哪一個反向代理服務器最好？各種啟發(fā)式算法（略）：考慮負載均衡和/或下載延遲3.2.4緩存組織（cacheorganization）內容管理主要由CDN的緩存組織方式?jīng)Q定：緩存技術：如何從分布式緩存中找到要請求的內容？緩存更新：如何保證緩存內容的一致性和新鮮性？（1）緩存技術（cachingtechniques）CDN中的內容緩存分為簇內緩存和簇間緩存簇內緩存基于查詢的緩存方案：當一個反向代理服務器發(fā)現(xiàn)cachemiss后，向簇內的其它反向代理服務器廣播一個查詢。若所有的反向代理服務器都沒有該內容，該反向代理向源服務器請求。缺點：查詢流量大（查詢洪泛），延遲長（需要等待所有的反向代理服務器返回響應）。簇內緩存（續(xù)）基于摘要的緩存方案：每個反向代理服務器維護其它服務器中內容的摘要，內容更新的通知發(fā)送給所有的反向代理。反向代理服務器檢查保存于本地的內容摘要后，決定將內容請求路由到哪個反向代理。優(yōu)點：解決了查詢洪泛的問題。缺點：存儲量大，更新流量大（頻繁發(fā)送更新通知）。簇內緩存（續(xù)）基于目錄的緩存方案：摘要方法的集中式版本，一個集中的目錄服務器保存簇內所有反向代理服務器上內容的信息。每個反向代理只將內容改變通知目錄服務器，并在本地cachemiss后查詢目錄服務器。缺點：目錄服務器接收來自所有反向代理的更新和查詢流量，是性能瓶頸和單故障點。簇內緩存（續(xù)）基于哈希的緩存方案：所有反向代理服務器使用相同的哈希函數(shù)和一組反向代理IP地址，根據(jù)內容的URL確定內容存在哪個服務器（稱為內容的指定服務器）上。對內容的請求全都定向到其指定服務器。優(yōu)點：實現(xiàn)代價最?。]有查詢流量，也不需要維護摘要或目錄），內容共享效率最高（沒有緩存冗余）。缺點：對本地請求的擴放性不好（本地用戶的請求會被引導到其它的反向代理服務器）。簇內緩存（續(xù)）基于半哈希的緩存方案：本地反向代理服務器劃出一部分磁盤空間，用于緩存本地用戶經(jīng)常請求的內容，其余空間采用基于哈希的方法與其它服務器協(xié)作。優(yōu)點：實現(xiàn)開銷小，內容共享效率高，本地內容命中率高。簇間緩存基于摘要或目錄的方法：（不可行）擴放性差（每個簇的代表服務器必須維護其它簇的服務器中所存內容的信息）?；诠＃ò牍＃┑姆椒ǎ海ú豢尚校┚植啃圆缓??；诓樵兊姆椒ǎ何ㄒ豢梢詰玫酱亻g緩存的方法。簇內、簇間使用不同的緩存技術簇間使用基于查詢的緩存技術，簇內使用基于哈希的緩存技術：當一個簇不能服務某個內容請求時，其代表服務器向鄰近的簇（代表服務器）發(fā)出詢問。在每個簇內，代表服務器只向內容的指定服務器詢問。（2）緩存更新緩存更新技術用于保證緩存服務器上的內容是最新的。周期性更新：內容提供商配置源web服務器，向緩存服務器提供緩存指示，如內容的可緩存性、過期時間、向源服務器的核對時間等。缺點：每個更新間隔會產(chǎn)生大量不必要的更新流量。緩存更新（續(xù)）更新傳播：每當源服務器上的一個內容發(fā)生了改變，更新的內容就被主動推送到所有的緩存服務器。缺點：內容頻繁更新時產(chǎn)生過多的更新流量。按需更新：僅當內容被請求時，最新的內容拷貝才被投送到發(fā)出請求的緩存服務器。缺點：源服務器和緩存服務器之間來回傳遞消息（如詢問最新的版本），延遲大。緩存更新（續(xù)）無效（invalidation）：當源服務器中的某個文檔發(fā)生改變時，源服務器向所有的代理服務器發(fā)送一個無效消息。需要時，每個代理服務器單獨向源服務器獲取文檔的最新拷貝。優(yōu)點：消除了不必要的內容推送和更新查詢。缺點：沒有充分利用CDN的資源，每個代理服務器需單獨向源服務器獲取文檔的最新拷貝。（3）內部緩存策略使用規(guī)則集定義緩存策略：內容提供商用一個規(guī)則集向CDN提供商描述緩存策略；CDN提供商將規(guī)則集傳播給自己的緩存服務器。使用啟發(fā)式算法：令緩存服務器使用某種啟發(fā)式算法，自動學習源服務器上的內容更新頻率，相應調整它們的行為。3.3請求路由（request-routing）請求路由負責將用戶請求發(fā)送到包含該內容的一個最合適的反向代理服務器上。請求路由系統(tǒng)使用一組度量參數(shù)（如網(wǎng)絡鄰近性、延遲、距離、服務器負載）確定最合適的服務器。內容選擇和投送技術對請求路由系統(tǒng)的設計有直接影響：若使用全站點方法：用戶請求被發(fā)送到代理服務器。若使用部分站點方法：源服務器投送基本內容，代理服務器投送內置的對象。請求路由的示意圖請求路由系統(tǒng)的關鍵技術CDN的請求路由系統(tǒng)包括兩個關鍵的部分：請求路由算法：針對某個內容請求選擇一個反向代理服務器的方法。請求路由機制：將選擇結果通知用戶的方法。3.3.1請求路由算法非自適應算法：使用某種啟發(fā)式來選擇緩存服務器，不考慮當前網(wǎng)絡狀態(tài)，實現(xiàn)簡單。當啟發(fā)式的假設滿足時，算法很有效。自適應算法：在選擇緩存服務器時考慮當前的網(wǎng)絡狀態(tài)（通過估計某些度量參數(shù)獲得），實現(xiàn)復雜。面對瞬間突發(fā)事件時，算法有很好的魯棒性。（1）非自適應算法輪轉：假設所有服務器具有相同的處理能力，且任何服務器可以服務任何請求.內容請求按輪轉順序發(fā)送給各個服務器處理。優(yōu)點：對于放置在一起的服務器機群較有效。缺點：對于廣域分布式系統(tǒng)不適合（沒有考慮距離）未充分實現(xiàn)負載均衡（沒有考慮不同請求的計算開銷有差異）非自適應算法（續(xù)）基于負載分級：假設服務器負載和用戶-服務器間距離是影響請求處理效率的最重要因素。所有服務器按照預估的負載（到目前為止已服務的請求數(shù)）劃分等級。算法首先根據(jù)負載等級選擇侯選服務器，然后在侯選服務器中根據(jù)用戶-服務器距離再選擇服務器。優(yōu)點：既考慮了負載均衡，又考慮了網(wǎng)絡距離。缺點：需要整個網(wǎng)絡的同步，要求較高。非自適應算法（續(xù)）基于服務器的能力：假設：服務器接收用戶請求的比例越高，說明服務器能力越強。用戶請求被路由到能力強的服務器，以充分利用資源?；趯Ψ掌鞯钠茫憾x對不同服務器的偏好，用戶請求被路由到最偏好的服務器。（2）自適應算法基于網(wǎng)絡鄰近性：利用一個周期性更新的路徑長度來估計網(wǎng)絡鄰近性，將用戶請求發(fā)送給最近的服務器。缺點：距離度量的估計過程不太精確?；谟脩?服務器延遲：利用用戶訪問日志或服務器側的延遲測量值，將用戶請求發(fā)送到最近報告了最小延遲的服務器。優(yōu)點：考慮了延遲缺點：需要維護集中的測量數(shù)據(jù)庫，擴放性差。自適應算法（續(xù)）基于多種度量值的加權值：比如，Cisco的DD算法使用AS間距離、AS內距離和端到端延遲三種度量值的加權和。優(yōu)點：靈活性更高。缺點：在每個服務器上需要配置一個測量代理，增加復雜度和處理開銷。3.3.2請求路由機制請求路由機制通知用戶所選擇的代理服務器。（1）全局服務器負載均衡

（GlobalServerLoadBalancing，GSLB）

服務節(jié)點：由一個支持GSLB的web交換機和許多實際的web服務器組成。GSLB交換機具有全局感知能力：每個GSLB交換機知道本地web服務器的健康和性能信息，并與其它GSLB交換機交換信息。GSLB交換機充當某些域的權威DNS服務器：GSLB交換機接收特定域的DNS請求，選擇最好的代理服務器，返回服務器IP地址。GSLB的請求-路由機制用戶鍵入域名解析器