基于OpenFlow 的流媒體云服務(wù)遷移方法

戰(zhàn)立松,奚宏生,王子磊

(中國(guó)科學(xué)技術(shù)大學(xué)自動(dòng)化系網(wǎng)絡(luò)傳播系統(tǒng)與控制聯(lián)合實(shí)驗(yàn)室,合肥 230027)

1 概述

近年來(lái),隨著中國(guó)互聯(lián)網(wǎng)產(chǎn)業(yè)走向成熟,以及網(wǎng)絡(luò)視頻與傳統(tǒng)電視媒體的深入合作,網(wǎng)絡(luò)視頻業(yè)務(wù)成為互聯(lián)網(wǎng)產(chǎn)業(yè)中發(fā)展最快的業(yè)務(wù)之一。同時(shí),隨著移動(dòng)終端的普及以及使用環(huán)境的逐步完善,中國(guó)互聯(lián)網(wǎng)已經(jīng)步入移動(dòng)互聯(lián)網(wǎng)時(shí)代。大規(guī)模并發(fā)的用戶接入、多終端接入方式以及高品質(zhì)的服務(wù)要求,成為流媒體服務(wù)面臨的新挑戰(zhàn)。然而,傳統(tǒng)的基于CDN 與P2P 技術(shù)的流媒體服務(wù)難以支持服務(wù)時(shí)用戶終端切換(多屏切換)、移動(dòng)自動(dòng)切換等需求,同時(shí)系統(tǒng)擴(kuò)展能力有限。

云計(jì)算的興起讓人們考慮將流媒體服務(wù)向云形態(tài)轉(zhuǎn)變?；谠朴?jì)算的新型流媒體服務(wù)模式(流媒體云)將龐大的資源和超強(qiáng)的計(jì)算能力包裝成一個(gè)整體并進(jìn)行統(tǒng)一的管理,支持用戶在任意位置、使用各種終端獲取“不知不覺(jué)”的服務(wù),且其規(guī)?？梢詣?dòng)態(tài)伸縮,以滿足應(yīng)用和用戶增長(zhǎng)的需要,能夠解決傳統(tǒng)流媒體服務(wù)遇到的問(wèn)題。因此,多種流媒體云平臺(tái)和框架相繼被提出,文獻(xiàn)[1]從廣播電視的角度提出了如何利用云計(jì)算技術(shù)構(gòu)建了一個(gè)靈活、可靠、節(jié)能、安全的流媒體服務(wù)平臺(tái)；文獻(xiàn)[2]提供了一種支持多終端接入,有服務(wù)質(zhì)量保障的云模式流媒體服務(wù)平臺(tái)；文獻(xiàn)[3]提出一種由多個(gè)媒體邊緣云(子云)構(gòu)成的多媒體云框架,以提供QoS 支持。除基本平臺(tái)外,云形態(tài)下的流媒體服務(wù)也帶來(lái)了許多挑戰(zhàn),如云資源的優(yōu)化調(diào)度、系統(tǒng)的容錯(cuò)能力、有效負(fù)載均衡、服務(wù)終端的移動(dòng)性和實(shí)時(shí)切換、服務(wù)透明性等。特別地,流媒體服務(wù)的在線遷移技術(shù)(簡(jiǎn)稱流媒體遷移)是解決上述問(wèn)題的關(guān)鍵技術(shù)之一。

針對(duì)流媒體的服務(wù)遷移技術(shù),先前研究主要集中在應(yīng)用層的服務(wù)遷移,通過(guò)在應(yīng)用層加入中間件或服務(wù)代理來(lái)實(shí)現(xiàn)遷移,這也是當(dāng)前流媒體服務(wù)系統(tǒng)中普遍采用的技術(shù)[4-5]。但這種方式存在以下問(wèn)題：(1)只適用于局域的集群系統(tǒng)中,不適用于廣域的流媒體云；(2)中間件或代理通常成為系統(tǒng)的性能瓶頸,且可靠性難以保障；(3)流媒體的交互性和長(zhǎng)會(huì)話特性使其難以做到對(duì)用戶透明。

