本發(fā)明涉及計(jì)算機(jī)通信領(lǐng)域，尤其涉及虛擬網(wǎng)絡(luò)中的廣播數(shù)據(jù)包通信。

背景技術(shù)：

虛擬交換機(jī)(Open VSwitch，OVS)是一個(gè)虛擬交換軟件，主要在虛擬機(jī)環(huán)境下作為一個(gè)虛擬交換機(jī)使用。OVS支持多個(gè)宿主機(jī)的分布式環(huán)境，OVS可用于傳遞虛擬機(jī)之間的流量，或者用于實(shí)現(xiàn)虛擬機(jī)和外界網(wǎng)絡(luò)的通信。

在基于OVS的虛擬網(wǎng)絡(luò)中，當(dāng)客戶端發(fā)送廣播、組播等多播數(shù)據(jù)包(即廣播流)時(shí)，OVS接收多播數(shù)據(jù)包。由于在大型虛擬網(wǎng)絡(luò)中通常同時(shí)會(huì)有多個(gè)客戶端，為了做到多個(gè)客戶端之間的隔離，OVS需要將多播數(shù)據(jù)包采用隧道(tunnel)的方式轉(zhuǎn)發(fā)到相應(yīng)云資源服務(wù)器的隧道端口。

然而，當(dāng)云資源服務(wù)器首次建立連接時(shí)，需要首先建立隧道，因此會(huì)造成客戶端的多播數(shù)據(jù)包在本地滯留。當(dāng)云資源服務(wù)器數(shù)量大于650臺(tái)以上時(shí)，由于OVS輸出端口存在數(shù)量限制，因此會(huì)導(dǎo)致多播數(shù)據(jù)包發(fā)送失敗。

技術(shù)實(shí)現(xiàn)要素：

基于以上問(wèn)題，本發(fā)明的目的在于提供一種多播數(shù)據(jù)包通信方法、裝置與系統(tǒng)，能夠應(yīng)對(duì)云資源服務(wù)器數(shù)量較多時(shí)的情況，以及能夠快速進(jìn)行多播數(shù)據(jù)包通信。

根據(jù)本發(fā)明的一個(gè)方面，提供一種多播數(shù)據(jù)包通信方法，包括步驟：虛擬交換機(jī)接收來(lái)自客戶端的第一多播數(shù)據(jù)包，基于第一多播數(shù)據(jù)包構(gòu)建單播數(shù)據(jù)包；虛擬交換機(jī)向多播數(shù)據(jù)包通信裝置發(fā)送單播數(shù)據(jù)包；多播數(shù)據(jù)包通信裝置接收單播數(shù)據(jù)包；多播數(shù)據(jù)包通信裝置提取單播數(shù)據(jù)包對(duì)應(yīng)的客戶端特征；多播數(shù)據(jù)包查詢客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器；多播數(shù)據(jù)包通信裝置基于單播數(shù)據(jù)包構(gòu)建第二多播數(shù)據(jù)包；多播數(shù)據(jù)包通信裝置向多個(gè)云資源服務(wù)器發(fā)送第二多播數(shù)據(jù)包。

優(yōu)選地，多播數(shù)據(jù)包通信裝置基于英特爾數(shù)據(jù)面開(kāi)發(fā)套件數(shù)據(jù)處理框架接收單播數(shù)據(jù)包以及發(fā)送第二多播數(shù)據(jù)包。

優(yōu)選地，一個(gè)或多個(gè)多播數(shù)據(jù)包通信裝置通過(guò)一個(gè)虛擬IP地址接收來(lái)自虛擬交換機(jī)的單播數(shù)據(jù)包。

優(yōu)選地，多個(gè)多播數(shù)據(jù)包通信裝置通過(guò)等價(jià)路由分配用于處理單播數(shù)據(jù)包的多播數(shù)據(jù)包通信裝置。

