掌桥专利:专业的专利平台
掌桥专利
首页

一种容器流量采集方法、装置、存储介质及设备

文献发布时间:2023-06-19 18:46:07


一种容器流量采集方法、装置、存储介质及设备

技术领域

本申请涉及容器技术领域,具体而言,涉及一种容器流量采集方法、容器流量采集装置、存储介质以及电子设备。

背景技术

随着容器技术的发展,尤其是随着大规模容器集群管理系统,例如kubernetes(简称K8S)等称为IT基础设施,越来越多的业务系统采用容器化部署。传统的基于网络流量的入侵检测工具无法采集到容器流量,使得容器流量成为检测盲区,威胁业务系统的安全。

相关技术中采集容器流量的方式一般跟容器的部署方式相关,比如,通过Docker部署时,对Docker0虚拟网桥进行采集;通过K8S部署时,利用K8S网络模块创建的虚拟网桥,如Cni0网桥抓包。这样的方式不够通用,很难做成标准化产品,而且无法对单个的容器配置采集规则,不利于产品化。

发明内容

本申请实施例的目的在于提供一种容器流量采集方法、装置、存储介质及设备,旨在解决相关技术中采集容器流量的方案存在的不够通用,无法对单个的容器配置单独的采集规则,难以标准化、产品化的问题。

第一方面,本申请实施例提供的一种容器流量采集方法,应用于部署在Linux主机上的客户端,所述Linux主机上运行有至少一个容器,所述方法包括:

获取服务端下发的采集策略,所述采集策略包括待采集容器以及对应的流量采集规则;

根据所述采集策略,应用对应的流量采集规则对所述待采集容器的veth-pair虚拟网卡进行容器流量采集;

将采集到的容器流量发送至检测系统。

在上述实现过程中,部署在Linux主机上的客户端获取服务端下发的采集策略,并根据该采集策略,在Linux主机上对待采集容器的veth-pair虚拟网卡进行容器流量采集,并将采集到的容器流量上报至检测系统。如此,不仅支持各种容器部署方式,还支持对每一个要采集的容器配置单独的流量采集规则,配置更为灵活丰富,易于标准化和产品化。

进一步地,在一些实施例中,所述采集策略中携带所述待采集容器的容器资产信息,所述容器资产信息包括以下至少一种:

容器ID、容器名称、MAC地址、IP地址、veth-pair虚拟网卡名称。

在上述实现过程中,限定容器资产信息的类型,方便客户端确定要采集的容器。

进一步地,在一些实施例中,所述容器资产信息是所述服务端通过容器部署平台提供的API获取得到;和/或,所述容器资产信息由所述客户端上报至所述服务端。

在上述实现过程中,提供收集容器资产信息的具体方式,以提高收集到的容器资产信息的完整性。

进一步地,在一些实施例中,所述根据所述采集策略,应用对应的流量采集规则对所述待采集容器的veth-pair虚拟网卡进行容器流量采集,包括:

根据所述容器资产信息,确定所述待采集容器的veth-pair虚拟网卡;

应用对应的流量采集规则采集所述veth-pair虚拟网卡的容器流量。

在上述实现过程中,根据采集策略中的容器资产信息确定要采集的容器对应的veth-pair虚拟网卡,以此进行容器流量采集,实现准确按照配置实施采集。

进一步地,在一些实施例中,所述流量采集规则包括以下至少一种:

BPF过滤规则、限速阈值。

在上述实现过程中,通过对BPF过滤规则和/或限速阈值的配置,方便采集技术的产品化。

进一步地,在一些实施例中,所述方法还包括:

统计各容器的容器流量,并将统计结果上报至所述服务端。

在上述实现过程中,提供针对各容器的容器流量的统计功能,客户端将统计结果上报至服务端后,可以给用户配置采集策略提供参考,为调整得到更为合理的采集策略提供数据支持。

进一步地,在一些实施例中,所述流量采集规则基于以下方式进行配置:

若统计得到任一待采集容器的容器流量超过第一预设阈值,针对所述待采集容器配置的BPF过滤规则包括指定IP地址、指定端口、指定协议中的至少一种;

若统计得到任一待采集容器的容器流量不超过第二预设阈值,针对所述待采集容器配置的BPF过滤规则为空。