針對(duì)上述流媒體云的服務(wù)遷移挑戰(zhàn),本文借助于軟件定義網(wǎng)絡(luò)中的OpenFlow[6]技術(shù),將遷移功能從應(yīng)用層業(yè)務(wù)剝離,提出一種網(wǎng)絡(luò)層實(shí)現(xiàn)的流媒體服務(wù)遷移方法,以克服用戶透明性、服務(wù)瓶頸等問(wèn)題。另外,在提出的流媒體服務(wù)遷移框架下,通過(guò)預(yù)測(cè)用戶請(qǐng)求分布,提出一種優(yōu)化遷移數(shù)的遷移模型及其策略,從而在增強(qiáng)系統(tǒng)服務(wù)能力的同時(shí)降低遷移代價(jià)。

2 流媒體云及其存在的問(wèn)題

流媒體服務(wù)具有會(huì)話時(shí)間較長(zhǎng)、網(wǎng)絡(luò)QoS 要求高、交互性強(qiáng)等特點(diǎn),移動(dòng)互聯(lián)網(wǎng)對(duì)終端的多樣性和移動(dòng)性支持又提出了較高的要求,針對(duì)這些特點(diǎn)設(shè)計(jì)的流媒體云有其鮮明的特征。如圖1 所示,在網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)上,為了降低時(shí)延,將服務(wù)和處理推到處于云邊緣的各子云,同時(shí)為了避免傳統(tǒng)CDN 中存在的單點(diǎn)失效問(wèn)題,采用分布式方式管理各子云。

圖1 流媒體云的拓?fù)浣Y(jié)構(gòu)

子云是在地理位置上處于同一地區(qū)的服務(wù)器群,面向的是同一個(gè)地區(qū)的采用不同終端接入的用戶,其內(nèi)部也是按照分布式方式來(lái)管理虛擬化的服務(wù)節(jié)點(diǎn)。在功能和服務(wù)上,融合了超大規(guī)模分布式存儲(chǔ)、智能并行分布式計(jì)算、動(dòng)態(tài)實(shí)時(shí)分布式轉(zhuǎn)碼、自動(dòng)適配終端類型和碼流自適應(yīng)調(diào)整等。這樣流媒體云就能以一個(gè)云計(jì)算平臺(tái)整體的形式向處于不同地理位置的多終端用戶提供統(tǒng)一的流媒體服務(wù)。

這種云形態(tài)的流媒體服務(wù)在解決傳統(tǒng)服務(wù)時(shí)存在以下問(wèn)題：

(1) 服務(wù)可靠性問(wèn)題

長(zhǎng)期大量的服務(wù)使單個(gè)節(jié)點(diǎn)的失效概率劇增,節(jié)點(diǎn)失效使流媒體服務(wù)的可靠性得不到保障。當(dāng)發(fā)現(xiàn)其中的某個(gè)節(jié)點(diǎn)失效時(shí),需要將該節(jié)點(diǎn)上正在進(jìn)行的服務(wù)準(zhǔn)確迅速地遷移到其他節(jié)點(diǎn)上,使用戶不需要重新進(jìn)行請(qǐng)求和等待,才符合云計(jì)算對(duì)用戶透明的本質(zhì)。

(2) 服務(wù)移動(dòng)性問(wèn)題

在移動(dòng)互聯(lián)網(wǎng)時(shí)代,用戶終端常常在服務(wù)時(shí)頻繁移動(dòng)導(dǎo)致地理位置不斷變化,為了保證服務(wù)的持續(xù)性和服務(wù)質(zhì)量,需要在不同的子云之間及時(shí)切換服務(wù)節(jié)點(diǎn),這就需要進(jìn)行服務(wù)遷移,同時(shí)為了使服務(wù)的變化對(duì)用戶透明,服務(wù)遷移要有良好的性能。目前移動(dòng)網(wǎng)絡(luò)的遷移技術(shù)大都需要終端參與處理[7],而移動(dòng)終端的處理能力有限。如果能將處理壓力完全轉(zhuǎn)移到服務(wù)端,可以減輕終端的壓力,增強(qiáng)其續(xù)航能力和移動(dòng)性。

