CN108881425A - 一种数据包处理方法及系统 - Google Patents

Abstract

本发明提供了一种数据包处理方法及系统，应用于万维网Web服务器，Web服务器用于处理网络层、传输层和应用层的请求数据包。该方法包括预先构建Web应用服务器底层的数据平面开发工作集DPDK，调用DPDK提供的接口函数来接收客户端发送的请求数据包，确定请求数据包的请求类型。并基于请求数据包的请求类型对请求数据包进行处理，得到响应数据包，调用DPDK提供的发送函数发送响应数据包。本发明基于DPDK对数据包进行处理，加快了数据包的处理速度和极大增加了Web服务器的并发量。

Description

一种数据包处理方法及系统

技术领域

本发明涉及数据包处理技术领域，具体涉及一种数据包处理方法及系统。

背景技术

随着科学技术的发展，网络早已成为人们生活中不可切割的一部分，在网络技术最初发展的时候，由于使用范围小和使用人数少，所以对服务器并发量和响应时间的要求并不高。但随着互联网的高速发展，网络的使用范围急速扩大，用户以及服务的数量和种类也越来越多，所以对服务器的并发量和响应时间的要求也越来越高。

全球广域网(World Wild Web)应用服务器是一种运行在物理服务器上的软件框架，基本功能是提供Web信息浏览服务，其主要支持超文本传输协议(HyperText TransferProtocol，HTTP)，响应客户端浏览器发出的HTTP请求。现有的大部分Web服务器虽然功能强大，但这些传统Web服务器大多都是应用在复杂业务场景中，而现有的Web服务器在处理一些需要极高并发量且业务逻辑简单的场景中会存在臃肿、并发量小和效率低下的问题。

发明内容

有鉴于此，本发明实施例提供一种数据包处理方法及系统，以解决现有Web服务器在处理极高并发且业务逻辑简单的场景存在的臃肿、并发量小和效率低下的问题。

为实现上述目的，现提出的方案如下：

本发明实施例第一方面提供了一种数据包处理方法，应用于万维网web服务器，所述web服务器用于处理网络层、传输层和应用层的请求数据包，所述方法包括：

调用数据平面开发工作集DPDK提供的第一接口函数，所述DPDK为预先构建于web应用服务器底层的DPDK，所述第一接口函数为rte_eth_rx_burst函数；

基于所述第一接口函数接收客户端发送的请求数据包；

确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包；

调用所述DPDK提供的第二接口函数向所述客户端发送所述响应数据包，所述第二接口函数为rte_eth_tx_burst函数。

可选的，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

基于协议头部类型字段确定所述请求数据包为链路层协议类型的ARP协议包；

则生成反向地址转换协议RARP响应数据包。

可选的，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

基于协议头部类型字段确定所述请求数据包为网络层协议类型的ICMP协议包；或者，基于协议头部类型字段确定所述请求数据包为Ipv6协议类型的ICMP协议包；

基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包；

若是，则对所述ICMP请求数据包进行处理，将得到的回显应答包作为响应数据包。

可选的，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

基于协议头部类型字段确定所述请求数据包为传输层协议类型的TCP协议包；

根据所述TCP协议包的头部标志位字段确定所述TCP协议包的请求类型；

若所述头部标志位字段为SYN，确定所述TCP协议包的请求类型为握手请求；

生成标志位为SYN和ACK的响应数据包；

若所述头部标志位字段为FIN，确定所述TCP协议包的请求类型为挥手请求；

生成标志位为ACK的响应数据包；

若所述头部标志位字段为ACK，确定所述TCP协议包的请求类型为发送数据请求；

解析所述TCP协议包，获取HTTP协议数据包；

在应用层解析所述HTTP协议数据包，得到HTTP请求；

调用数据层中与所述HTTP请求相对应的数据，并封装，得到HTTP响应包；

对所述HTTP响应包进行处理，生成包含所请求发送的数据的响应数据包，所述HTTP响应包中包括所请求发送的数据。

可选的，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

根据所述请求数据包的IP头部协议类型字段确定所述请求数据包为采用Ipv4协议或Ipv6协议类型的TCP协议包；

执行根据所述TCP协议包的头部标志位字段确定所述协议包的请求类型这一步骤。

