一种多播数据包通信方法、装置与系统与流程

本发明涉及计算机通信领域，尤其涉及虚拟网络中的广播数据包通信。

背景技术：

虚拟交换机(Open VSwitch，OVS)是一个虚拟交换软件，主要在虚拟机环境下作为一个虚拟交换机使用。OVS支持多个宿主机的分布式环境，OVS可用于传递虚拟机之间的流量，或者用于实现虚拟机和外界网络的通信。

在基于OVS的虚拟网络中，当客户端发送广播、组播等多播数据包(即广播流)时，OVS接收多播数据包。由于在大型虚拟网络中通常同时会有多个客户端，为了做到多个客户端之间的隔离，OVS需要将多播数据包采用隧道(tunnel)的方式转发到相应云资源服务器的隧道端口。

然而，当云资源服务器首次建立连接时，需要首先建立隧道，因此会造成客户端的多播数据包在本地滞留。当云资源服务器数量大于650台以上时，由于OVS输出端口存在数量限制，因此会导致多播数据包发送失败。

技术实现要素：

基于以上问题，本发明的目的在于提供一种多播数据包通信方法、装置与系统，能够应对云资源服务器数量较多时的情况，以及能够快速进行多播数据包通信。

根据本发明的一个方面，提供一种多播数据包通信方法，包括步骤：虚拟交换机接收来自客户端的第一多播数据包，基于第一多播数据包构建单播数据包；虚拟交换机向多播数据包通信装置发送单播数据包；多播数据包通信装置接收单播数据包；多播数据包通信装置提取单播数据包对应的客户端特征；多播数据包查询客户端特征所对应的多个云资源服务器；多播数据包通信装置基于单播数据包构建第二多播数据包；多播数据包通信装置向多个云资源服务器发送第二多播数据包。

优选地，多播数据包通信装置基于英特尔数据面开发套件数据处理框架接收单播数据包以及发送第二多播数据包。

优选地，一个或多个多播数据包通信装置通过一个虚拟IP地址接收来自虚拟交换机的单播数据包。

优选地，多个多播数据包通信装置通过等价路由分配用于处理单播数据包的多播数据包通信装置。

优选地，多播数据包通信装置查询客户端特征所对应的多个云资源服务器步骤包括：多播数据包通信装置查询本地数据库，将客户端特征与本地数据库中的数据匹配，从而获得与客户端特征所对应的多个云资源服务器，其中，本地数据库定期接收后端数据库的数据。

根据本发明的第二个方面，提供一种多播数据包通信装置，包括接收模块，接收来自虚拟交换机的单播数据包，查询模块，提取单播数据包中的客户端特征，并查询客户端特征所对应的多个云资源服务器，组包模块，基于单播数据包构建第二多播数据包，发送模块，向多个云资源服务器发送第二多播数据包。

优选地，多播数据包通信装置采用英特尔数据面开发套件数据处理框架。

优选地，第二个方面的多播数据包通信装置还包括，本地数据库，本地数据库存储客户端特征所对应的多个云资源服务器信息，查询模块将客户端特征与本地数据库中的数据匹配，从而获得与客户端特征所对应的多个云资源服务器，本地数据库定期接收后端数据库的数据。

根据本发明的第三个方面，提供一种多播数据包通信系统还包括一个或多个如上述第二个方面的多播数据包通信装置，多播数据包通信系统通过一个虚拟IP地址接收来自虚拟交换机的单播数据包。

优选地，第三个方面的多播数据包通信系统还包括等价路由装置，等价路由装置分配用于处理单播数据包的多播数据包通信装置。

本发明中OVS接收多播数据包后发送单播数据包，通过设置多播数据包通信装置接收单播数据包，由多播数据包通信装置查找相对应的多个云资源服务器，并向多个云资源服务器发送多播数据包。

由于增加了多播数据包通信装置，OVS不再需要通过tunnel发送多播数据包，因此避免了多播数据包在本地滞留，也不再有云资源服务器数量的限制。