(3) 負(fù)載均衡問(wèn)題

在流媒體云中,各虛擬服務(wù)節(jié)點(diǎn)經(jīng)統(tǒng)一的協(xié)作組成一個(gè)服務(wù)能力極強(qiáng)的系統(tǒng),作為一個(gè)整體向用戶提供統(tǒng)一的、透明的服務(wù)。各節(jié)點(diǎn)的負(fù)載分布往往不夠均衡,從而導(dǎo)致整個(gè)系統(tǒng)容量下降。通過(guò)服務(wù)遷移可以調(diào)整系統(tǒng)的負(fù)載分布,使各節(jié)點(diǎn)達(dá)到一定的負(fù)載均衡,從而提高系統(tǒng)的服務(wù)能力[8]。

因此,服務(wù)遷移是解決這些問(wèn)題的關(guān)鍵技術(shù)。以往的遷移技術(shù)主要集中在應(yīng)用層,通過(guò)在加入中間件或服務(wù)代理來(lái)實(shí)現(xiàn),但這種方式存在以下問(wèn)題：(1)只適用于局域的集群系統(tǒng)中,不適用于廣域的流媒體云；(2)中間件或代理往往成為系統(tǒng)的性能瓶頸,且可靠性難以保障；(3)流媒體的交互性和長(zhǎng)會(huì)話特性使其難以做到對(duì)用戶透明。軟件定義網(wǎng)絡(luò)(Software Defined Network,SDN)的出現(xiàn)能夠解決以上問(wèn)題。下文介紹如何采用SDN 中的OpenFlow技術(shù)在網(wǎng)絡(luò)層實(shí)現(xiàn)服務(wù)遷移。

3 基于OpenFlow 的流媒體遷移技術(shù)

3.1 OpenFlow 架構(gòu)及其關(guān)鍵組件介紹

OpenFlow 主要由OpenFlow 交換機(jī)和控制器兩部分組成,實(shí)現(xiàn)了數(shù)據(jù)層和控制層的分離,其具體架構(gòu)如圖2 所示[9]。OpenFlow 交換機(jī)是數(shù)據(jù)層,負(fù)責(zé)根據(jù)流表轉(zhuǎn)發(fā)數(shù)據(jù)包；控制器是控制平面,通過(guò)全網(wǎng)視圖來(lái)實(shí)現(xiàn)對(duì)數(shù)據(jù)轉(zhuǎn)發(fā)的控制。

圖2 OpenFlow 架構(gòu)

OpenFlow 交換機(jī)主要由流表、安全信道和OpenFlow 協(xié)議三部分組成。流表是OpenFlow 交換機(jī)進(jìn)行轉(zhuǎn)發(fā)策略控制的核心數(shù)據(jù)結(jié)構(gòu),每個(gè)流表由許多流表項(xiàng)組成,流表項(xiàng)代表轉(zhuǎn)發(fā)規(guī)則,交換機(jī)通過(guò)查找匹配的流表項(xiàng)來(lái)決策對(duì)進(jìn)入交換機(jī)的數(shù)據(jù)包執(zhí)行的操作。流表項(xiàng)主要由匹配字段(Header fields)、計(jì)數(shù)器(Counters)和操作(Action)等三部分組成,如圖3 所示。

圖3 OpenFlow 交換機(jī)流表結(jié)構(gòu)

匹配字段包含很多匹配項(xiàng),涵蓋了鏈路層、網(wǎng)絡(luò)層和傳輸層大部分關(guān)鍵標(biāo)識(shí)。計(jì)數(shù)器用來(lái)對(duì)數(shù)據(jù)流的基本數(shù)據(jù)進(jìn)行統(tǒng)計(jì),操作則表明了對(duì)與該流表項(xiàng)匹配的數(shù)據(jù)包應(yīng)該執(zhí)行的下一步操作。安全通道用來(lái)連接OpenFlow 交換機(jī)和控制器,可以用SSL 進(jìn)行加密,控制器按照OpenFlow 協(xié)議的規(guī)定配置和管理OpenFlow 交換機(jī)。

