CN107181701B - 公共网关接口数据的收集方法及装置 - Google Patents

Abstract

本发明实施例公开了一种公共网关接口数据的收集方法及装置，应用于计算机领域，该方法包括：通过第一虚拟网卡获取网络数据包，并通过物理网卡将该第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中，通过与该第二虚拟网卡关联的采集Docker容器，从该第二虚拟网卡中提取复制的网络数据包中的CGI数据，通过该采集Docker容器将该CGI数据发送给该第二虚拟网卡，并通过该第二虚拟网卡将该CGI数据传输给CGI数据收集集群进行收集，由于该采集Docker容器具有单独的CPU和内存，因此提取CGI数据的过程不会占用服务器的CPU和内存资源，进而不会影响服务器正常的业务程序。

Description

公共网关接口数据的收集方法及装置

技术领域

本发明实施例属于计算机技术领域，尤其涉及一种公共网关接口数据的收集方法及装置。

背景技术

超文本传输协议(HTTP，HyperText Transfer Protocol)流量属于公共网关接口(CGI，Common Gateway Interface)数据，HTTP流量是可以反映全球广域网(web，WorldWide Web)服务器、网络以及客户端之间的传输情况，例如，网络延时情况、web服务器的运行状态等。因此抓取HTTP流量并分析可以有效的监控网络传输情况，能够及时的发现并解决异常情况。

现有技术中，抓取HTTP流量的方法有很多，目前被广泛使用的方法是：通过为web服务器编写Nginx或者Apache的so扩展库，将编写好的so扩展库安装于web服务器上，以扩展的方式去抓取HTTP流量，然后将抓取到的HTTP转给远端服务器或本地进行分析和存储。

但是上述使用so扩展库的CGI数据收集方法存在以下缺陷：

首先，HTTP流量的抓取是从大量的数据流量中过滤、分析得到的，故需要消耗大量的服务器资源，由于上述so扩展库的CGI数据收集方法是与web服务器共享CPU和内存资源，因此在web服务器正常运行的业务程序繁忙时，会出现内存不足或CPU使用率过高的异常情况，进而影响服务器的正常运行。一般正常运行的业务程序主要是存储数据，并根据客户端中web浏览器发送的数据获取请求，将请求的数据反馈给web浏览器；

其次，针对每种web server均需要编写对应的so扩展程序，不具有通用性。

发明内容

本发明实施例提供一种公共网关接口数据的收集方法及装置，旨在解决现有的so扩展库的CGI数据收集方法所造成的服务器内存不足或CPU使用率过高的异常情况，进而影响服务器的正常运行的问题。

本发明实施例第一方面提供了一种公共网关接口数据的收集方法，包括：

通过第一虚拟网卡获取网络数据包，并通过物理网卡将所述第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中，其中所述第一虚拟网卡和所述第二虚拟网卡分别与所述物理网卡关联；

通过与所述第二虚拟网卡关联的采集Docker容器，从所述第二虚拟网卡中提取复制的网络数据包中的公共网关接口CGI数据；

通过所述采集Docker容器将所述CGI数据发送给所述第二虚拟网卡，并通过所述第二虚拟网卡将所述CGI数据传输给CGI数据收集集群进行收集。

本发明实施例第二方面提供了一种公共网关接口数据的收集装置，包括：

复制单元，用于通过第一虚拟网卡获取网络数据包，并通过物理网卡将所述第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中，其中所述第一虚拟网卡和所述第二虚拟网卡分别与所述物理网卡关联；

提取单元，用于通过与所述第二虚拟网卡关联的采集Docker容器，从所述第二虚拟网卡中提取复制的网络数据包中的公共网关接口CGI数据；

传输单元，用于通过所述采集Docker容器将所述CGI数据发送给所述第二虚拟网卡，并通过所述第二虚拟网卡将所述CGI数据传输给CGI数据收集集群进行收集。

本发明实施例提供的公共网关接口数据的收集方法及装置，是将网络数据包复制到单独的一个指定的采集Docker容器中，然后通过该采集Docker容器中预置的CGI数据提取程序来提取CGI数据，相较于现有的so扩展库的CGI数据收集方法，预置的CGI数据提取程序具有通用性，无需对每种服务器单独开发程序，只需将该CGI数据提取程序配置在指定的采集Docker容器中，即可实现对CGI数据的提取，同时，由于该采集Docker容器具有单独的CPU和内存，因此提取CGI数据的过程不会占用服务器的CPU和内存资源，进而不会影响服务器正常的业务程序。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例。

图1为本发明实施例提供的应用场景的示意图；