本发明实施例第二方面提供了一种数据包处理系统，应用于万维网web服务器，所述web服务器用于处理网络层、传输层和应用层的请求数据包，所述方法包括：

调用模块，用于调用数据平面开发工作集DPDK提供的第一接口函数，以及，调用所述DPDK提供的第二接口函数发送响应数据包，所述DPDK为预先构建于web应用服务器底层的DPDK，所述第一接口函数为rte_eth_rx_burst函数，所述第二接口函数为rte_eth_tx_burst函数；

接收模块，用于基于所述第一接口函数接收客户端发送的请求数据包；

处理模块，用于确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到所述响应数据包。

可选的，所述处理模块包括：

设置于网络层的ARP处理模块，用于基于协议头部类型字段确定所述请求数据包为链路层协议类型的ARP协议包，则生成RARP响应数据包。

可选的，所述处理模块包括：

设置于网络层的ICMP处理模块，用于基于协议头部类型字段确定所述请求数据包为所述网络层协议类型的ICMP协议包，基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包，若是，则对所述ICMP请求数据包进行处理，将得到的回显应答包作为响应数据包；和/或，

设置于网络层的ICMPv6处理模块，用于处理Ipv6协议类型的ICMP协议包，基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包，若是，则对所述ICMP请求数据包进行处理，将得到的回显应答包作为响应数据包。

可选的，所述处理模块包括：

设置于传输层的TCP处理模块，用于确定所述请求数据包为传输层协议类型的TCP协议包，根据所述TCP协议包的头部标志位字段确定所述TCP协议包的请求类型，若所述头部标志位字段为SYN，确定所述TCP协议包的请求类型为握手请求，生成标志位为SYN和ACK的响应数据包；若所述头部标志位字段为FIN，确定所述TCP协议包的请求类型为挥手请求，生成标志位为ACK的响应数据包；若所述头部标志位字段为ACK，确定所述TCP协议包的请求类型为发送数据请求，解析所述TCP协议包，获取HTTP协议数据包，将所述HTTP协议数据包发送至HTTP处理模块，以及对接收到的HTTP响应包进行处理，生成包含所请求发送的数据的响应数据包；

设置于应用层的HTTP处理模块，用于解析所述HTTP协议数据包，得到HTTP请求，调用数据层中与所述HTTP请求相对应的数据，并封装，得到HTTP响应包，所述HTTP响应包中包括所请求发送的数据。

可选的，所述处理模块还包括：

设置于网络层的IPv4/IPv6处理模块，用于根据所述请求数据包的IP头部协议类型字段确定所述请求数据包为采用Ipv4协议或Ipv6协议类型的TCP协议包，并将所述TCP协议包发送至所述TCP处理模块。

经由上述技术方案可知，本发明公开了一种数据处理方法及系统，通过预先构建Web应用服务器底层的数据平面开发工作集DPDK，调用DPDK提供的接口函数来接收客户端发送的请求数据包，确定请求数据包的请求类型，并基于请求数据包的请求类型对请求数据包进行处理，得到响应数据包，调用DPDK提供的发送函数发送响应数据包。基于DPDK对数据包进行处理，能够绕过Linux协议栈，直接接管网络数据包处理、内存管理和CPU调度，从而加快的数据包的处理速度。同时，在一些需要极高并发且业务逻辑简单的场景中，上述方法不需要保存客户端的连接状态，不需要维护进程和线程信息，这样能减少系统资源占用，从而极大地提高了Web服务器的并发量。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本发明实施例提供的一种应用数据在TCP/IP协议栈中封装的示意图；

图2为本发明实施例提供的一种数据包处理方法的流程图；

图3为本发明实施例提供的一种数据包处理方法的一具体示例图；

图4为本发明实施例提供的一种数据包处理方法实的一具体示例图；

图5为本发明实施例提供的一种数据包处理系统的结构框图；

图6为本发明实施例提供的一种数据包处理系统的结构框图；

图7为本发明实施例提供的一种数据包处理系统的结构框图；

图8为本发明实施例提供的一种基于DPDK的Web服务器的体系结构图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

在本申请中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

参考图1，示出了本发明实施例提供的一种应用数据在TCP/IP协议栈中封装的示意图。

需要说明的是，在TCP/IP四层模型中，由上至下分别是：应用层、传输层、网络层和链路层。每一层的协议都由相对的协议头部和数据部分组成。如果一台主机要通过网络传送数据，在TCP/IP协议栈中，从应用数据到组成链路层帧，需要经过以下步骤：