附图说明

以下结合附图和具体实施例对本发明的技术方案进行详细的说明，以使本发明的特性和优点更为明显。

图1为现有的多播数据包通信方法的数据流向示意图；

图2为本发明的多播数据包通信方法的一个实例的数据流向示意图；

图3为本发明的多播数据包通信方法的流程示意图；

图4为本发明的多播数据包通信系统的一个实例的模块示意图；

图5为现有技术的多播数据包通信方法与本发明的一个实例的多播数据包通信方法的测试数据对比表。

具体实施方式

以下将对本发明的实施例给出详细的说明。尽管本发明将结合一些具体实施方式进行阐述和说明，但需要注意的是本发明并不仅仅只局限于这些实施方式。相反，对本发明进行的修改或者等同替换，均应涵盖在本发明的权利要求范围当中。

一些示例性实施例被描述成作为流程图描绘的处理或方法。虽然流程图将各项操作描述成顺序的处理，但是其中的许多操作可以被并行地、并发地或者同时实施。此外，各项操作的顺序可以被重新安排。当其操作完成时所述处理可以被终止，但是还可以具有未包括在附图中的附加步骤。所述处理可以对应于方法、函数、规程、子例程、子程序等等。

应当理解的是，虽然在这里可能使用了术语“第一”、“第二”等等来描述各个单元或是数据，但是这些单元或数据不应当受这些术语限制。使用这些术语仅仅是为了将一个数据与另一个数据进行区分。举例来说，在不背离示例性实施例的范围的情况下，第一多播数据包可以被称为第二多播数据包，并且类似地第二多播数据包可以被称为第一多播数据包。

下文描述中的单播流与单播数据包具有相同的涵义，即都是指信息的接收和传递在节点间是一对一进行。广播流与多播数据包都是指信息的接收和传递在节点间是一对多进行，需要注意的是，本文中的广播流或是多播数据包既适用于广播通信方式，也适用于组播通信方式。

图1为现有的多播数据包通信方法的数据流向示意图，下面将通过图1介绍现有技术的多播数据包通信方法。

如图1所示，在云主机100上运行多个虚拟的客户端101，多个客户端101的结构以及运行原理相同。客户端101向外发出多播数据包，在云主机100上运行的OVS102接收多播数据包。OVS102的云主机100通常使用openflow协议，OVS102实现openflow交换机的功能，云主机100实现openflow控制器的功能。云主机100提取多播数据包中的客户端特征，这里的客户端特征包括客户端101的虚拟IP地址、用户名、用户IP地址、用户设备通信物理地址等中的一个或多个。云主机100根据提取的客户端特征在后端数据库103中查找与客户端特征匹配的多个云资源服务器104，并将多个云资源服务器104的到达路径通过openflow协议与OVS102交互。OVS102构建转发的多播数据包，并通过tunnel的方式将转发的多播数据包发送到多个相应的云资源服务器104的隧道端口。各个云资源服务104对多播数据包进行处理并向OVS102返回单播数据包，OVS102将单播数据包转发回客户端101。

在现有的多播数据包通信方法中，OVS102向多个相应的云资源服务器转发多播数据包，由于多播数据包需要通过tunnel的方式进行发送，因此如果部分云资源服务器的连接属于新建，则在发送多播数据包之前需要先建立tunnel，直到所有的tunnel都建立完毕后才能进行多播数据包转发。从而会导致多播数据包在云主机100本地滞留。

由于云主机100需要在后端数据库103中查找与客户端特征匹配的多个云资源服务器，当云资源服务器的数量比较庞大时，通过后端数据库103查找云资源服务器104的信息就会变得非常缓慢。

OVS102进行多播数据包的发送时受到输出端口的限制，当数量超过650个时，导致多播数据包发送失败。