图2为本发明实施例提供的公共网关接口数据的收集装置结构示意图；

图3为本发明第一实施例提供的公共网关接口数据的收集方法的实现流程示意图；

图4为本发明第二实施例提供的公共网关接口数据的收集方法的实现流程示意图；

图5为本发明实施例提供的公共网关接口数据的收集装置结构示意图；

图6为本发明实施例提供的另一应用场景图；

图7为本发明实施例提供的公共网关接口数据的收集装置10与客户端100、CGI数据收集集群200之间的交互示意图；

图8为本发明第三实施例提供的公共网关接口数据的收集装置的结构示意图；

图9为本发明第四实施例提供的公共网关接口数据的收集装置的结构示意图。

具体实施方式

为使得本发明的发明目的、特征、优点能够更加的明显和易懂，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而非全部实施例。基于本发明中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

图1示出了上述公共网关接口数据的收集方法的一种示例性应用场景图，在该场景下，包括：公共网关接口数据的收集装置10、流量分析集群11以及数据库12。

流量分析集群11是一个服务器集群，一般流量分析集群11中包括两种设备，一种是存储集群，另一种是数据流处理设备。该流量分析集群11用于对CGI数据分析、去重等操作，以达到可以存入至数据库12的标准。

数据库12是按照数据结构来组织、存储和管理数据的建立在计算机存储设备上的仓库，该数据库12可以为网状数据库、关系数据库、树状数据库或面向对象数据库等种类。数据库12存储经流量分析集群11存入的CGI数据。

公共网关接口数据的收集装置10可以为一台物理服务器，也可以多台物理服务器集群，还可以物理服务器和物理服务器集群中的部分装置。该公共网关接口数据的收集装置10或公共网关接口数据的收集装置10所在的物理服务器支持SR-IOV技术。

图2为公共网关接口数据的收集装置10的结构示意图。如图2所示，该装置包括：总线1、处理器2、通信接口3和存储器4。处理器2、通信接口3、存储器4通过总线1相互连接。

其中，总线1包括一通路，在计算机系统各个器件间传送信息。处理器2可以是通用处理器，例如，中央处理器(CPU)、网络处理器(NP，network processor)或微处理器等，也可以是特定应用集成电路(ASIC，application-specific integrated circuit)，或一个或多个用于控制本发明技术方案的程序执行的集成电路。还可以是数字信号处理器(DSP，Digital Signal Processing)、现场可编程门阵列(FPGA，Field－Programmable GateArray)或其他可编程逻辑器件。

通信接口3可包括使用任何收发器的装置，以便于其他设备或通信网络进行通信，如以太网、无线接入网和无线局域网等。

存储器4中保存有执行本发明技术方案的程序，还可以保存有操作系统和其他关键业务。具体地，程序可以包括程序代码，该程序代码包括计算机操作指令。更具体地，存储器4可以包括只读存储器(ROM，read-only memory)、可存储信息和指令的其他类型的动态存储设备、磁盘存储器、闪存等。

数据的特征提取装置10的处理器2执行存储器4中所存放的程序，以及调用其他设备，可用于实现本发明实施例提供的公共网关接口数据的收集方法。

请参阅图3，图3为本发明第一实施例提供的公共网关接口数据的收集方法的实现流程示意图，可应用于上述公共网关接口数据的收集装置10中，主要包括以下步骤：

S301：通过第一虚拟网卡获取网络数据包，并通过物理网卡将该第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中。

该第一虚拟网卡和该第二虚拟网卡分别与该物理网卡关联。在实际应用中，公共网关接口数据的收集装置10中包括一个或多个内置的物理网卡，每一个物理网卡可以与一个或多个第一虚拟网卡相关联，以及与一个第二虚拟网卡相关联。通过将该物理网卡内的驱动程序驱动调用该物理网卡的寄存器中存储的配置参数，以实现通过该物理网卡将该第一虚拟网卡获取的网络数据包复制到该第二虚拟网卡的操作。其中该配置参数中包括复制的路径，例如，该物理网卡与第一虚拟网卡VF1和VF2关联，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，则第一虚拟网卡VF2获取的网络数据包将不能复制到第二虚拟网卡中，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，以及从第一虚拟网卡VF2到该第二虚拟网卡的复制路径，则该物理网卡分别将第一虚拟网卡VF1和VF2获取的网络数据包复制到第二虚拟网卡中。

S302：通过与该第二虚拟网卡关联的采集Docker容器，从该第二虚拟网卡中提取复制的网络数据包中的CGI数据。

Docker容器是一个开源的应用容器引擎，可以为任何应用创建一个轻量级的、可移植的、自给自足的容器。