步骤S101：根据应用层协议添加对应的协议头(Header)，包装成应用层数据分组；

步骤S102：应用层数据分组再向下根据对应传输层协议添加传输层协议头，组成传输层的数据包，此时上层的应用层数据分组作为传输层的数据部分；

步骤S103：传输层数据包向下添加网络层协议头部，组成网络层数据包，此时上层的传输层数据包作为网络层的数据部分；

步骤S104：网络层数据包向下添加链路层协议头部，组成链路层帧，此时上层的网络层数据包作为链路层的数据部分。

通常情况下，应用数据的封装都遵循步骤S101至步骤S104，当然也有例外，比如TCP/IP协议栈中存在的一些控制协议，如ARP请求直接作为链路层帧的数据部分，和ICMP控制报文协议直接作为网络层数据包的数据部分。那么，TCP/IP协议栈就需要用到协议头部来判断某一层协议的数据部分的内容。

每一层的协议都由相应的协议头部和数据部分组成，链路层和网络层的协议头部具有数据部分的类型标识，也就是说，通过链路层和网络层的协议头部，可以判断对应数据部分的内容。比如，链路层的头部类型字段为‘0800’，则标识链路层数据部分为网络层数据包，如果类型字段为‘0806’，则表示链路层数据部分为ARP请求。

综上所述，在TCP/IP协议栈中，数据的封装过程是：数据经由应用层、传输层、链路层，一层层向下，上层内容作为下层内容协议的数据部分，并添加相应的协议头部，协议头部具有相应字段来标识数据部分的内容，组成链路层帧之后，通过物理链路传送到目标主机。

由背景技术可知，现有的大部分Web服务器虽然功能强大，但这些传统Web服务器大多都是应用在复杂业务场景中，而现有的Web服务器在处理一些需要极高并发量且业务逻辑简单的场景中会存在臃肿、并发量小和效率低下的问题。因此，本发明实施例公开了一种数据包处理方法及系统，以解决Web服务器在处理极高并发且业务逻辑简单的场景存在的臃肿、并发量小和效率低下的问题。

参考图2，示出了本发明实施例提供的一种数据包处理方法的流程图，可以包括以下步骤：

步骤S201，调用数据平面开发工作集(Data Plane Development Kit，DPDK)提供的第一接口函数接收客户端发送的请求数据包。

在具体实现步骤S201的过程中，所述DPDK为预先构建与Web应用服务器底层的DPDK，所述第一接口函数为rte_eth_rx_burst函数；

上述涉及预先构建DPDK的过程包括：

首先，基于所述DPDK的源码包在具有因特网(Intel)网卡的物理服务器上进行配置，并将所述DPDK与所述Intel网卡绑定，形成DPDK环境。

在具体实现上述过程中，可以使用DPDK源码包提供的脚本工具来构建DPDK环境，采用以下过程(1)至(2)进行说明：

(1)构建DPDK环境：

首先，编译源码包提供的脚本工具和加载模块，然后输入1024，查看网卡，最后输入空余的网卡名字并绑定网卡。如果输入的网卡名字还是启用状态，则需要先将网卡关闭，其具体做法是在构建过程中输入命令sudo ifconfig eth0dowm。

(2)编译源代码并运行

在所述DPDK环境下编译所述Web服务器的源代码并运行，得到构建与所述Web服务器底层的DPDK。

具体实现中的部分命令行如下：

source env_vars

make

sudo build/ipdesc-dpdk-cl-nl 172.16.1.132 80

在这里，ipdesc-dpdk为所述Web服务器的源代码，首先使用make命令编译源代码，然后在执行的时候指定所监听的IP地址和端口号，IP地址即DPDK所绑定的网卡的IP地址，而端口号即为HTTP协议的端口号80。

可选的，在构建好上述DPDK环境后，为了便于调试和演示，以Web服务器的功能为做1000以内的平方运算，并且使用Redis内存数据库作为数据层的存储方式为例，采用下述过程(1)至(3)进行说明：

(1)浏览器访问

在客户端浏览器访问Web服务器，访问路径为‘/888’，界面输出‘788544’，而788544正好是888的平方，则可知结果正确，基于DPDK的Web服务器可以正常工作。