優(yōu)選地，多播數(shù)據(jù)包通信裝置查詢客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器步驟包括：多播數(shù)據(jù)包通信裝置查詢本地?cái)?shù)據(jù)庫(kù)，將客戶端特征與本地?cái)?shù)據(jù)庫(kù)中的數(shù)據(jù)匹配，從而獲得與客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器，其中，本地?cái)?shù)據(jù)庫(kù)定期接收后端數(shù)據(jù)庫(kù)的數(shù)據(jù)。

根據(jù)本發(fā)明的第二個(gè)方面，提供一種多播數(shù)據(jù)包通信裝置，包括接收模塊，接收來(lái)自虛擬交換機(jī)的單播數(shù)據(jù)包，查詢模塊，提取單播數(shù)據(jù)包中的客戶端特征，并查詢客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器，組包模塊，基于單播數(shù)據(jù)包構(gòu)建第二多播數(shù)據(jù)包，發(fā)送模塊，向多個(gè)云資源服務(wù)器發(fā)送第二多播數(shù)據(jù)包。

優(yōu)選地，多播數(shù)據(jù)包通信裝置采用英特爾數(shù)據(jù)面開(kāi)發(fā)套件數(shù)據(jù)處理框架。

優(yōu)選地，第二個(gè)方面的多播數(shù)據(jù)包通信裝置還包括，本地?cái)?shù)據(jù)庫(kù)，本地?cái)?shù)據(jù)庫(kù)存儲(chǔ)客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器信息，查詢模塊將客戶端特征與本地?cái)?shù)據(jù)庫(kù)中的數(shù)據(jù)匹配，從而獲得與客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器，本地?cái)?shù)據(jù)庫(kù)定期接收后端數(shù)據(jù)庫(kù)的數(shù)據(jù)。

根據(jù)本發(fā)明的第三個(gè)方面，提供一種多播數(shù)據(jù)包通信系統(tǒng)還包括一個(gè)或多個(gè)如上述第二個(gè)方面的多播數(shù)據(jù)包通信裝置，多播數(shù)據(jù)包通信系統(tǒng)通過(guò)一個(gè)虛擬IP地址接收來(lái)自虛擬交換機(jī)的單播數(shù)據(jù)包。

優(yōu)選地，第三個(gè)方面的多播數(shù)據(jù)包通信系統(tǒng)還包括等價(jià)路由裝置，等價(jià)路由裝置分配用于處理單播數(shù)據(jù)包的多播數(shù)據(jù)包通信裝置。

本發(fā)明中OVS接收多播數(shù)據(jù)包后發(fā)送單播數(shù)據(jù)包，通過(guò)設(shè)置多播數(shù)據(jù)包通信裝置接收單播數(shù)據(jù)包，由多播數(shù)據(jù)包通信裝置查找相對(duì)應(yīng)的多個(gè)云資源服務(wù)器，并向多個(gè)云資源服務(wù)器發(fā)送多播數(shù)據(jù)包。

由于增加了多播數(shù)據(jù)包通信裝置，OVS不再需要通過(guò)tunnel發(fā)送多播數(shù)據(jù)包，因此避免了多播數(shù)據(jù)包在本地滯留，也不再有云資源服務(wù)器數(shù)量的限制。

附圖說(shuō)明

以下結(jié)合附圖和具體實(shí)施例對(duì)本發(fā)明的技術(shù)方案進(jìn)行詳細(xì)的說(shuō)明，以使本發(fā)明的特性和優(yōu)點(diǎn)更為明顯。

圖1為現(xiàn)有的多播數(shù)據(jù)包通信方法的數(shù)據(jù)流向示意圖；

圖2為本發(fā)明的多播數(shù)據(jù)包通信方法的一個(gè)實(shí)例的數(shù)據(jù)流向示意圖；

圖3為本發(fā)明的多播數(shù)據(jù)包通信方法的流程示意圖；

圖4為本發(fā)明的多播數(shù)據(jù)包通信系統(tǒng)的一個(gè)實(shí)例的模塊示意圖；