本发明实施例中的采集Docker容器具有独立的CPU和内存，该Docker容器与该第二虚拟网卡相关联，这样复制到该第二虚拟网卡中的网络数据包可以输入至该采集Docker容器中。

预先在该采集Docker容器的CPU中设置有提取CGI数据的应用程序，通过该采集Docker容器运行该应用程序来提取CGI数据，这样无需占用公共网关接口数据的收集装置10自身的CPU和内存资源。

上述该提取CGI数据的应用程序是具有通用性的，如果有多个公共网关接口数据的收集装置10，无需针对每一个公共网关接口数据的收集装置10设置独有的提取程序，只需预先设置该采集Docker容器，并在该采集Docker容器中配置该提取CGI数据的应用程序即可。

该CGI数据是反映网络、客户端以及服务器之间传输情况的数据。

S303：通过该采集Docker容器将该CGI数据发送给该第二虚拟网卡，并通过该第二虚拟网卡将该CGI数据传输给CGI数据收集集群进行收集。

该CGI数据收集集群是多台服务器的集群，主要用于处理和存储接收到的CGI数据。该CGI数据收集集群包括：上述的流量分析集群11和数据库12。

在本发明实施例中，是将网络数据包复制到单独的一个指定的采集Docker容器中，然后通过该采集Docker容器中预置的CGI数据提取程序来提取CGI数据，相较于现有的so扩展库的CGI数据收集方法，预置的CGI数据提取程序具有通用性，无需对每种服务器单独开发程序，只需将该CGI数据提取程序配置在指定的采集Docker容器中，即可实现对CGI数据的提取，同时，由于该采集Docker容器具有单独的CPU和内存，因此提取CGI数据的过程不会占用服务器的CPU和内存资源，进而不会影响服务器正常的业务程序。

请参阅图4，图4为本发明第二实施例提供的公共网关接口数据的收集方法的实现流程示意图，可应用于上述公共网关接口数据的收集装置10中。

结合图5，图5为本发明实施例提供的上述公共网关接口数据的收集装置10的结构示意图。需要说明的是，图5是在图2示出的硬体结构的基础上的结构示意图。图5示出的装置包括：物理网卡101，又称网络适配器(NIC，Network Interface Card)、业务Docker容器D1、D2和D3和一个采集Docker容器D0，其中，该物理网卡101分别与第一虚拟网卡VF1、VF2和VF3，以及一个第二虚拟网卡VF0相关联，第一虚拟网卡VF1、VF2和VF3分别与业务Docker容器D1、D2和D3关联，且该第二虚拟网卡VF0与该采集Docker容器D0相关联。图5中，第一虚拟网卡VF1、VF2和VF3分别与业务Docker容器D1、D2和D3之间的连线表示关联，第二虚拟网卡VF0与采集Docker容器D0之间的连线表示关联。需要说明的是，图5为示例图，同一公共网关接口数据的收集装置10中，不会对物理网卡、第一虚拟网卡、第二虚拟网卡、业务Docker容器以及采集Docker容器的数量构成任何限定。

图4示出的公共网关接口数据的收集方法，主要包括以下步骤：

S401：通过第一虚拟网卡从局域网或广域网中，获取客户端发送的带有业务请求的网络数据包。

该第一虚拟网卡可以为上述图5中第一虚拟网卡VF1、VF2和VF3中的一个或多个。该客户端可以是安装于手机、电脑、平板电脑等可以登录网络的终端内的浏览器。用户通过该客户端可以向公共网关接口数据的收集装置10(物理服务器)发送业务请求，然后通过该第一虚拟网卡从局域网或广域网中，获取该客户端发送的带有业务请求的网络数据包。

公共网关接口数据的收集装置10或公共网关接口数据的收集装置10所在的物理服务器属于web服务器。该业务请求一般是用户通过与web服务器(公共网关接口数据的收集装置10)关联的浏览器发送的请求。例如，当用户通过手机打开浏览器，点击某网页时，会向公共网关接口数据的收集装置10(web服务器)发送用于打开该网页的HTTP请求；当用户通过手机打开浏览器，并点击网页中的视频框时，会向该公共网关接口数据的收集装置10(web服务器)发送用于播放该视频对应的多媒体文件的业务请求。

该网络数据包是包含有该业务请求的数据的数据包。在实际应用中，该网络数据包中包含有目的IP地址，该第一虚拟网卡依据该目的IP地址获取网络数据包。

S402：通过该第一虚拟网卡，将该网络数据包转发给与该第一虚拟网卡关联的业务Docker容器。