此时Web服务器后台中输出了收到的数据包的详细信息，从输出的信息可以看到该HTTP请求的完整包格式，同时也可以看到其十六进制的包数据。

(2)抓包

通过DPDK提供的抓包工具dpdk-pdump来抓包。需要说明的是，在本发明实施例中由于网卡被DPDK绑定，不归操作系统管理，这里不能使用常规的抓包工具进行抓包。比如利用wireshark等工具抓包。在本发明实施例中执行调试和演示的命令行中，分别通过rx-dev参数和tx-dev参数指定DPDK收到的数据包，以及发出的数据包所存放的文件。

(3)抓包结果

在Web服务器运行的过程中，通过DPDK提供的抓包工具dpdk-pdump抓取了DPDK交互的数据包，并将收到的数据包和发出的数据包分别存入rx.pcap文件和tx.pcap文件。此时可以用wireshark打开这两个文件查看详细的抓包结果。需要说明的是，DPDK交互的数据包是本发明实施例中提及的Web服务器与客户端交互的数据包。

步骤S202：确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包。

在具体实现步骤S202的过程中，所述请求数据包的请求类型包括：链路层类型的ARP协议包、网络层协议类型的ICMP协议包和传输层协议类型的TCP协议包。

可选的，根据所述TCP协议包的头部标志位字段确定所述TCP协议包的请求类型还包括：握手请求、挥手请求和发送数据请求。

步骤S203：调用所述DPDK提供的第二接口函数向客户端发送所述响应数据包。

在具体实现步骤S203的过程中，可选的，该所述第二接口函数可以为‘rte_eth_tx_burst’函数。

本发明实施例中通过使用基于DPDK的Web服务器对数据包处理，让应用程序直接接管网络数据包处理、内存管理和CPU调度，这样能在处理数据包时绕过了Linux协议栈，从而加快的数据包的处理速度。同时，在一些需要极高并发且业务逻辑简单的场景中，上述方法不需要保存客户端的连接状态，不需要维护进程和线程信息，这样能减少系统资源占用，从而极大地提高了Web服务器的并发量。

可选的，基于上述本发明实施例公开的一种数据包处理方法，结合图2，在执行步骤S201至S203过程中，记录日志信息，记录客户端收到的数据包，记录客户端发送的查询内容以及记录Web服务器查询出来的响应结果等信息。

根据上述本发明实施例图2公开的一种数据包处理的方法，在TCP/IP四层模型中生成数据包的过程中，根据所述TCP/IP四层模型携带的协议头部字段的内容，执行步骤S202确定所述请求数据包的请求类型。并基于所述请求类型对所述请求数据包进行处理，得到响应数据包。具体处理所述请求数据包的过程参见以下详细说明。

参考图3，示出了本发明实施例提供的一种确定请求数据包的请求类型和得到响应数据包的流程图，包括以下步骤：

步骤S301：基于协议头部类型字段判断所述请求数据包为链路层协议类型的ARP协议包，如果是，则执行步骤S302，如果否，则执行步骤S304。

步骤S302：判断所述ARP协议包请求的IP地址是否为所述Web服务器的IP地址，如果是，则执行步骤S303，如果否，则继续传输所述ARP协议包。

步骤S303：生成RARP响应数据包，执行步骤S308。

具体实现步骤S303的过程中，得到RARP响应数据包的具体操作方法是：

将ARP请求包链路层的源物理地址(Media Access Control，MAC)地址拷贝到其链路层目的MAC地址，将Web服务器自己的MAC地址拷贝到链路层的源MAC地址，将ARP包的OP字段设置成ARP应答，即OP字段为2。由于ARP包中也有一个目的MAC地址和源MAC地址，因此将这两个MAC地址也按照链路层一样的模式填充，将ARP请求包中的源IP地址拷贝到其目的IP地址，将Web服务器自己的IP地址拷贝到源IP地址。通过上述步骤能够构造出了一个完整的RARP响应数据包。

步骤S304：去掉所述请求数据包的链路层协议头部，将所述请求数据包传输到网络层进行处理。

步骤S305：基于头部协议类型字段判断所述请求数据包是否为网络层协议类型的ICM协议包，如果是，则执行步骤S306，如果否，则执行步骤S309。