圖5為現(xiàn)有技術(shù)的多播數(shù)據(jù)包通信方法與本發(fā)明的一個(gè)實(shí)例的多播數(shù)據(jù)包通信方法的測(cè)試數(shù)據(jù)對(duì)比表。

具體實(shí)施方式

以下將對(duì)本發(fā)明的實(shí)施例給出詳細(xì)的說(shuō)明。盡管本發(fā)明將結(jié)合一些具體實(shí)施方式進(jìn)行闡述和說(shuō)明，但需要注意的是本發(fā)明并不僅僅只局限于這些實(shí)施方式。相反，對(duì)本發(fā)明進(jìn)行的修改或者等同替換，均應(yīng)涵蓋在本發(fā)明的權(quán)利要求范圍當(dāng)中。

一些示例性實(shí)施例被描述成作為流程圖描繪的處理或方法。雖然流程圖將各項(xiàng)操作描述成順序的處理，但是其中的許多操作可以被并行地、并發(fā)地或者同時(shí)實(shí)施。此外，各項(xiàng)操作的順序可以被重新安排。當(dāng)其操作完成時(shí)所述處理可以被終止，但是還可以具有未包括在附圖中的附加步驟。所述處理可以對(duì)應(yīng)于方法、函數(shù)、規(guī)程、子例程、子程序等等。

應(yīng)當(dāng)理解的是，雖然在這里可能使用了術(shù)語(yǔ)“第一”、“第二”等等來(lái)描述各個(gè)單元或是數(shù)據(jù)，但是這些單元或數(shù)據(jù)不應(yīng)當(dāng)受這些術(shù)語(yǔ)限制。使用這些術(shù)語(yǔ)僅僅是為了將一個(gè)數(shù)據(jù)與另一個(gè)數(shù)據(jù)進(jìn)行區(qū)分。舉例來(lái)說(shuō)，在不背離示例性實(shí)施例的范圍的情況下，第一多播數(shù)據(jù)包可以被稱(chēng)為第二多播數(shù)據(jù)包，并且類(lèi)似地第二多播數(shù)據(jù)包可以被稱(chēng)為第一多播數(shù)據(jù)包。

下文描述中的單播流與單播數(shù)據(jù)包具有相同的涵義，即都是指信息的接收和傳遞在節(jié)點(diǎn)間是一對(duì)一進(jìn)行。廣播流與多播數(shù)據(jù)包都是指信息的接收和傳遞在節(jié)點(diǎn)間是一對(duì)多進(jìn)行，需要注意的是，本文中的廣播流或是多播數(shù)據(jù)包既適用于廣播通信方式，也適用于組播通信方式。

圖1為現(xiàn)有的多播數(shù)據(jù)包通信方法的數(shù)據(jù)流向示意圖，下面將通過(guò)圖1介紹現(xiàn)有技術(shù)的多播數(shù)據(jù)包通信方法。

如圖1所示，在云主機(jī)100上運(yùn)行多個(gè)虛擬的客戶端101，多個(gè)客戶端101的結(jié)構(gòu)以及運(yùn)行原理相同。客戶端101向外發(fā)出多播數(shù)據(jù)包，在云主機(jī)100上運(yùn)行的OVS102接收多播數(shù)據(jù)包。OVS102的云主機(jī)100通常使用openflow協(xié)議，OVS102實(shí)現(xiàn)openflow交換機(jī)的功能，云主機(jī)100實(shí)現(xiàn)openflow控制器的功能。云主機(jī)100提取多播數(shù)據(jù)包中的客戶端特征，這里的客戶端特征包括客戶端101的虛擬IP地址、用戶名、用戶IP地址、用戶設(shè)備通信物理地址等中的一個(gè)或多個(gè)。云主機(jī)100根據(jù)提取的客戶端特征在后端數(shù)據(jù)庫(kù)103中查找與客戶端特征匹配的多個(gè)云資源服務(wù)器104，并將多個(gè)云資源服務(wù)器104的到達(dá)路徑通過(guò)openflow協(xié)議與OVS102交互。OVS102構(gòu)建轉(zhuǎn)發(fā)的多播數(shù)據(jù)包，并通過(guò)tunnel的方式將轉(zhuǎn)發(fā)的多播數(shù)據(jù)包發(fā)送到多個(gè)相應(yīng)的云資源服務(wù)器104的隧道端口。各個(gè)云資源服務(wù)104對(duì)多播數(shù)據(jù)包進(jìn)行處理并向OVS102返回單播數(shù)據(jù)包，OVS102將單播數(shù)據(jù)包轉(zhuǎn)發(fā)回客戶端101。