业务Docker容器可以为图5示出的业务Docker容器D1、D2和D3中的一个或多个。在实际应用中，每一个第一虚拟网卡均关联一个业务Docker容器，使得该第一虚拟网卡获取的网络数据包可以转入与其相关联的业务Docker容器中进行处理。其中，每一个业务Docker容器中包含单独的CPU和内存。

S403：通过该业务Docker容器，对该网络数据包进行解析，并根据解析结果生成响应该业务请求的数据。

生成该响应该业务请求的数据的过程就是：将该网络数据包进行拆分，以获取业务请求的数据，然后根据获取的业务请求的数据生成响应该业务请求的数据。例如，当用户通过手机打开浏览器，点击某网页时，向公共网关接口数据的收集装置10(web服务器)发送用于打开该网页的HTTP请求，通过对该HTTP请求的网络数据包进行解析，查找到打开该网页的链接信息以及该网页的脚本。

S404：通过与该业务Docker容器关联的第一虚拟网卡，将生成的响应数据发送给该客户端，使得该客户端根据该响应数据执行与该业务请求对应的操作。

在实际应用中，将生成的响应数据封装于数据包内，并以数据包的形式反馈给客户端。例如，在步骤S403的举例中，将该链接信息以及该网页的脚本以数据包的形式反馈给客户端，通过客户端中的浏览器就可以进入该网页并显示该网页，此时用户可以看到该网页的内容。

S405：通过物理网卡将该第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中。

该第一虚拟网卡和该第二虚拟网卡分别与该物理网卡关联。在实际应用中，公共网关接口数据的收集装置10中包括一个或多个内置的物理网卡，每一个物理网卡可以与一个或多个第一虚拟网卡相关联，以及与一个第二虚拟网卡相关联。通过将该物理网卡内的驱动程序驱动调用该物理网卡的寄存器中存储的配置参数，以实现通过该物理网卡将该第一虚拟网卡获取的网络数据包复制到该第二虚拟网卡的操作。其中该配置参数中包括复制的路径，例如，该物理网卡与第一虚拟网卡VF1和VF2关联，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，则第一虚拟网卡VF2获取的网络数据包将不能复制到第二虚拟网卡中，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，以及从第一虚拟网卡VF2到该第二虚拟网卡的复制路径，则该物理网卡分别将第一虚拟网卡VF1和VF2获取的网络数据包复制到第二虚拟网卡中。其中该第二虚拟网卡可以为图5示出的第二虚拟网卡VF0。

S406：通过采集Docker容器，从该第二虚拟网卡中提取复制的网络数据包。

该采集Docker容器为图5示出的采集Docker容器D0。该采集Docker容器中设置有单独的CPU和内存，这样避免与上述业务Docker容器共享CPU和内存资源，进而避免出现处理业务请求的CPU使用率高或内存资源不足的异常情况。这样将该第一虚拟网卡获取到的网络数据包均转入该采集Docker容器，方便了该采集Docker容器后续提取网络数据包中的CGI数据。

S407：通过该采集Docker容器，按照传输控制协议/因特网互联协议的协议栈逐层解析该复制的网络数据包，直至解析到该传输控制协议/因特网互联协议的协议栈的应用层，得到从该应用层解析出的数据流量。

传输控制协议/因特网互联协议(TCP/IP，Transmission Control Protocol/Internet Protocol)共有7层协议，按照TCP/IP的协议栈逐层解析该复制的网络数据包。

S408：通过该采集Docker容器从该应用层解析出的数据流量中提取HTTP流量。

该提取的HTTP流量为上述步骤S406中所描述的后续从该网络数据包中提取的CGI数据。

S409：通过该采集Docker容器，对该HTTP流量进行过滤清洗，以滤除异常数据，得到清洗后的HTTP流量。

该异常数据包括：不符合HTTP协议的数据、扫描无漏洞的数据以及数据包体大小超过预置数值的数据。该无漏洞的数据可以为图片、客户端下载的文件等数据。该预置数值不做限定，可以为1G，也可以为2G。

S410：通过该采集Docker容器将该清洗后的HTTP流量发送给该第二虚拟网卡。

由于该采集Docker容器和该第二虚拟网卡相关联，所以该采集Docker容器中的数据均需要从该第二虚拟网卡向后端的服务器或其他设备进行发送。

S411：通过该第二虚拟网卡将该清洗后的HTTP流量传输给该CGI数据收集集群中的流量分析集群，以使该流量分析集群对该清洗后的HTTP流量进行处理，并将处理后的HTTP流量存储于该CGI数据收集集群中的数据库中。