步骤S306：基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包，如果是，则执行步骤S307，如果否，则继续传输所述ICMP协议包。

步骤S307：对回显应答包进行处理，将所述回显应答包作为响应数据包。

具体实现步骤S307的过程中，对所述回显应答包进行处理的具体过程为：

将所述ICMP协议包链路层的源MAC地址拷贝到其链路层目的MAC地址，将Web服务器自己的MAC地址拷贝到链路层的源MAC地址，将IP层目的IP地址设置为所述ICMP协议包的源IP地址。将IP层源IP地址设置为Web服务器自己的IP地址，设置IP层的TTL字段以及设置IP层的校验和，将ICMP的类型字段设置为回显应答字段，即TYPE字段为0，设置ICMP校验和。按照上述步骤可构造出一个完整的ICMP回显应答包。

步骤S308：调用所述DPDK提供的第二接口函数向客户端发送响应数据包。

步骤S309：去掉所述请求数据包的网络层协议头部，将得到的所述请求数据包传输给传输层处理。

经由图3所述步骤S309处理所述请求数据包之后，参考图4，示出了本发明实施例中如何确定请求数据包的请求类型，和得到所述响应数据包的过程，所述过程包括：

步骤S401：基于协议头部类型字段判断所述请求数据包为传输层协议类型的TCP协议包，如果是，则执行步骤S402，如果否，则继续传输所述TCP协议包。

步骤S402：判断所述TCP协议包是否采用Ipv4或Ipv6协议，如果是，则执行步骤S403，如果否，则继续传输所述TCP协议包。

在具体实现步骤S402的过程中，所述Ipv4协议是互联网协议(InternetProtocol，IP)的第四版，是现有互联网技术的基础协议，IPv6协议是用于替代现行版本Ipv4协议的新一代互联网协议。

步骤S403：判断所述TCP协议包头部标志位字段，如果所述头部标志位字段为SYN，则执行步骤S404。如果所述头部标志位字段为FIN，则执行步骤S405。如果所述头部标志位字段为ACK，则执行步骤S406。

在具体实现步骤S403的过程中，TCP协议包的头部标志位字段包括SYN、FIN和ACK，需要说明的是，所述SYN是同步标志，所述ACK是确认标志，所述FIN是结束标志。

步骤S404：确定所述TCP协议包的请求类型为握手请求并生成标志位为SYN和ACK的响应数据包，执行步骤S410。

具体实现步骤S404的过程中，生成标志位为SYN和ACK的响应数据包的具体过程为：

交换链路层头部的目的MAC地址和源MAC地址，交换IP网络层头部的目的IP地址和源IP地址，交换TCP头部的目的端口和源端口。将TCP头部标志位设置为SYN和ACK，设置TCP确认号ack为握手请求包的序列号加1，设置TCP序列号为一个随机数，设置TCP头部长度字段，设置TCP头部校验和，设置IP头部总长度字段，设置IP头部校验和，设置IP头部TTL字段。经过上述步骤，即可构造出一个完整标志位为SYN何ACK的响应数据包。

步骤S405：确定所述TCP协议包的请求类型为挥手请求，并生成标志位为ACK的响应数据包，执行步骤S410。

具体实现步骤S405的过程中，生成标志位为ACK的响应数据包的过程为：

交换链路层头部的目的MAC地址和源MAC地址，交换IP网络层头部的目的IP地址和源IP地址，交换TCP头部的目的端口和源端口，交换TCP头部的序列号和确认号。并且将TCP头部确认号加1，将TCP头部标志位设置为ACK。设置TCP头部长度字段，设置TCP头部校验和，设置IP头部总长度字段，设置IP头部校验和，设置IP头部TTL字段。经过上述步骤，即可构造出对于FIN请求的ACK响应数据包。

步骤S406：确定所述TCP协议包的请求类型为发送数据请求，解析所述TCP协议包获取HTTP协议数据包。

步骤S407：在应用层解析所述HTTP协议数据包，得到HTTP请求。

步骤S408：调用数据层中与所述HTTP请求相对应的数据，并封装得到HTTP响应包。

步骤S409：处理所述HTTP响应包，生成包含所请求发送的数据的响应数据包，所述HTTP响应包中包括所请求发送的数据，执行步骤S410。

具体实现步骤S409的过程中，得到所请求发送的数据的响应数据包的过程为：