在上述实现过程中,提供根据统计结果调整流量采集规则的具体方式,满足容器流量检测时数据采集需求和带宽限制的均衡,使得调整后的采集策略更为合理。

进一步地,在一些实施例中,所述服务端提供配置界面,所述配置界面用于供用户配置所述采集策略。

在上述实现过程中,用户可以在服务端上配置采集策略,实现采集策略的个性化配置,满足用户定制化需求。

进一步地,在一些实施例中,所述将采集到的容器流量发送至检测系统,包括:

将采集到的容器流量封装成VXLAN格式或GRE格式后,发送至检测系统。

在上述实现过程中,客户端对采集到的容器流量进行VXLAN/GRE封装,使得封装后的容器流量能够传输至检测系统。

进一步地,在一些实施例中,所述方法还包括:

当获取到服务端下发的新的采集策略时,应用所述新的采集策略中的流量采集规则,对所述新的采集策略中的待采集容器的veth-pair虚拟网卡进行容器流量采集。

在上述实现过程中,当用户配置新的采集策略时,客户端按照新的采集策略进行容器流量采集,方便用户调整采集策略,提升用户的使用体验。

第二方面,本申请实施例提供的一种容器流量采集装置,应用于部署在Linux主机上的客户端,所述Linux主机上运行有至少一个容器,所述装置包括:

获取模块,用于获取服务端下发的采集策略,所述采集策略包括待采集容器以及对应的流量采集规则;

采集模块,用于根据所述采集策略,应用对应的流量采集规则对所述待采集容器的veth-pair虚拟网卡进行容器流量采集;

发送模块,用于将采集到的容器流量发送至检测系统。

第三方面,本申请实施例提供的一种电子设备,包括:存储器、处理器以及存储在所述存储器中并可在所述处理器上运行的计算机程序,所述处理器执行所述计算机程序时实现如第一方面任一项所述的方法的步骤。

第四方面,本申请实施例提供的一种计算机可读存储介质,所述计算机可读存储介质上存储有指令,当所述指令在计算机上运行时,使得所述计算机执行如第一方面任一项所述的方法。

第五方面,本申请实施例提供的一种计算机程序产品,所述计算机程序产品在计算机上运行时,使得计算机执行如第一方面任一项所述的方法。

本申请公开的其他特征和优点将在随后的说明书中阐述,或者,部分特征和优点可以从说明书推知或毫无疑义地确定,或者通过实施本申请公开的上述技术即可得知。

为使本申请的上述目的、特征和优点能更明显易懂,下文特举较佳实施例,并配合所附附图,作详细说明如下。

附图说明

为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。

图1为本申请实施例提供的一种容器流量采集方法的流程图;

图2为本申请实施例提供的一种容器流量采集系统的整体架构的示意图;

图3为本申请实施例提供的一种容器流量采集装置的框图;

图4为本申请实施例提供的一种电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图,对本申请实施例中的技术方案进行描述。

应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。同时,在本申请的描述中,术语“第一”、“第二”等仅用于区分描述,而不能理解为指示或暗示相对重要性。

如背景技术记载,相关技术采集容器流量的方案存在着难以标准化、产品化的问题。基于此,本申请实施例提供一种容器流量采集方案,以解决这一问题。

接下来对本申请实施例进行介绍:

如图1所示,图1是本申请实施例提供的一种容器流量采集方法的流程图,所述方法可以应用于部署在Linux主机上的客户端。这里的Linux主机可以是基于Linux内核的操作系统配置的主机,其可以是物理机,也可以是虚拟机;其中,基于Linux内核的操作系统可以是CentOS、Debian、Ubuntu等的任意一种。在本实施例中,该Linux主机上运行有至少一个容器,一个容器包含了完整的运行时环境,除了应用程序本身以外,应用所需的依赖、类库、其他二进制文件以及配置文件等都统一被打入了一个称为容器镜像的包中。通过容器化,操作系统发行版本和其他基础环境造成的差异都被抽象掉了。当该Linux主机上运行多个容器时,这些容器内的进程是相互隔离的,且无法相互感知,其中一个容器的升级或者故障,不会影响其他容器。这里的客户端是执行本实施例的方法步骤的应用程序,用于采集容器流量。