控制器通過(guò) OpenFlow 協(xié)議標(biāo)準(zhǔn)接口對(duì)OpenFlow 交換機(jī)中的流表進(jìn)行控制,從而實(shí)現(xiàn)對(duì)整個(gè)網(wǎng)絡(luò)的集中控制。控制器通過(guò)維護(hù)網(wǎng)絡(luò)視圖來(lái)獲取整個(gè)網(wǎng)絡(luò)的基本信息,如拓?fù)?、網(wǎng)絡(luò)單元和提供的服務(wù)[10]。運(yùn)行在控制器之上的應(yīng)用程序通過(guò)調(diào)用網(wǎng)絡(luò)視圖中的全局?jǐn)?shù)據(jù),進(jìn)而操作OpenFlow 交換機(jī)來(lái)對(duì)整個(gè)網(wǎng)絡(luò)進(jìn)行管理和控制。

3.2 基于OpenFlow 的服務(wù)遷移實(shí)現(xiàn)

以僅有一個(gè)OpenFlow 交換機(jī)的網(wǎng)絡(luò)為例,簡(jiǎn)單說(shuō)明在流媒體云中如何基于OpenFlow 實(shí)現(xiàn)服務(wù)遷移。假設(shè)將一個(gè)正在服務(wù)的流(A 到C)從源服務(wù)節(jié)點(diǎn)A 遷移到目標(biāo)服務(wù)節(jié)點(diǎn)B,遷移流程如圖4 所示：

(1) 查詢?cè)垂?jié)點(diǎn)A 得到當(dāng)前播放偏移；

(2) 停止源節(jié)點(diǎn)A 的服務(wù)；

(3) 向OpenFlow 交換機(jī)下發(fā)流表項(xiàng),將由B 發(fā)往C 的相關(guān)數(shù)據(jù)包的源地址和端口改為A 的地址和端口后,從交換機(jī)的端口3 發(fā)出；

(4) 向目標(biāo)節(jié)點(diǎn)B 請(qǐng)求相應(yīng)播放偏移之后的數(shù)據(jù)；

(5) 目標(biāo)節(jié)點(diǎn)發(fā)出播放偏移之后的數(shù)據(jù)；

(6) 數(shù)據(jù)流經(jīng)OpenFlow 交換機(jī)后匹配流表(Header Fields),執(zhí)行一系列操作(Action)后,最終到達(dá)客戶端C。

圖4 基于OpenFlow 的遷移流程

在客戶端“完全不知情”的情況下,為其服務(wù)的節(jié)點(diǎn)已經(jīng)改變。由于客戶端有緩存的存在,且云的超強(qiáng)計(jì)算能力使整個(gè)調(diào)度過(guò)程耗時(shí)極短,因此可以做到不影響客戶端正常播放影片,即無(wú)縫遷移。由于OpenFlow 控制器擁有網(wǎng)絡(luò)視圖,當(dāng)A,B,C 之間存在多個(gè)交換機(jī)、多條路徑時(shí),控制器會(huì)根據(jù)網(wǎng)絡(luò)視圖中的全局?jǐn)?shù)據(jù)自動(dòng)選擇一條最短路徑,向此最短路徑上的每個(gè)OpenFlow 交換機(jī)下發(fā)流表,下發(fā)流程與上述流程相似,達(dá)到修改媒體流走向的目的,進(jìn)而實(shí)現(xiàn)網(wǎng)絡(luò)層服務(wù)遷移。