交换链路层头部的目的MAC地址和源MAC地址，交换IP网络层头部的目的IP地址和源IP地址，交换TCP头部的目的端口和源端口。设置TCP头部标志位为ACK、PSH和FIN，设置TCP头部序列号为收到的请求包的确认号，设置确认号为请求包的序列号加请求包TCP数据部分的长度，设置TCP头部校验和，设置IP头部校验和，设置IP头部TTL字段，设置IP头部总长度字段。经过上述步骤，即可得到一个完整的数据响应包。

步骤S410：调用所述DPDK提供的第二接口函数向客户端发送所述响应数据包。

本发明实施例中，Web服务器采用轮询的方式，不断调用DPDK提供的接收数据包的接口来获取数据包，对每一个数据进行判断和处理，绕过了Linux协议栈，增加了数据包处理速度。同时，基于DPDK的Web服务器能全面支持Ipv6，使得Web服务器的访问不再局限于Ipv4。

与上述本发明实施例提供的一种数据包处理方法相对应，参考图5，本发明实施例还提供了一种数据包处理系统。在本发明该实施例中，该数据包处理系统可以包括：预设模块501、调用模块502、接收模块503和处理模块504。其中：

预设模块501，用于构建Web服务器底层的DPDK。

调用模块502，用于调用DPDK提供的第一接口函数‘rte_eth_rx_burst’函数，以及，调用所述DPDK提供的第二接口函数‘rte_eth_tx_burst’函数向客户端发送响应数据包。

接收模块503，用于基于所述第一接口函数接收客户端发送的请求数据包。

处理模块504，用于确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到所述响应数据包并将所述响应数据包传输给所述调用模块502，由所述第二接口函数向客户端发送所述响应数据包。

应用本发明实施例提供的数据包处理系统，在处理一些高并发且业务逻辑简单的场景时，使用基于DPDK技术的Web服务器对客户端发送的请求数据包进行处理，可以加快数据包的处理流程和提高Web服务器的并发量。

优选的，结合图5，参考图6，本发明实施例中所述的数据包处理系统中处理模块504包括：设置于网络层的ARP处理模块505；

设置于网络层的ARP处理模块505，用于基于协议头部类型字段判断所述请求数据包为链路层协议类型的ARP协议包。判断所述APR协议包请求的IP地址是否为Web服务器的IP地址，若是，则对所述ARP协议包进行处理，将得到的RARP数据包作为响应数据包，其具体操作参见上述本发明实施例图3公开的步骤S303相对应的内容。

优选的，结合图5，参考图6，本发明实施例中所述的数据包处理系统中，处理模块504包括：设置于网络层的ICMP处理模块506；

设置于网络层的ICMP处理模块506用于基于协议头部类型字段确定所述请求数据包为所述网络层协议类型的ICMP协议包。基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包，若是，则对所述ICMP请求数据包进行处理，将得到的回显应答包作为响应数据包，其具体操作可参见上述本发明实施例图3公开的步骤S307的相对应的内容。

优选的，结合图5，参考图6，本发明实施例中所述的数据包处理系统中，处理模块504包括：设置于传输层中的TCP处理模块507；

设置于传输层中的TCP处理模块507用于确定所述请求数据包为传输层协议类型的TCP协议包，并判断所述TCP协议包是否采用Ipv4或Ipv6协议，若是，根据所述TCP协议包的头部标志位字段确定所述TCP协议包的请求类型；

若所述头部标志位字段为SYN，确定所述TCP协议包的请求类型为握手请求，生成标志位SYN和ACK的响应数据包，其具体操作可参见上述本发明实施例图4公开的步骤S404相对应的内容。

若所述头部标志位字段为FIN，确定所述TCP协议包的请求类型为挥手请求，生成标志位为ACK的响应数据包，其具体操作可参见上述本发明实施例图4公开的步骤S405相对应的内容。

若所述头部标志位字段为ACK，确定所述TCP协议包的请求类型为发送数据请求。解析所述TCP协议包，获取HTTP协议数据包，将所述HTTP协议数据发送至HTTP处理模块，对接收到的HTTP响应包进行处理，生成包含所请求发送的数据的响应数据包。其具体操作可参见上述本发明实施例图4公开的步骤S409相对应的内容。