在現(xiàn)有的多播數(shù)據(jù)包通信方法中，OVS102向多個(gè)相應(yīng)的云資源服務(wù)器轉(zhuǎn)發(fā)多播數(shù)據(jù)包，由于多播數(shù)據(jù)包需要通過(guò)tunnel的方式進(jìn)行發(fā)送，因此如果部分云資源服務(wù)器的連接屬于新建，則在發(fā)送多播數(shù)據(jù)包之前需要先建立tunnel，直到所有的tunnel都建立完畢后才能進(jìn)行多播數(shù)據(jù)包轉(zhuǎn)發(fā)。從而會(huì)導(dǎo)致多播數(shù)據(jù)包在云主機(jī)100本地滯留。

由于云主機(jī)100需要在后端數(shù)據(jù)庫(kù)103中查找與客戶端特征匹配的多個(gè)云資源服務(wù)器，當(dāng)云資源服務(wù)器的數(shù)量比較龐大時(shí)，通過(guò)后端數(shù)據(jù)庫(kù)103查找云資源服務(wù)器104的信息就會(huì)變得非常緩慢。

OVS102進(jìn)行多播數(shù)據(jù)包的發(fā)送時(shí)受到輸出端口的限制，當(dāng)數(shù)量超過(guò)650個(gè)時(shí)，導(dǎo)致多播數(shù)據(jù)包發(fā)送失敗。

圖2為本發(fā)明的多播數(shù)據(jù)包通信方法的一個(gè)實(shí)例的數(shù)據(jù)流向示意圖。如圖2所示，本實(shí)施例中加入了多播數(shù)據(jù)包通信系統(tǒng)205。

圖4為本發(fā)明的多播數(shù)據(jù)包通信系統(tǒng)的一個(gè)實(shí)例的模塊示意圖，如圖4所示，多播數(shù)據(jù)包通信系統(tǒng)205包括2個(gè)多播數(shù)據(jù)包通信裝置206以及等價(jià)路由裝置(Equal-CostMultipathRouting，ECMP)207。需要注意的是，多播數(shù)據(jù)包通信系統(tǒng)205中可以包括2個(gè)以上的多播數(shù)據(jù)包通信裝置206，也可以僅設(shè)置1個(gè)多播數(shù)據(jù)包通信裝置206。在多播數(shù)據(jù)包通信系統(tǒng)205中包括多個(gè)多播數(shù)據(jù)包通信裝置206時(shí)，在多播數(shù)據(jù)包通信系統(tǒng)205通過(guò)一個(gè)虛擬IP地址接收數(shù)據(jù)包，即多個(gè)多播數(shù)據(jù)包通信裝置206共享一個(gè)虛擬IP地址，進(jìn)一步地，多播數(shù)據(jù)包通信系統(tǒng)205中設(shè)置等價(jià)路由裝置207用于分配處理數(shù)據(jù)包的多播數(shù)據(jù)包通信裝置206。等價(jià)路由是指路由表中有多條路由能夠到達(dá)同一目的地，且這些條目的優(yōu)先級(jí)、跳數(shù)和開(kāi)銷(xiāo)都相等，那么路由器就會(huì)把這些路由表?xiàng)l目看作是等價(jià)路由，會(huì)輪流使用這些路由表進(jìn)行發(fā)送，從而實(shí)現(xiàn)負(fù)載分擔(dān)的效果。在本示例中，通過(guò)等價(jià)路由裝置206，2個(gè)多播數(shù)據(jù)包通信裝置206等價(jià)地輪流接收數(shù)據(jù)包并進(jìn)行處理，等價(jià)路由裝置206可以使用現(xiàn)有的等價(jià)路由技術(shù)，例如通過(guò)添加靜態(tài)路由實(shí)現(xiàn)。在其他實(shí)施例中也可以通過(guò)其他方式進(jìn)行負(fù)載均衡配置，從而分配處理數(shù)據(jù)包的多播數(shù)據(jù)包通信裝置206。在僅設(shè)置1個(gè)多播數(shù)據(jù)包通信裝置206時(shí)，可以不設(shè)置等價(jià)路由裝置207。