由于流媒體云對(duì)各虛擬節(jié)點(diǎn)采用二級(jí)分布式智能管理方式,各個(gè)節(jié)點(diǎn)實(shí)際上成為了云中的對(duì)等節(jié)點(diǎn)。雖然不同的流媒體服務(wù)有不同的特征,如協(xié)議、碼率等,但是在網(wǎng)絡(luò)層中都解析為通過(guò)OpenFlow 交換機(jī)進(jìn)行統(tǒng)一控制的數(shù)據(jù)包。而在OpenFlow 網(wǎng)絡(luò)中,控制器通過(guò)網(wǎng)絡(luò)視圖中的全局?jǐn)?shù)據(jù)將網(wǎng)絡(luò)中的各OpenFlow 交換機(jī)統(tǒng)一管理和控制,使得整個(gè)網(wǎng)絡(luò)實(shí)際上成為一個(gè)“大”的可控網(wǎng)絡(luò)節(jié)點(diǎn)。所以,可以將基于OpenFlow 的流媒體云服務(wù)遷移問(wèn)題抽象成如圖5 所示的模型。

圖5 基于OpenFlow 的流媒體云服務(wù)遷移抽象模型

3.3 基于OpenFlow 的預(yù)測(cè)遷移策略

如本文第2 節(jié)所述,通過(guò)服務(wù)遷移可以調(diào)整系統(tǒng)的負(fù)載分布,使各節(jié)點(diǎn)達(dá)到一定的負(fù)載均衡,從而提高系統(tǒng)的服務(wù)能力。由于服務(wù)遷移所需的系統(tǒng)開(kāi)銷較大,而流媒體服務(wù)對(duì)網(wǎng)絡(luò)QoS 的要求很高,如何優(yōu)化遷移數(shù),在調(diào)整負(fù)載分布的同時(shí)使得遷移的媒體流的數(shù)目最小,是遷移策略要解決的關(guān)鍵問(wèn)題。如文獻(xiàn)[11]中所述,用戶對(duì)不同影片的請(qǐng)求熱度不同是造成負(fù)載不夠均衡的主要原因,所以本文提出通過(guò)預(yù)測(cè)用戶請(qǐng)求分布來(lái)優(yōu)化遷移數(shù)的遷移策略。

根據(jù)圖5 所示的抽象模型可以將流媒體云中基于OpenFlow 的服務(wù)遷移建立數(shù)學(xué)模型來(lái)描述遷移策略。設(shè)已知流媒體云中的節(jié)點(diǎn)集合為N,影片集合為V,每個(gè)節(jié)點(diǎn)的負(fù)載能力(同時(shí)服務(wù)的媒體流的數(shù)目)為cap,用戶請(qǐng)求到達(dá)速率服從參數(shù)為λ的泊松分布[11],用戶請(qǐng)求影片的概率服從Zipf 分布[12]。設(shè)每隔Δt時(shí)間記錄監(jiān)測(cè)到的各個(gè)流的狀態(tài),據(jù)此分析得到此段時(shí)間內(nèi)用戶請(qǐng)求影片的概率分布,結(jié)合用戶請(qǐng)求到達(dá)速率,可以預(yù)測(cè)下一個(gè)Δt時(shí)間內(nèi)用戶對(duì)第i個(gè)影片的請(qǐng)求數(shù)為Ri。設(shè)查詢信息模塊得到的節(jié)點(diǎn)j的當(dāng)前負(fù)載大小為L(zhǎng)j,則節(jié)點(diǎn)j的當(dāng)前空余負(fù)載為cap-Lj。設(shè)下一個(gè)Δt時(shí)間內(nèi)分配給第j個(gè)節(jié)點(diǎn)的對(duì)第i個(gè)影片的請(qǐng)求數(shù)為若不等式式(1)有解,則表明根據(jù)對(duì)上一個(gè)Δt時(shí)間內(nèi)用戶請(qǐng)求特征的分析,當(dāng)前服務(wù)的分布在概率上可以滿足下一個(gè)Δt時(shí)間內(nèi)用戶的請(qǐng)求,即預(yù)測(cè)的結(jié)果不需要進(jìn)行服務(wù)遷移。