优选的，结合图5，参考图6，本发明实施例中所述的数据包处理系统中处理模块504包括：设置于应用层的HTTP处理模块508；

设置于应用层的HTTP处理模块508用于解析所述HTTP协议数据包，得到HTTP请求，调用数据层中所述HTTP请求相对应的数据并封装，得到HTTP响应包，所述HTTP响应数据包中包含所请求发送的数据。其具体操作流程为：解析客户端的HTTP请求，获取所述HTTP请求路径，根据所述请求路径获取客户端的请求内容。根据所述请求内容调用数据层接口获得相对应的数据，将所述相对应的数据封装进HTTP响应体，连同构造好的HTTP状态行和响应头，构造出完整的HTTP响应包。

优选的，结合图5，参考图6，本发明实施例中所述的数据包处理系统中处理模块504包括：设置于网络层的Ipv4/Ipv6处理模块509；

设置于网络层的Ipv4/Ipv6处理模块509用于根据所述请求数据包的IP头部协议类型字段确定所述请求数据包为采用Ipv4协议或Ipv6协议类型的TCP协议包，并将所述TCP协议包发送至所述设置于传输层中的TCP处理模块607。

与上述本发明提供的一种数据包处理系统实施例相对应，结合图6，参考图7，本发明实施例还提供了一种数据包处理系统的优选实施例，在本发明实施例中，该系统可以包括：

横跨网络层到数据层的日志记录模块510；

日志记录模块510，用于记录日志信息，记录收到的数据包，记录客户端发送的查询内容以及记录Web服务器查询出来的响应结果等信息，同时，日志记录模块510也可用于调试。

在具体实现中，基于上述本发明实施例公开的数据包处理方法及系统，构建的基于DPDK的Web服务器的体系结构图，如图8所示。该基于DPDK的Web服务器的体系包括：底层的DPDK，设置于网络层801的ARP、ICMP、ICMPv6、IPv4和IPv6等处理模块，设置于传输层802的TCP和TCPv6等处理模块，设置于应用层803的HTTP等处理模块，设置于数据层804的内存数据库8041和文件存储单元8042等存储模块，以及横跨网络层801、传输层802、应用层803和数据层804的日志记录模块805。

需要说明的是，图8所示出的各个处理模块以及日志记录模块的具体实现原理和过程，与图5-图7中公开的相应模块的执行原理和过程相同，可参见，这里不再进行赘述。

综上所述，本发明实施例提供的上述数据包处理方法及系统，通过预先构建Web应用服务器底层的数据平面开发工作集DPDK，调用DPDK提供的接口函数来接收客户端发送的请求数据包，确定请求数据包的请求类型，并基于请求数据包的请求类型对请求数据包进行处理，得到响应数据包，调用DPDK提供的发送函数发送响应数据包。基于DPDK对数据包进行处理，加快了数据包的处理速度和极大增加了Web服务器的并发量，同时，在一些需要极高并发且业务逻辑简单的场景中，上述方法不需要保存客户端的连接状态，不需要维护进程和线程信息，这样能减少系统资源占用，从而极大地提高了Web服务器的并发量。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。

Claims (10)

1.一种数据包处理方法，其特征在于，应用于万维网web服务器，所述web服务器用于处理网络层、传输层和应用层的请求数据包，所述方法包括：

调用数据平面开发工作集DPDK提供的第一接口函数，所述DPDK为预先构建于web应用服务器底层的DPDK，所述第一接口函数为rte_eth_rx_burst函数；

基于所述第一接口函数接收客户端发送的请求数据包；

确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包；

调用所述DPDK提供的第二接口函数向所述客户端发送所述响应数据包，所述第二接口函数为rte_eth_tx_burst函数。

2.根据权利要求1所述的方法，其特征在于，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

基于协议头部类型字段确定所述请求数据包为链路层协议类型的ARP协议包；

则生成反向地址转换协议RARP响应数据包。

3.根据权利要求1所述的方法，其特征在于，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

基于协议头部类型字段确定所述请求数据包为网络层协议类型的ICMP协议包；或者，基于协议头部类型字段确定所述请求数据包为Ipv6协议类型的ICMP协议包；

基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包；

若是，则对所述ICMP请求数据包进行处理，将得到的回显应答包作为响应数据包。

4.根据权利要求1所述的方法，其特征在于，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