CGI数据收集集群包括：该流量分析集群和该数据库。该流量分析集群和该数据库分别为上述图1示出的流量分析集群11和数据库12，其中，该流量分析集群11中包括KAFKA存储集群、STORM系统和REDIS存储系统。以公共网关接口数据的收集装置10为物理服务器为示例，图6为另一应用场景示意图，该应用场景包括：多个物理服务器10、KAFKA存储集群110、STORM系统111和REDIS存储系统112和数据库12。

KAFKA存储集群110是一种高吞吐量的分布式发布订阅消息系统，包含一个或多个服务器。与该KAFKA存储集群110关联的装置可以从该KAFKA存储集群110中读取所需的数据。

STORM系统111是一个开源的分布式实时计算系统，可以简单、可靠的处理大量的数据流。在本发明实施例中STORM系统是用于完成对HTTP流量的初步去重和分析。

REDIS存储系统112是一种内存数据库，本发明实施例中的REDIS存储系统112用于数据的二次去重。

该KAFKA存储集群110接收该HTTP流量，然后由STORM系统111从该KAFKA存储集群110中读取该HTTP流量，并对该HTTP流量进行初步去重和分析，然后将经初步去重和分析后的数据发送给REDIS存储系统112，REDIS存储系统112对接收到的数据进行二次去重，得到二次去重后的数据，并将该二次去重后的数据存入数据库12中。

需要说明的是，本发明实施例中与第一实施例相同的描述，请参阅第一实施例相应的描述，此处不再赘述。

本发明实施例中，是将网络数据包复制到单独的一个指定的采集Docker容器中，然后通过该采集Docker容器中预置的CGI数据提取程序来提取CGI数据(HTTP流量)，相较于现有的so扩展库的CGI数据收集方法，预置的CGI数据提取程序具有通用性，无需对每种服务器单独开发程序，只需将该CGI数据提取程序配置在指定的采集Docker容器中，即可实现对CGI数据的提取，同时，由于该采集Docker容器具有单独的CPU和内存，因此提取CGI数据的过程不会占用服务器的CPU和内存资源，进而不会影响服务器正常的业务程序。

图7为上述公共网关接口数据的收集装置10(物理服务器)与客户端100和CGI数据收集集群200之间的交互示意图。其中该公共网关接口数据的收集装置10中包括：物理网卡101、业务Docker容器102、采集Docker容器103。

需要说明的是，图7为硬体装置间的交互图，本发明实施例中的该第一虚拟网卡和该第二虚拟网卡为与该物理网卡101关联的软体模块，该第一虚拟网卡和第二虚拟网卡相应的硬体实现为物理网卡101，故此处省略了第一虚拟网卡和第二虚拟网卡。

S701：客户端100向物理网卡101发送带有业务请求的网络数据包；

S702：物理网卡101接收该网络数据包并复制该网络数据包；

S703：物理网卡101将接收的网络数据包转发给业务Docker容器102；

S704：物理网卡101将复制的网络数据包转发给采集Docker容器103；

S705：业务Docker容器102解析该网络数据包，并根据解析结果生成响应该业务请求的数据；

S706：业务Docker容器102将生成的响应数据发送至物理网卡101中；

S707：物理网卡101将该响应数据反馈给客户端100；

S708：采集Docker容器103提取该复制的网络数据包中的HTTP流量，并对该HTTP流量进行过滤清洗，得到清洗后的HTTP流量；

S709：采集Docker容器103将该清洗后的HTTP流量发送给物理网卡101；

S710：物理网卡101将该清洗后的HTTP流量传输给CGI数据收集集群200进行收集。

请参阅图8，图8为本发明第三实施例提供的公共网关接口数据的收集装置的结构示意图，为了便于说明，仅示出了与本发明实施例相关的部分。图8示例的公共网关接口数据的收集装置可以是前述图3所示实施例提供的公共网关接口数据的收集方法的执行主体。图8示例的公共网关接口数据的收集装置，主要包括：复制单元801、提取单元802和传输单元803。以上各功能模块详细说明如下：

复制单元801，用于通过第一虚拟网卡获取网络数据包，并通过物理网卡将该第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中。