通過(guò)設(shè)置多個(gè)多播數(shù)據(jù)包通信裝置206，增強(qiáng)了對(duì)數(shù)據(jù)包的處理能力，加快了處理速度。

圖3為本發(fā)明的多播數(shù)據(jù)包通信方法的流程示意圖。如圖3所示，本發(fā)明的多播數(shù)據(jù)包通信方法主要實(shí)施以下步驟：

S101：OVS202接收來(lái)自客戶端201的第一多播數(shù)據(jù)包，基于第一多播數(shù)據(jù)包構(gòu)建單播數(shù)據(jù)包；

S102：OVS202向多播數(shù)據(jù)包通信裝置206發(fā)送單播數(shù)據(jù)包；

S103：多播數(shù)據(jù)包通信裝置206接收單播數(shù)據(jù)包；

S104：多播數(shù)據(jù)包通信裝置206提取單播數(shù)據(jù)包對(duì)應(yīng)的客戶端特征；

S105：多播數(shù)據(jù)包通信裝置206查詢客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器204；

S106：多播數(shù)據(jù)包通信裝置206基于單播數(shù)據(jù)包構(gòu)建第二多播數(shù)據(jù)包；

S107：多播數(shù)據(jù)包通信裝置206向多個(gè)云資源服務(wù)器204發(fā)送第二多播數(shù)據(jù)包。

與現(xiàn)有的多播數(shù)據(jù)包通信方法相同，本實(shí)施例中的多個(gè)客戶端201同樣以虛擬機(jī)的形式運(yùn)行在云主機(jī)200上，多個(gè)客戶端201的結(jié)構(gòu)以及運(yùn)行原理相同?？蛻舳?01向外發(fā)出第一多播數(shù)據(jù)包，在云主機(jī)200上運(yùn)行的OVS202接收第一多播數(shù)據(jù)包。云主機(jī)200同樣可以使用openflow協(xié)議，OVS202實(shí)現(xiàn)openflow交換機(jī)的功能，云主機(jī)200實(shí)現(xiàn)openflow控制器的功能。在如步驟S101，OVS202接收來(lái)自客戶端201的第一多播數(shù)據(jù)包后，構(gòu)建單播數(shù)據(jù)包；然后，如步驟S102，OVS202向多播數(shù)據(jù)包通信裝置206發(fā)送單播數(shù)據(jù)包。在本發(fā)明中，OVS202以及云主機(jī)200不再需要對(duì)客戶端201發(fā)出的第一多播數(shù)據(jù)包進(jìn)行直接處理，而是基于該客戶端201發(fā)出的第一多播數(shù)據(jù)包，構(gòu)建單播數(shù)據(jù)包，向多播數(shù)據(jù)包通信系統(tǒng)205轉(zhuǎn)發(fā)該單播數(shù)據(jù)包。該單播數(shù)據(jù)包在本實(shí)施例中通過(guò)通用路由封裝(Generic Routing Encapsulation，GRE)進(jìn)行封裝發(fā)送。

如步驟S103，多播數(shù)據(jù)包通信裝置206接收單播數(shù)據(jù)包。根據(jù)上文中對(duì)多播數(shù)據(jù)包通信系統(tǒng)205的介紹，本實(shí)施例中多播數(shù)據(jù)包通信系統(tǒng)205包括2個(gè)多播數(shù)據(jù)包通信裝置206。通過(guò)公用的虛擬IP地址，等價(jià)路由裝置207接收該單播數(shù)據(jù)包并分配用于處理該單播數(shù)據(jù)包的多播數(shù)據(jù)包通信裝置206，該多播數(shù)據(jù)包通信裝置206接收單播數(shù)據(jù)包。