图2为本发明的多播数据包通信方法的一个实例的数据流向示意图。如图2所示，本实施例中加入了多播数据包通信系统205。

图4为本发明的多播数据包通信系统的一个实例的模块示意图，如图4所示，多播数据包通信系统205包括2个多播数据包通信装置206以及等价路由装置(Equal-CostMultipathRouting，ECMP)207。需要注意的是，多播数据包通信系统205中可以包括2个以上的多播数据包通信装置206，也可以仅设置1个多播数据包通信装置206。在多播数据包通信系统205中包括多个多播数据包通信装置206时，在多播数据包通信系统205通过一个虚拟IP地址接收数据包，即多个多播数据包通信装置206共享一个虚拟IP地址，进一步地，多播数据包通信系统205中设置等价路由装置207用于分配处理数据包的多播数据包通信装置206。等价路由是指路由表中有多条路由能够到达同一目的地，且这些条目的优先级、跳数和开销都相等，那么路由器就会把这些路由表条目看作是等价路由，会轮流使用这些路由表进行发送，从而实现负载分担的效果。在本示例中，通过等价路由装置206，2个多播数据包通信装置206等价地轮流接收数据包并进行处理，等价路由装置206可以使用现有的等价路由技术，例如通过添加静态路由实现。在其他实施例中也可以通过其他方式进行负载均衡配置，从而分配处理数据包的多播数据包通信装置206。在仅设置1个多播数据包通信装置206时，可以不设置等价路由装置207。

通过设置多个多播数据包通信装置206，增强了对数据包的处理能力，加快了处理速度。

图3为本发明的多播数据包通信方法的流程示意图。如图3所示，本发明的多播数据包通信方法主要实施以下步骤：

S101：OVS202接收来自客户端201的第一多播数据包，基于第一多播数据包构建单播数据包；

S102：OVS202向多播数据包通信装置206发送单播数据包；

S103：多播数据包通信装置206接收单播数据包；

S104：多播数据包通信装置206提取单播数据包对应的客户端特征；

S105：多播数据包通信装置206查询客户端特征所对应的多个云资源服务器204；

S106：多播数据包通信装置206基于单播数据包构建第二多播数据包；

S107：多播数据包通信装置206向多个云资源服务器204发送第二多播数据包。

与现有的多播数据包通信方法相同，本实施例中的多个客户端201同样以虚拟机的形式运行在云主机200上，多个客户端201的结构以及运行原理相同。客户端201向外发出第一多播数据包，在云主机200上运行的OVS202接收第一多播数据包。云主机200同样可以使用openflow协议，OVS202实现openflow交换机的功能，云主机200实现openflow控制器的功能。在如步骤S101，OVS202接收来自客户端201的第一多播数据包后，构建单播数据包；然后，如步骤S102，OVS202向多播数据包通信装置206发送单播数据包。在本发明中，OVS202以及云主机200不再需要对客户端201发出的第一多播数据包进行直接处理，而是基于该客户端201发出的第一多播数据包，构建单播数据包，向多播数据包通信系统205转发该单播数据包。该单播数据包在本实施例中通过通用路由封装(Generic Routing Encapsulation，GRE)进行封装发送。

如步骤S103，多播数据包通信装置206接收单播数据包。根据上文中对多播数据包通信系统205的介绍，本实施例中多播数据包通信系统205包括2个多播数据包通信装置206。通过公用的虚拟IP地址，等价路由装置207接收该单播数据包并分配用于处理该单播数据包的多播数据包通信装置206，该多播数据包通信装置206接收单播数据包。

接着如步骤S104至步骤S107，多播数据包通信装置206处理该单播数据包。下面对多播数据包通信装置206进行介绍。