其中该第一虚拟网卡和该第二虚拟网卡分别与该物理网卡关联。在实际应用中，公共网关接口数据的收集装置10中包括一个或多个内置的物理网卡，每一个物理网卡可以与一个或多个第一虚拟网卡相关联，以及与一个第二虚拟网卡相关联。通过将该物理网卡内的驱动程序驱动调用该物理网卡的寄存器中存储的配置参数，以实现通过该物理网卡将该第一虚拟网卡获取的网络数据包复制到该第二虚拟网卡的操作。其中该配置参数中包括复制的路径，例如，该物理网卡与第一虚拟网卡VF1和VF2关联，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，则第一虚拟网卡VF2获取的网络数据包将不能复制到第二虚拟网卡中，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，以及从第一虚拟网卡VF2到该第二虚拟网卡的复制路径，则该物理网卡分别将第一虚拟网卡VF1和VF2获取的网络数据包复制到第二虚拟网卡中。

提取单元802，用于通过与该第二虚拟网卡关联的采集Docker容器，从该第二虚拟网卡中提取复制的网络数据包中的公共网关接口CGI数据。

传输单元803，用于通过该采集Docker容器将该CGI数据发送给该第二虚拟网卡，并通过该第二虚拟网卡将该CGI数据传输给CGI数据收集集群进行收集。

该CGI数据收集集群是多台服务器的集群，主要用于处理和存储接收到的CGI数据。该CGI数据收集集群包括：上述的流量分析集群11和数据库12。

本发明实施例中，复制单元801将网络数据包复制到单独的一个指定的采集Docker容器中，然后提取单元802通过该采集Docker容器中预置的CGI数据提取程序来提取CGI数据，相较于现有的so扩展库的CGI数据收集方法，预置的CGI数据提取程序具有通用性，无需对每种服务器单独开发程序，只需将该CGI数据提取程序配置在指定的采集Docker容器中，即可实现对CGI数据的提取，同时，由于该采集Docker容器具有单独的CPU和内存，因此提取CGI数据的过程不会占用服务器的CPU和内存资源，进而不会影响服务器正常的业务程序。

请参阅图9，图9为本发明第四实施例提供的公共网关接口数据的收集装置的结构示意图，为了便于说明，仅示出了与本发明实施例相关的部分。图9示例的公共网关接口数据的收集装置可以是前述图3和图4所示实施例提供的公共网关接口数据的收集方法的执行主体。图9示例的公共网关接口数据的收集装置，主要包括：复制单元901、提取单元902、传输单元903、业务处理单元904和过滤单元905，其中该提取单元902中包括：提取子单元9021和解析子单元9022。以上各功能模块详细说明如下：

复制单元901，用于通过第一虚拟网卡从局域网或广域网中，获取客户端发送的带有业务请求的网络数据包。

该客户端可以是安装于手机、电脑、平板电脑等可以登录网络的终端内的浏览器。用户通过该客户端可以向公共网关接口数据的收集装置10(物理服务器)发送业务请求。

该网络数据包是包含有该业务请求的数据的数据包。在实际应用中，该网络数据包中包含有目的IP地址，该第一虚拟网卡依据该目的IP地址获取网络数据包。

传输单元903，用于通过该第一虚拟网卡，将该网络数据包转发给与该第一虚拟网卡关联的业务Docker容器。

在实际应用中，每一个第一虚拟网卡均关联一个业务Docker容器，使得该第一虚拟网卡获取的网络数据包可以转入与其相关联的业务Docker容器中进行处理。其中，每一个业务Docker容器中包含单独的CPU和内存。

业务处理单元904，用于通过该业务Docker容器，对该网络数据包进行解析，并根据解析结果生成响应该业务请求的数据。

传输单元903，还用于通过与该业务Docker容器关联的第一虚拟网卡，将生成的响应数据发送给该客户端，使得该客户端根据该响应数据执行与该业务请求对应的操作。

在实际应用中，将生成的响应数据封装于数据包内，并以数据包的形式反馈给客户端。

复制单元901，还用于通过物理网卡将该第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中。

该第一虚拟网卡和该第二虚拟网卡分别与该物理网卡关联。在实际应用中，公共网关接口数据的收集装置10中包括一个或多个内置的物理网卡，每一个物理网卡可以与一个或多个第一虚拟网卡相关联，以及与一个第二虚拟网卡相关联。通过将该物理网卡内的驱动程序驱动调用该物理网卡的寄存器中存储的配置参数，以实现通过该物理网卡将该第一虚拟网卡获取的网络数据包复制到该第二虚拟网卡的操作。其中该配置参数中包括复制的路径，例如，该物理网卡与第一虚拟网卡VF1和VF2关联，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，则第一虚拟网卡VF2获取的网络数据包将不能复制到第二虚拟网卡中，若该配置参数中包括从第一虚拟网卡VF1到该第二虚拟网卡的复制路径，以及从第一虚拟网卡VF2到该第二虚拟网卡的复制路径，则该物理网卡分别将第一虚拟网卡VF1和VF2获取的网络数据包复制到第二虚拟网卡中。