所述方法包括:

在步骤101、获取服务端下发的采集策略,所述采集策略包括待采集容器以及对应的流量采集规则;

本步骤中提到的服务端可以是与客户端相对应,为客户端提供服务的程序。其中,该服务端可以部署在容器部署平台上,用以向各个Linux主机下发相应采集策略的服务。该服务端跟客户端之间可以基于HTTP(Hyper Text Transfer Protocol,超文本传输协议)通信,也可以基于其他方式通信。

在本实施例中,该服务端向客户端下发采集策略,该采集策略包括待采集容器以及对应的流量采集规则。也就是说,这里的采集策略指示了要采集的容器以及采集该容器的容器流量时的具体规则。该待采集容器可以是Linux主机上的全部或部分容器,例如,当Linux主机上运行有两个容器时,该待采集容器可以是这两个容器,也可以是其中任意一个容器。

为了方便客户端确定要采集的容器,在一些实施例中,采集策略中可以携带待采集容器的容器资产信息,该容器资产信息可以包括以下至少一种:容器ID、容器名称、MAC地址、IP地址、veth-pair虚拟网卡名称。以容器部署平台是Docker为例,Docker在创建容器时会自动为容器生成一个随机的名称,并为该容器创建容器ID,还会使用分配给容器的IP地址生成MAC地址以避免ARP冲突;veth-pair是一对虚拟设备接口,在Linux系统里,容器的网卡通过veth-pair虚拟网络设备进行创建,容器的网卡是veth-pair的一端,Linux主机有一个虚拟网卡对应veth-pair的另一端,容器运行时收发的网络流量会经过Linux主机对应的veth-pair虚拟网卡,本实施例利用这一原理,可以收集veth-pair虚拟网卡名称作为容器资产信息,以此确定待采集容器对应的veth-pair虚拟网卡,进而进行容器流量采集。当然,在其他实施例中,该容器资产信息还可以包括其他信息,本申请对此不作限制。

进一步地,在一些实施例中,该容器资产信息可以是服务端通过容器部署平台提供的API获取得到;和/或,该容器资产信息由客户端上报至服务端。容器部署平台上记录有各Linux主机上所运行的容器的一些相关信息,因此,服务端通过容器部署平台提供的API,可以查询并收集到一定程度的容器资产信息。而客户端部署在Linux主机上,其可以采集到该Linux主机上所运行的容器的一些相关信息,因此,由客户端上报,也可以使得服务端获取到一定程度的容器资产信息。优选地,这两种收集方式可以同时进行,以提高收集到的容器资产信息的完整性。当然,在其他实施例中,也可以采用其他收集方式。

本步骤中提到的流量采集规则是客户端采集容器流量时的过滤规则和/或限制规则。在一些实施例中,该流量采集规则可以包括以下至少一种:BPF过滤规则、限速阈值。BPF(Berkeley Packet Filter,伯克利包过滤器)是类Unix系统上数据链路层的一种原始接口,提供原始链路层封包的收发,并且支持过滤数据包。BPF过滤规则的设置,是让网络设备只捕获用户感兴趣的网络数据包,如通过指定端口收发的数据包、基于指定协议的数据包等;而如果没有设置BPF过滤规则,网络设备会捕获所有类型的数据包。限速阈值是客户端正常采集的容器流量的临界值,对于流量较大的容器,在实际采集的过程中需要考虑发送给检测系统的外部网络带宽限制,因此设置限速阈值,当一定时间段内采集到的容器流量达到该限速阈值时,客户端降低采集容器流量的频率甚至暂时停止采集容器流量。通过对BPF过滤规则和/或限速阈值的配置,方便采集技术的产品化。另外,在其他实施例中,该流量采集规则还可以包括其他内容,如采集间隔时间等等。

另外,在一些实施例中,该服务端可以提供配置界面,该配置界面可以供用户配置采集策略。也就是说,在服务端收集完容器资产信息后,用户可以在服务端上配置采集策略,指定要采集的容器以及对应的流量采集规则。例如,Linux主机上运行有三个容器,分别是容器1、容器2和容器3,用户可以在服务端上配置仅采集容器1和容器3,并且针对容器1可以配置仅捕获指定端口收发的数据包作为流量采集规则,针对容器3配置仅捕获基于指定协议的数据包作为流量采集规则。如此,实现采集策略的个性化配置,满足用户定制化需求。