如不等式式(1)無(wú)整數(shù)解,則表明當(dāng)前的服務(wù)分布是不合理的,未來(lái)很有可能出現(xiàn)某些節(jié)點(diǎn)過(guò)載的情況,所以預(yù)測(cè)的結(jié)果是需要進(jìn)行服務(wù)遷移,即要調(diào)整當(dāng)前服務(wù)的分布。為使遷移的代價(jià)最小,設(shè)當(dāng)前第j個(gè)節(jié)點(diǎn)上的第i個(gè)影片的服務(wù)數(shù)為調(diào)整服務(wù)分布后第j個(gè)節(jié)點(diǎn)上的第i個(gè)影片的服務(wù)數(shù)為此時(shí)抽象出的整數(shù)規(guī)劃問(wèn)題如下：

若此問(wèn)題有解,則Z即為最少遷移次數(shù),根據(jù)和即可得到相應(yīng)的遷移步驟。

4 遷移策略評(píng)估

為評(píng)估本文提出的遷移策略,進(jìn)行仿真測(cè)試。測(cè)試環(huán)境如下：整個(gè)系統(tǒng)共有20 個(gè)流媒體服務(wù)節(jié)點(diǎn),每個(gè)節(jié)點(diǎn)的負(fù)載能力為100 個(gè)媒體流,每個(gè)節(jié)點(diǎn)上部署了110 個(gè)影片副本,整個(gè)系統(tǒng)共有1 500 個(gè)影片(不包括副本)；取單位時(shí)間為1 min,單位時(shí)間內(nèi)整個(gè)系統(tǒng)接受到的用戶請(qǐng)求數(shù)服從參數(shù)為λ的泊松分布,影片熱度服從參數(shù)為0.6 的Zipf 分布,每次請(qǐng)求的會(huì)話時(shí)長(zhǎng)服從參數(shù)為90 的指數(shù)分布[11],因此當(dāng)λ=20(100/90≈23 時(shí)系統(tǒng)達(dá)到滿載。本文實(shí)驗(yàn)以360 min 內(nèi)用戶請(qǐng)求的接受率和遷移數(shù)為性能指標(biāo),分別對(duì)以下2 種情況進(jìn)行仿真：

(1) 在理想狀況下,影片熱度與影片副本的部署分布相吻合,即熱門影片在系統(tǒng)中部署的副本較多,冷門影片在系統(tǒng)中部署的副本較少。

(2) 在實(shí)際情況下,影片熱度與影片副本的分布部署不吻合,即熱門影片在系統(tǒng)中部署的副本可能較少,冷門影片在系統(tǒng)中部署的副本可能較多。

2 種情況下的仿真結(jié)果分別如圖6、圖7 所示。

圖6 理想狀況下的實(shí)驗(yàn)結(jié)果

圖7 實(shí)際狀況下的實(shí)驗(yàn)結(jié)果

由圖6 可以看出,理想情況下,由于影片副本的部署分布較合理,可以有效發(fā)揮系統(tǒng)的服務(wù)能力,因此在λ=23 時(shí)仍然有99% 的請(qǐng)求接受率。隨著請(qǐng)求到達(dá)速率的上升,請(qǐng)求接受率下降明顯,通過(guò)遷移策略的調(diào)度,各節(jié)點(diǎn)的負(fù)載得到更合理的分配,提升了系統(tǒng)容量,所以,系統(tǒng)的請(qǐng)求接受率有顯著提升,提升的平均幅度約為2% 。

由圖7 可以看出,實(shí)際情況下,由于影片副本的部署分布不是很合理,在λ=23 時(shí)請(qǐng)求接受率只有約96%,明顯低于圖6 中的情況,此時(shí)系統(tǒng)的服務(wù)能力顯然沒(méi)有達(dá)到最大發(fā)揮。通過(guò)遷移策略的調(diào)度,各節(jié)點(diǎn)的負(fù)載得到更合理的分配,一定程度上彌補(bǔ)了影片副本部署分布不合理的問(wèn)題。由于影片副本部署分布的不合理,系統(tǒng)容量的提升空間不大,服務(wù)分布的調(diào)整次數(shù)也較少,因此圖7 中接受率的提升幅度沒(méi)有圖6 中的大,但是仍然有平均幅度約1.5%的提升,而遷移數(shù)也相對(duì)較少。這說(shuō)明實(shí)際情況下,遷移策略仍可以在一定程度上提高系統(tǒng)容量。

5 結(jié)束語(yǔ)

本文基于OpenFlow 技術(shù),提出一種網(wǎng)絡(luò)層的流媒體服務(wù)遷移方法,解決了服務(wù)的可靠性、用戶透明性和服務(wù)瓶頸等問(wèn)題。另外,基于對(duì)用戶請(qǐng)求分布的預(yù)測(cè),提出一種優(yōu)化遷移數(shù)的遷移模型及其策略,在增強(qiáng)了系統(tǒng)接受并發(fā)請(qǐng)求能力的同時(shí)降低了遷移代價(jià)。實(shí)驗(yàn)結(jié)果驗(yàn)證了在2 種不同情況下,該策略均可以用較少的遷移數(shù)明顯提高請(qǐng)求接受率。由于影片副本的部署方式對(duì)系統(tǒng)服務(wù)能力有著重要影響,因此下一步的工作重點(diǎn)是優(yōu)化資源的自適應(yīng)部署。

[1]楊銘民,徐元?jiǎng)P.基于云計(jì)算平臺(tái)的網(wǎng)絡(luò)視頻技術(shù)應(yīng)用研究[J].廣播與電視技術(shù),2012,(11)：30-35.