提取单元902，用于通过与该第二虚拟网卡关联的采集Docker容器，从该第二虚拟网卡中提取复制的网络数据包中的CGI数据。

进一步地，提取子单元9021，用于通过该采集Docker容器，从该第二虚拟网卡中提取该复制的网络数据包。

进一步地，解析子单元9022，用于通过该采集Docker容器，按照传输控制协议/因特网互联协议的协议栈逐层解析该复制的网络数据包，直至解析到该传输控制协议/因特网互联协议的协议栈的应用层，得到从该应用层解析出的数据流量。

该采集Docker容器中设置有单独的CPU和内存，这样避免与上述业务Docker容器共享CPU和内存资源，进而避免了出现处理业务请求的CPU使用率高或内存资源不足的异常情况。该第一虚拟网卡获取到的网络数据包均转入该采集Docker容器，方便了该采集Docker容器后续提取网络数据包中的CGI数据。

进一步地，提取子单元9021，还用于通过该采集Docker容器从该应用层解析出的数据流量中提取HTTP流量。

过滤单元905，用于通过该采集Docker容器，对该HTTP流量进行过滤清洗，以滤除异常数据，得到清洗后的HTTP流量。

传输单元903，还用于通过该第二虚拟网卡将该清洗后的HTTP流量传输给CGI数据收集集群中的流量分析集群，以使该流量分析集群对该清洗后的HTTP流量进行处理，并将处理后的HTTP流量存储于该CGI数据收集集群中的数据库中。

该CGI数据收集集群包括：该流量分析集群和该数据库。该流量分析集群和该数据库分别为上述图1示出的流量分析集群11和数据库12。

本实施例未尽之细节，请参阅前述图3和图4所示实施例的描述，此处不再赘述。

本发明实施例中，复制单元901将网络数据包复制到单独的一个指定的采集Docker容器中，然后提取单元902通过该采集Docker容器中预置的CGI数据提取程序来提取CGI数据(HTTP流量)，相较于现有的so扩展库的CGI数据收集方法，预置的CGI数据提取程序具有通用性，无需对每种服务器单独开发程序，只需将该CGI数据提取程序配置在指定的采集Docker容器中，即可实现对CGI数据的提取，同时，由于该采集Docker容器具有单独的CPU和内存，因此提取CGI数据的过程不会占用服务器的CPU和内存资源，进而不会影响服务器正常的业务程序。

在本申请所提供的多个实施例中，应该理解到，所揭露的系统、装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，所述模块的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个模块或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信链接可以是通过一些接口，装置或模块的间接耦合或通信链接，可以是电性，机械或其它的形式。

所述作为分离部件说明的模块可以是或者也可以不是物理上分开的，作为模块显示的部件可以是或者也可以不是物理模块，即可以位于一个地方，或者也可以分布到多个网络模块上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

另外，在本发明各个实施例中的各功能模块可以集成在一个处理模块中，也可以是各个模块单独物理存在，也可以两个或两个以上模块集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本发明所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上为对本发明实施例提供的公共网关接口数据的收集方法及装置的描述，对于本领域的技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上，本说明书内容不应理解为对本发明的限制。

Claims (10)

1.一种公共网关接口数据的收集方法，其特征在于，包括：

通过第一虚拟网卡获取网络数据包，并通过物理网卡内的驱动程序调用所述物理网卡的寄存器中存储的配置参数，将所述第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中，其中所述第一虚拟网卡和所述第二虚拟网卡分别与所述物理网卡关联，所述配置参数包括复制的路径；

通过与所述第二虚拟网卡关联的采集Docker容器，从所述第二虚拟网卡中提取复制的网络数据包中的公共网关接口CGI数据；

通过所述采集Docker容器将所述CGI数据发送给所述第二虚拟网卡，并通过所述第二虚拟网卡将所述CGI数据传输给CGI数据收集集群进行收集。

2.根据权利要求1所述的方法，其特征在于，所述通过第一虚拟网卡获取网络数据包，包括：

通过所述第一虚拟网卡从局域网或广域网中，获取客户端发送的带有业务请求的网络数据包；

则所述方法还包括：

通过所述第一虚拟网卡，将所述网络数据包转发给与所述第一虚拟网卡关联的业务Docker容器；

通过所述业务Docker容器，对所述网络数据包进行解析，并根据解析结果生成响应所述业务请求的数据；

通过与所述业务Docker容器关联的第一虚拟网卡，将生成的响应数据发送给所述客户端，使得所述客户端根据所述响应数据执行与所述业务请求对应的操作。