在步骤102、根据所述采集策略,应用对应的流量采集规则对所述待采集容器的veth-pair虚拟网卡进行容器流量采集;

容器流量是指容器运行时收发的网络流量,而容器流量采集即是对容器运行时收发的数据包进行收集。对于客户端来说,其无法直接采集到容器内的网卡收发的网络流量,而本实施例利用容器运行时收发的网络流量都会经过对应的veth-pair虚拟网卡的这一原理,应用采集策略中的流量采集规则对待采集容器的veth-pair虚拟网卡进行容器流量采集,从而实现通用的容器流量采集。

具体地,在一些实施例中,本步骤可以包括:根据采集策略中携带的容器资产信息,确定待采集容器的veth-pair虚拟网卡;应用对应的流量采集规则采集该veth-pair虚拟网卡的容器流量。也就是说,客户端可以根据采集策略中携带的容器资产信息,确定要采集的容器,并确定该容器对应的veth-pair虚拟网卡,之后应用对应的流量采集规则进行抓包,从而实现容器流量的采集。需要说明的是,当该容器资产信息中不包括veth-pair虚拟网卡名称时,客户端可以根据其他容器资产信息,如待采集容器的IP地址查询对应的veth-pair虚拟网卡名称,进而确定待采集容器对应的veth-pair虚拟网卡。

客户端根据采集策略,对不同容器的veth-pair虚拟网卡进行采集,应用不同的BPF过滤规则和/或限速阈值。沿用前面的例子,客户端接收到采集策略后,对容器1的veth-pair虚拟网卡进行采集,且仅捕获指定端口收发的数据包;对容器2的veth-pair虚拟网卡不进行采集;对容器3的veth-pair虚拟网卡进行采集,且仅捕获基于指定协议的数据包。

本实施例中,用户在服务端配置采集策略,客户端根据该采集策略进行容器流量采集,不依赖容器部署平台的特定模块,因此是一种通用的容器流量采集方法,支持各种容器部署方式,包括但不限于Docker部署、K8S部署,因而易于标准化和产品化。

在步骤103、将采集到的容器流量发送至检测系统。

本步骤中提到的检测系统是用于对网络流量进行统计分析并能够检测出恶意或可疑的流量,从而保障业务系统安全的工具。可选地,该检测系统可以是NIDS(NetworkIntrusion Detection System,网络入侵检测系统)。NIDS是指对收集漏洞信息、造成拒绝访问及获取超出合法范围的系统控制权等危害计算机系统安全的行为,进行检测的软件与硬件的组合。客户端将采集到的容器流量发送至NIDS后,NIDS将这些容器流量作为资料提供给其IDS分析引擎组件,由该IDS分析引擎组件利用统计或规则的方式找出可能的入侵行为,并将事件提供给其响应组件,再由该响应组件采取相应的行为,如主动通知系统管理员、中断入侵者的连接和搜索入侵信息等。当然,在其他实施例中,该检测系统也可以是其他类型的网络流量检测工具,本申请对此不作限制。

具体地,在一些实施例中,本步骤可以包括:将采集到的容器流量封装成VXLAN格式或GRE格式后,发送至检测系统。VXLAN(Virtual Extensible Local Area Network,虚拟扩展局域网)格式是一种网络数据包封装格式,其报文封装是将二层以太网帧封装到UDP包,再加上VXLAN头,用以标识不同的二层网络。GRE(Generic Routing Encapsulation,通用路由封装)格式也是一种网络数据包封装格式,其提供了将一种协议的报文封装在另一种协议报文中的机制,是一种三层隧道封装技术。客户端每采集到一个报文,就对其进行VXLAN/GRE封装,使得封装后的报文能够传输至检测系统。当然,在其他实施例中,也可以采用其他封装格式,本申请对此不作限制。