基于协议头部类型字段确定所述请求数据包为传输层协议类型的TCP协议包；

根据所述TCP协议包的头部标志位字段确定所述TCP协议包的请求类型；

若所述头部标志位字段为SYN，确定所述TCP协议包的请求类型为握手请求；

生成标志位为SYN和ACK的响应数据包；

若所述头部标志位字段为FIN，确定所述TCP协议包的请求类型为挥手请求；

生成标志位为ACK的响应数据包；

若所述头部标志位字段为ACK，确定所述TCP协议包的请求类型为发送数据请求；

解析所述TCP协议包，获取HTTP协议数据包；

在应用层解析所述HTTP协议数据包，得到HTTP请求；

调用数据层中与所述HTTP请求相对应的数据，并封装，得到HTTP响应包；

对所述HTTP响应包进行处理，生成包含所请求发送的数据的响应数据包，所述HTTP响应包中包括所请求发送的数据。

5.根据权利要求4所述的方法，其特征在于，所述确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到响应数据包，包括：

根据所述请求数据包的IP头部协议类型字段确定所述请求数据包为采用Ipv4协议或Ipv6协议类型的TCP协议包；

执行根据所述TCP协议包的头部标志位字段确定所述协议包的请求类型这一步骤。

6.一种数据包处理系统，其特征在于，应用于万维网web服务器，所述web服务器用于处理网络层、传输层和应用层的请求数据包，所述方法包括：

调用模块，用于调用数据平面开发工作集DPDK提供的第一接口函数，以及，调用所述DPDK提供的第二接口函数发送响应数据包，所述DPDK为预先构建于web应用服务器底层的DPDK，所述第一接口函数为rte_eth_rx_burst函数，所述第二接口函数为rte_eth_tx_burst函数；

接收模块，用于基于所述第一接口函数接收客户端发送的请求数据包；

处理模块，用于确定所述请求数据包的请求类型，并基于所述请求数据包的请求类型对所述请求数据包进行处理，得到所述响应数据包。

7.根据权利要求6所述的系统，其特征在于，所述处理模块包括：

设置于网络层的ARP处理模块，用于基于协议头部类型字段确定所述请求数据包为链路层协议类型的ARP协议包，则生成RARP响应数据包。

8.根据权利要求6所述的系统，其特征在于，所述处理模块包括：

设置于网络层的ICMP处理模块，用于基于协议头部类型字段确定所述请求数据包为所述网络层协议类型的ICMP协议包，基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包，若是，则对所述ICMP请求数据包进行处理，将得到的回显应答包作为响应数据包；和/或，

设置于网络层的ICMPv6处理模块，用于处理Ipv6协议类型的ICMP协议包，基于所述ICMP协议包的类型字段和代码字段判断所述ICMP协议包是否为回显请求包，若是，则对所述ICMP请求数据包进行处理，将得到的回显应答包作为响应数据包。

9.根据权利要求6所述的系统，其特征在于，所述处理模块包括：

设置于传输层的TCP处理模块，用于确定所述请求数据包为传输层协议类型的TCP协议包，根据所述TCP协议包的头部标志位字段确定所述TCP协议包的请求类型，若所述头部标志位字段为SYN，确定所述TCP协议包的请求类型为握手请求，生成标志位为SYN和ACK的响应数据包；若所述头部标志位字段为FIN，确定所述TCP协议包的请求类型为挥手请求，生成标志位为ACK的响应数据包；若所述头部标志位字段为ACK，确定所述TCP协议包的请求类型为发送数据请求，解析所述TCP协议包，获取HTTP协议数据包，将所述HTTP协议数据包发送至HTTP处理模块，以及对接收到的HTTP响应包进行处理，生成包含所请求发送的数据的响应数据包；

设置于应用层的HTTP处理模块，用于解析所述HTTP协议数据包，得到HTTP请求，调用数据层中与所述HTTP请求相对应的数据，并封装，得到HTTP响应包，所述HTTP响应包中包括所请求发送的数据。

10.根据权利要求8所述的系统，其特征在于，所述处理模块还包括：

设置于网络层的IPv4/IPv6处理模块，用于根据所述请求数据包的IP头部协议类型字段确定所述请求数据包为采用Ipv4协议或Ipv6协议类型的TCP协议包，并将所述TCP协议包发送至所述TCP处理模块。