3.根据权利要求1所述的方法，其特征在于，所述CGI数据为超文本传输协议HTTP流量；

则所述通过与所述第二虚拟网卡关联的采集Docker容器，从所述第二虚拟网卡中提取复制的网络数据包中的公共网关接口CGI数据，包括：

通过所述采集Docker容器，从所述第二虚拟网卡中提取所述复制的网络数据包；

通过所述采集Docker容器，按照传输控制协议/因特网互联协议的协议栈逐层解析所述复制的网络数据包，直至解析到所述传输控制协议/因特网互联协议的协议栈的应用层，得到从所述应用层解析出的数据流量；

通过所述采集Docker容器，从所述应用层解析出的数据流量中提取所述HTTP流量。

4.根据权利要求3所述的方法，其特征在于，所述通过所述采集Docker容器将所述CGI数据 发送给所述第二虚拟网卡之前，还包括：

通过所述采集Docker容器，对所述HTTP流量进行过滤清洗，以滤除异常数据，得到清洗后的HTTP流量。

5.根据权利要求4所述的方法，其特征在于，所述通过所述采集Docker容器将所述CGI数据发送给所述第二虚拟网卡，并通过所述第二虚拟网卡将所述CGI数据传输给CGI数据收集集群进行收集，包括：

通过所述采集Docker容器将所述清洗后的HTTP流量发送给所述第二虚拟网卡；

通过所述第二虚拟网卡将所述清洗后的HTTP流量传输给所述CGI数据收集集群中的流量分析集群，以使所述流量分析集群对所述清洗后的HTTP流量进行处理，并将处理后的HTTP流量存储于所述CGI数据收集集群中的数据库中。

6.一种公共网关接口数据的收集装置，其特征在于，所述装置包括：

复制单元，用于通过第一虚拟网卡获取网络数据包，并通过物理网卡内的驱动程序调用所述物理网卡的寄存器中存储的配置参数，将所述第一虚拟网卡获取的网络数据包复制到第二虚拟网卡中，其中所述第一虚拟网卡和所述第二虚拟网卡分别与所述物理网卡关联，所述配置参数包括复制的路径；

提取单元，用于通过与所述第二虚拟网卡关联的采集Docker容器，从所述第二虚拟网卡中提取复制的网络数据包中的公共网关接口CGI数据；

传输单元，用于通过所述采集Docker容器将所述CGI数据发送给所述第二虚拟网卡，并通过所述第二虚拟网卡将所述CGI数据传输给CGI数据收集集群进行收集。

7.根据权利要求6所述的装置，其特征在于，

所述复制单元，还用于通过所述第一虚拟网卡从局域网或广域网中，获取客户端发送的带有业务请求的网络数据包；

所述传输单元，还用于通过所述第一虚拟网卡，将所述网络数据包转发给与所述第一虚拟网卡关联的业务Docker容器；

所述装置还包括：业务处理单元，用于通过所述业务Docker容器，对所述网络数据包进行解析，并根据解析结果生成响应所述业务请求的数据；

所述传输单元，还用于通过与所述业务Docker容器关联的第一虚拟网卡，将生成的响应数据发送给所述客户端，使得所述客户端根据所述响应数据执行与所述业务请求对应的操作。

8.根据权利要求6所述的装置，其特征在于，所述CGI数据为超文本传输协议HTTP流量；

则所述提取单元包括：

提取子单元，用于通过所述采集Docker容器，从所述第二虚拟网卡中提取所述复制的网络数据包；

解析子单元，用于通过所述采集Docker容器，按照传输控制协议/因特网互联协议的协议栈逐层解析所述复制的网络数据包，直至解析到所述传输控制协议/因特网互联协议的协议栈的应用层，得到从所述应用层解析出的数据流量；

所述提取子单元，还用于通过所述采集Docker容器，从所述应用层解析出的数据流量中提取所述HTTP流量。

9.根据权利要求8所述的装置，其特征在于，所述装置还包括：

过滤单元，用于通过所述采集Docker容器，对所述HTTP流量进行过滤清洗，以滤除异常数据，得到清洗后的HTTP流量。

10.根据权利要求9所述的装置，其特征在于，所述传输单元，还用于：

通过所述采集Docker容器将所述清洗后的HTTP流量发送给所述第二虚拟网卡；

通过所述第二虚拟网卡将所述清洗后的HTTP流量传输给所述CGI数据收集集群中的流量分析集群，以使所述流量分析集群对所述清洗后的HTTP流量进行处理，并将处理后的HTTP流量存储于所述CGI数据收集集群中的数据库中。