如图4所示，多播数据包通信装置206包括接收模块301、查询模块302、组包模块303、发送模块304以及本地数据库305。接收模块301用于接收来自OVS202的单播数据包。查询模块302用于提取单播数据包中的客户端特征，并查询客户端特征所对应的多个云资源服务器204。组包模块303基于单播数据包构建第二多播数据包。发送模块304向多个相应的云资源服务器204发送第二多播数据包。本地数据库305用于存储客户端特征所对应的多个云资源服务器信息。在本实施例中，本地数据库305定期接收后端数据库203的数据，通过后端数据库203定期向本地数据库305推送云资源服务器信息，使得多播数据包通信装置206对云资源服务器204的查询可以在本地实施，从而较大地提升查询速度，避免了现有技术中当云资源服务器的数量比较庞大时，通过后端数据库103查找云资源服务器104的信息，查询速度会变得非常缓慢的缺陷。

具体而言，如步骤S104，多播数据包通信装置206的查询模块302提取单播数据包对应的客户端特征，这里的客户端特征与现有技术中的客户端特征相同，可以是用户名、用户IP地址、用户设备通信物理地址等中的一个或多个，提取方式可以采用现有的提取技术，例如在之前的步骤S101中由OVS204在构建单播数据包时加入客户端特征，查询模块302在该单播数据包中提取客户端特征。

接着如步骤S105，查询模块302查询客户端特征所对应的多个云资源服务器204。具体地，查询模块302查询本地数据库305，将客户端特征与本地数据库305中的数据匹配，从而获得与客户端特征所对应的多个云资源服务器204，其中，本地数据库305定期接收后端数据库203的数据。

如步骤S106，组包模块303基于单播数据包构建第二多播数据包，如步骤S107发送模块304向多个S105步骤中确定的相关云资源服务器204发送第二多播数据包。

在本实例中，多播数据包通信装置206对于单播数据包的接收以及构建第二多播数据包，向相关云资源服务器204发送第二多播数据包均采用英特尔数据面开发套件(Intel DataPlaneDevelopmentKit，Intel DPDK)数据处理框架。Intel DPDK是Intel公司提出的一种高速网络数据包的软件开发套件，Intel DPDK通过旁路Linux系统网络协议栈，直接对网卡进行读写，结合对多核CPU中不同内核的绑定，能够实现1Gbit网络小包流量下的线速收发。在Intel DPDK数据处理框架下具体接收数单播据包以及发送第二多播数据包的方法，可以采用现有的Intel DPDK数据处理方法。

由于本发明采用Intel DPDK数据处理框架接收单播数据包以及发送第二多播数据包，而Intel DPDK数据处理框架的特点是通过软件进行组包并直接从硬件端口发送，因而本发明在步骤S107中无需新建tunnel，也没有输出端口的限制，进而优化了数据包处理过程，从而加快数据包处理速率，同时也克服了现有技术中通过OVS102发送多播数据包中端口限制，新建tunnel从而使得多播数据包滞留本地的问题。

在其他实施例中，多播数据包通信装置206也可以使用Intel DPDK数据处理框架以外的其他数据处理框架，只要满足能够进行大数量多播数据包发送即可。

云资源服务器204接收第二多播数据包后的处理和现有技术一致，此处不再赘述。

图5为现有技术的多播数据包通信方法与本实施例的多播数据包通信方法的测试数据对比表。如图5所示，当云资源服务器数量为100台时，本发明对客户端的多播数据包的处理时间和现有技术对客户端的多播数据包的处理时间相同。但当云资源服务器数量为600台时，本发明对客户端的多播数据包的处理时间大大短于现有技术对客户端的多播数据包的处理时间。当云资源服务器数量为700台或1000台时，现有技术对客户端的多播数据包已经无法处理，而本发明所提供的方法、装置以及系统能够在很短的时间内完成处理。因此，与现有技术相比，本发明的方法具有十分显著的效果。

以上仅是本发明的具体应用范例，对本发明的保护范围不构成任何限制。除上述实施例外，本发明还可以有其它实施方式。凡采用等同替换或等效变换形成的技术方案，均落在本发明所要求保护的范围之内。