接著如步驟S104至步驟S107，多播數(shù)據(jù)包通信裝置206處理該單播數(shù)據(jù)包。下面對(duì)多播數(shù)據(jù)包通信裝置206進(jìn)行介紹。

如圖4所示，多播數(shù)據(jù)包通信裝置206包括接收模塊301、查詢模塊302、組包模塊303、發(fā)送模塊304以及本地?cái)?shù)據(jù)庫(kù)305。接收模塊301用于接收來(lái)自O(shè)VS202的單播數(shù)據(jù)包。查詢模塊302用于提取單播數(shù)據(jù)包中的客戶端特征，并查詢客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器204。組包模塊303基于單播數(shù)據(jù)包構(gòu)建第二多播數(shù)據(jù)包。發(fā)送模塊304向多個(gè)相應(yīng)的云資源服務(wù)器204發(fā)送第二多播數(shù)據(jù)包。本地?cái)?shù)據(jù)庫(kù)305用于存儲(chǔ)客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器信息。在本實(shí)施例中，本地?cái)?shù)據(jù)庫(kù)305定期接收后端數(shù)據(jù)庫(kù)203的數(shù)據(jù)，通過(guò)后端數(shù)據(jù)庫(kù)203定期向本地?cái)?shù)據(jù)庫(kù)305推送云資源服務(wù)器信息，使得多播數(shù)據(jù)包通信裝置206對(duì)云資源服務(wù)器204的查詢可以在本地實(shí)施，從而較大地提升查詢速度，避免了現(xiàn)有技術(shù)中當(dāng)云資源服務(wù)器的數(shù)量比較龐大時(shí)，通過(guò)后端數(shù)據(jù)庫(kù)103查找云資源服務(wù)器104的信息，查詢速度會(huì)變得非常緩慢的缺陷。

具體而言，如步驟S104，多播數(shù)據(jù)包通信裝置206的查詢模塊302提取單播數(shù)據(jù)包對(duì)應(yīng)的客戶端特征，這里的客戶端特征與現(xiàn)有技術(shù)中的客戶端特征相同，可以是用戶名、用戶IP地址、用戶設(shè)備通信物理地址等中的一個(gè)或多個(gè)，提取方式可以采用現(xiàn)有的提取技術(shù)，例如在之前的步驟S101中由OVS204在構(gòu)建單播數(shù)據(jù)包時(shí)加入客戶端特征，查詢模塊302在該單播數(shù)據(jù)包中提取客戶端特征。

接著如步驟S105，查詢模塊302查詢客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器204。具體地，查詢模塊302查詢本地?cái)?shù)據(jù)庫(kù)305，將客戶端特征與本地?cái)?shù)據(jù)庫(kù)305中的數(shù)據(jù)匹配，從而獲得與客戶端特征所對(duì)應(yīng)的多個(gè)云資源服務(wù)器204，其中，本地?cái)?shù)據(jù)庫(kù)305定期接收后端數(shù)據(jù)庫(kù)203的數(shù)據(jù)。

如步驟S106，組包模塊303基于單播數(shù)據(jù)包構(gòu)建第二多播數(shù)據(jù)包，如步驟S107發(fā)送模塊304向多個(gè)S105步驟中確定的相關(guān)云資源服務(wù)器204發(fā)送第二多播數(shù)據(jù)包。