进一步地,在一些实施例中,上述方法还可以包括:统计各容器的容器流量,并将统计结果上报至服务端。也就是说,客户端除了采集容器流量的功能以外,还可以提供针对各容器的容器流量的统计功能,客户端将统计结果上报至服务端后,可以给用户配置采集策略提供参考,例如,针对流量较大的容器,可以设置较为严格的限速阈值,针对流量较小的容器,则可以设置较为宽松的限速阈值,如此,为调整得到更为合理的采集策略提供数据支持。

更进一步地,在一些实施例中,该流量采集规则可以基于以下方式进行配置:若统计得到任一待采集容器的容器流量超过第一预设阈值,针对所述待采集容器配置的BPF过滤规则包括指定IP地址、指定端口、指定协议中的至少一种;若统计得到任一待采集容器的容器流量不超过第二预设阈值,针对所述待采集容器配置的BPF过滤规则为空。也就是说,当客户端的统计结果中存在任意待采集容器的容器流量超过预先设定的上限值,表明该待采集容器当前流量较大,此时可以配置较为严格的过滤规则,以使客户端对该待采集容器的veth-pair虚拟网卡进行采集时,可以根据指定IP地址、指定端口、指定协议等对原始流量进行过滤;而当客户端的统计结果中存在任意待采集容器的容器流量不超过预先设定的下限值,表明该待采集容器当前流量较小,此时可以配置对应的BPF过滤规则为空,以使客户端对该待采集容器的veth-pair虚拟网卡进行采集时,可以捕获全类型的数据包。如此,满足容器流量检测时数据采集需求和带宽限制的均衡,使得调整后的采集策略更为合理。其中,该第一预设阈值和该第二预设阈值可以根据具体场景的需求进行设置,本申请对此不作限制。

另外,在实际应用中,用户经常会出现更换采集策略的需求,因此,在一些实施例中,上述方法还可以包括:当获取到服务端下发的新的采集策略时,应用所述新的采集策略中的流量采集规则,对所述新的采集策略中的待采集容器的veth-pair虚拟网卡进行容器流量采集。也就是说,当用户配置新的采集策略,如新增对某个容器进行容器流量采集的需求时,客户端利用新的采集策略替换原先的采集策略,进而按照新的采集策略进行容器流量采集。如此,方便用户调整采集策略,提升用户的使用体验。

本申请实施例,部署在Linux主机上的客户端获取服务端下发的采集策略,并根据该采集策略,在Linux主机上对待采集容器的veth-pair虚拟网卡进行容器流量采集,并将采集到的容器流量上报至检测系统。如此,不仅支持各种容器部署方式,还支持对每一个要采集的容器配置单独的流量采集规则,配置更为灵活丰富,易于标准化和产品化。

为了对本申请的方案做更为详细的说明,接下来介绍一具体实施例:

如图2所示,图2是本申请实施例提供的一种容器流量采集系统的整体架构的示意图,该系统包括Linux主机21、采集控制服务端22和NIDS23,其中,Linux主机21上运行有三个容器,分别为容器1、容器2和容器3(图中标号依次为241、242、243),每个容器在Linux主机上有一个对应的veth-pair虚拟网卡(图中标号依次为251、252、253);Linux主机21上还运行有一个采集器26。

具体地,该系统采集容器流量的工作流程包括:

S201、采集控制服务端22收集容器资产信息,包括容器的ID、名称、MAC地址、IP地址、veth-pair虚拟网卡名称等;

其中,采集控制服务端22收集容器资产信息的方法有很多种,包括但不限于通过API获取、采集器26上报等;

S202、用户在采集控制服务端22配置采集策略,该采集策略包括要采集的容器以及对应的BPF过滤规则、限速阈值等;

其中,要采集的容器可以是三个容器中的全部或部分,不同容器可以对应不同BPF过滤规则,也可以对应不同的限速阈值;

S203、采集控制服务端22将采集策略下发给采集器26;

S204、采集器26根据采集策略,对不同容器的veth-pair虚拟网卡进行采集,应用不同的BPF过滤规则和限速阈值等;

S205、采集器26采集到容器流量后进行VXLAN/GRE封装,再发送给NIDS23。