[2]北京原力創(chuàng)新科技有限公司.云模式流媒體服務(wù)平臺(tái)：中國(guó),200910091537.2[P].2010-01-27.

[3]Zhu Wenwu,Luo Chong,Wang Jianfeng,et al.Multimedia Cloud Computing [ J ].IEEE Signal Processing Magazine,2011,28(3)：59-69.

[4]中國(guó)科學(xué)技術(shù)大學(xué).媒體流在線服務(wù)遷移的方法和裝置：中國(guó),200810104086.7[P].2008-08-27.

[5]周 俊,李文中,陸桑璐,等.利用網(wǎng)格技術(shù)實(shí)現(xiàn)流媒體服務(wù)遷移[J].計(jì)算機(jī)科學(xué),2005,32(8)：109-113.

[6]左青云,陳 鳴,趙廣松,等.基于OpenFlow 的SDN技術(shù)研究[J].軟件學(xué)報(bào),2013,24(5)：1078-1097.

[7]Hu Yuefei,Li Wenzhong,Lu Sanglu,et al.On Media Streaming Application Migration in Pervasive Environment[C]//Proceedings of the 1st Asia-Pacific Symposium on Internetware.New York,USA：ACM Press,2009：206-230.

[8]Zhao Yinqing,Zhi Shi,Kuo C C.Dynamic Load Balancing and Content Update for Media Storage Servers[C]//Proceedings of SPIE’02.Orlando,USA：[s.n.],2002：201-212.

[9]McKeown N,Anderson T,Balakrishnan H,et al.OpenFlow：Enabling Innovation in Campus Networks[J].ACM SIGCOMM Computer Communication Review,2008,38(2)：69-74.

[10]Gude N,Koponen T,Pettit J,et al.Nox：Towards an Operating System for Networks[J].ACM SIGCOMM Computer Communication Review,2008,38(3)：105-110.

[11]Yu Hongliang,Zheng Dongdong.Understanding User Behavior in Large-scale Video-on-Demand Systems[C]//Proceedings of the 1st ACM SIGOPS/EuroSys European Conference on Computer Systems.New York,USA：ACM Press,2006：333-344.

[12]Qiu Tongqing,Ge Zihui,Lee Seung-Joon,et al.Modeling Channel Popularity Dynamics in a Large IPTV System[J].ACM SIGMETRICS Performance Evaluation Review,2009,37(1)：275-286.