在本實(shí)例中，多播數(shù)據(jù)包通信裝置206對(duì)于單播數(shù)據(jù)包的接收以及構(gòu)建第二多播數(shù)據(jù)包，向相關(guān)云資源服務(wù)器204發(fā)送第二多播數(shù)據(jù)包均采用英特爾數(shù)據(jù)面開(kāi)發(fā)套件(Intel DataPlaneDevelopmentKit，Intel DPDK)數(shù)據(jù)處理框架。Intel DPDK是Intel公司提出的一種高速網(wǎng)絡(luò)數(shù)據(jù)包的軟件開(kāi)發(fā)套件，Intel DPDK通過(guò)旁路Linux系統(tǒng)網(wǎng)絡(luò)協(xié)議棧，直接對(duì)網(wǎng)卡進(jìn)行讀寫(xiě)，結(jié)合對(duì)多核CPU中不同內(nèi)核的綁定，能夠?qū)崿F(xiàn)1Gbit網(wǎng)絡(luò)小包流量下的線速收發(fā)。在Intel DPDK數(shù)據(jù)處理框架下具體接收數(shù)單播據(jù)包以及發(fā)送第二多播數(shù)據(jù)包的方法，可以采用現(xiàn)有的Intel DPDK數(shù)據(jù)處理方法。

由于本發(fā)明采用Intel DPDK數(shù)據(jù)處理框架接收單播數(shù)據(jù)包以及發(fā)送第二多播數(shù)據(jù)包，而Intel DPDK數(shù)據(jù)處理框架的特點(diǎn)是通過(guò)軟件進(jìn)行組包并直接從硬件端口發(fā)送，因而本發(fā)明在步驟S107中無(wú)需新建tunnel，也沒(méi)有輸出端口的限制，進(jìn)而優(yōu)化了數(shù)據(jù)包處理過(guò)程，從而加快數(shù)據(jù)包處理速率，同時(shí)也克服了現(xiàn)有技術(shù)中通過(guò)OVS102發(fā)送多播數(shù)據(jù)包中端口限制，新建tunnel從而使得多播數(shù)據(jù)包滯留本地的問(wèn)題。

在其他實(shí)施例中，多播數(shù)據(jù)包通信裝置206也可以使用Intel DPDK數(shù)據(jù)處理框架以外的其他數(shù)據(jù)處理框架，只要滿足能夠進(jìn)行大數(shù)量多播數(shù)據(jù)包發(fā)送即可。

云資源服務(wù)器204接收第二多播數(shù)據(jù)包后的處理和現(xiàn)有技術(shù)一致，此處不再贅述。

圖5為現(xiàn)有技術(shù)的多播數(shù)據(jù)包通信方法與本實(shí)施例的多播數(shù)據(jù)包通信方法的測(cè)試數(shù)據(jù)對(duì)比表。如圖5所示，當(dāng)云資源服務(wù)器數(shù)量為100臺(tái)時(shí)，本發(fā)明對(duì)客戶端的多播數(shù)據(jù)包的處理時(shí)間和現(xiàn)有技術(shù)對(duì)客戶端的多播數(shù)據(jù)包的處理時(shí)間相同。但當(dāng)云資源服務(wù)器數(shù)量為600臺(tái)時(shí)，本發(fā)明對(duì)客戶端的多播數(shù)據(jù)包的處理時(shí)間大大短于現(xiàn)有技術(shù)對(duì)客戶端的多播數(shù)據(jù)包的處理時(shí)間。當(dāng)云資源服務(wù)器數(shù)量為700臺(tái)或1000臺(tái)時(shí)，現(xiàn)有技術(shù)對(duì)客戶端的多播數(shù)據(jù)包已經(jīng)無(wú)法處理，而本發(fā)明所提供的方法、裝置以及系統(tǒng)能夠在很短的時(shí)間內(nèi)完成處理。因此，與現(xiàn)有技術(shù)相比，本發(fā)明的方法具有十分顯著的效果。

以上僅是本發(fā)明的具體應(yīng)用范例，對(duì)本發(fā)明的保護(hù)范圍不構(gòu)成任何限制。除上述實(shí)施例外，本發(fā)明還可以有其它實(shí)施方式。凡采用等同替換或等效變換形成的技術(shù)方案，均落在本發(fā)明所要求保護(hù)的范圍之內(nèi)。