由上可知,本申请实施例提供通用的容器流量采集方法,在Linux主机上对每个容器的veth-pair虚拟网卡进行采集,在各种容器部署方式中都支持,而且,用户可以以容器为粒度进行采集规则的配置,比如设置特定容器采集的BPF过滤规则、限速阈值等,配置更加灵活丰富,更易于标准化和产品化。

与前述方法的实施例相对应,本申请还提供容器流量采集装置及其应用的终端的实施例:

如图3所示,图3是本申请实施例提供的一种容器流量采集装置的框图,所述装置应用于部署在Linux主机上的客户端,所述Linux主机上运行有至少一个容器,所述装置包括:

获取模块31,用于获取服务端下发的采集策略,所述采集策略包括待采集容器以及对应的流量采集规则;

采集模块32,用于根据所述采集策略,应用对应的流量采集规则对所述待采集容器的veth-pair虚拟网卡进行容器流量采集;

发送模块33,用于将采集到的容器流量发送至检测系统。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程,在此不再赘述。

本申请还提供一种电子设备,请参见图4,图4为本申请实施例提供的一种电子设备的结构框图。电子设备可以包括处理器410、通信接口420、存储器430和至少一个通信总线440。其中,通信总线440用于实现这些组件直接的连接通信。其中,本申请实施例中电子设备的通信接口420用于与其他节点设备进行信令或数据的通信。处理器410可以是一种集成电路芯片,具有信号的处理能力。

上述的处理器410可以是通用处理器,包括中央处理器(CPU,Central ProcessingUnit)、网络处理器(NP,Network Processor)等;还可以是数字信号处理器(DSP)、专用集成电路(ASIC)、现成可编程门阵列(FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件。可以实现或者执行本申请实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器410也可以是任何常规的处理器等。

存储器430可以是,但不限于,随机存取存储器(RAM,Random Access Memory),只读存储器(ROM,Read Only Memory),可编程只读存储器(PROM,Programmable Read-OnlyMemory),可擦除只读存储器(EPROM,Erasable Programmable Read-Only Memory),电可擦除只读存储器(EEPROM,Electric Erasable Programmable Read-Only Memory)等。存储器430中存储有计算机可读取指令,当所述计算机可读取指令由所述处理器410执行时,电子设备可以执行上述图1方法实施例涉及的各个步骤。

可选地,电子设备还可以包括存储控制器、输入输出单元。

所述存储器430、存储控制器、处理器410、外设接口、输入输出单元各元件相互之间直接或间接地电性连接,以实现数据的传输或交互。例如,这些元件相互之间可通过一条或多条通信总线440实现电性连接。所述处理器410用于执行存储器430中存储的可执行模块,例如电子设备包括的软件功能模块或计算机程序。

输入输出单元用于提供给用户创建任务以及为该任务创建启动可选时段或预设执行时间以实现用户与服务器的交互。所述输入输出单元可以是,但不限于,鼠标和键盘等。

可以理解,图4所示的结构仅为示意,所述电子设备还可包括比图4中所示更多或者更少的组件,或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。

本申请实施例还提供一种存储介质,所述存储介质上存储有指令,当所述指令在计算机上运行时,所述计算机程序被处理器执行时实现方法实施例所述的方法,为避免重复,此处不再赘述。

本申请还提供一种计算机程序产品,所述计算机程序产品在计算机上运行时,使得计算机执行方法实施例所述的方法。

在本申请所提供的几个实施例中,应该理解到,所揭露的装置和方法,也可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,附图中的流程图和框图显示了根据本申请的多个实施例的装置、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现方式中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或动作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。

另外,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。

所述功能如果以软件功能模块的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括:U盘、移动硬盘、只读存储器(ROM,Read-Only Memory)、随机存取存储器(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅为本申请的实施例而已,并不用于限制本申请的保护范围,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。应注意到:相似的标号和字母在下面的附图中表示类似项,因此,一旦某一项在一个附图中被定义,则在随后的附图中不需要对其进行进一步定义和解释。

以上所述,仅为本申请的具体实施方式,但本申请的保护范围并不局限于此,任何熟悉本技术领域的技术人员在本申请揭露的技术范围内,可轻易想到变化或替换,都应涵盖在本申请的保护范围之内。因此,本申请的保护范围应所述以权利要求的保护范围为准。

需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

技术分类

06120115686820