CN115834722A - 一种数据处理方法、装置、网元设备以及可读存储介质 - Google Patents

Abstract

本申请实施例提供了一种数据处理方法、装置、网元设备以及可读存储介质，该方法包括：在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；若数据报文集合中存在内核数据报文，则在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理；若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的一个或多个报文处理节点，通过一个或多个报文处理节点对业务数据报文进行流转处理。采用本申请，可以实现在用户态对数据报文集合中的数据报文进行流转处理，进而提高网元设备对数据报文的处理能力。

Description

一种数据处理方法、装置、网元设备以及可读存储介质

技术领域

本申请涉及通信技术领域，尤其涉及一种数据处理方法、装置、网元设备以及可读存储介质。

背景技术

目前网元设备(例如，网关)在接收到数据报文时，需要在内核态对数据报文进行流转处理，并在对数据报文进行流转处理后，由内核态切换到用户态。当网关接收到大量数据报文时，网关的频繁切换(即内核态空间和用户态空间之间的频繁切换)，以及数据在内核态空间和用户态空间的相互拷贝会产生较大的时间开销和性能开销，进而限制了网关对数据报文的处理能力。

发明内容

本申请实施例提供一种数据处理方法、装置、网元设备以及可读存储介质，可以提高网元设备对数据报文的处理能力。

本申请实施例一方面提供了一种数据处理方法，包括：

在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；同一个数据报文集合中的数据报文具有相同的报文格式；

若数据报文集合中存在内核数据报文，则在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理；

若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的一个或多个报文处理节点，通过一个或多个报文处理节点对业务数据报文进行流转处理。

本申请实施例一方面提供了一种数据处理装置，包括：

集合生成模块，用于在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；同一个数据报文集合中的数据报文具有相同的报文格式；

第一处理模块，用于若数据报文集合中存在内核数据报文，则在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理；

第二处理模块，用于若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的一个或多个报文处理节点，通过一个或多个报文处理节点对业务数据报文进行流转处理。

其中，集合生成模块包括：

格式识别单元，用于在用户态下的工作线程中，对工作线程对应的缓冲接收队列进行轮询，识别轮询得到的数据报文的报文格式；报文格式包括目标报文格式；

集合生成单元，用于若具有目标报文格式的数据报文的报文数量大于或等于数量阈值，则基于具有目标报文格式的数据报文，生成目标报文格式对应的数据报文集合。

其中，访问控制规则包括属于访问控制列表中的内核报文匹配规则和业务报文匹配规则；

装置还包括：

规则匹配模块，用于将数据报文集合发送至工作线程中的访问控制节点，在访问控制节点中，基于访问控制列表对数据报文集合中的数据报文进行匹配；

第一匹配模块，用于若数据报文集合中存在与内核报文匹配规则相匹配的数据报文，则确定数据报文集合中存在内核数据报文；

第二匹配模块，用于若数据报文集合中存在与业务报文匹配规则相匹配的数据报文，则确定数据报文集合中存在业务数据报文。

其中，规则匹配模块包括：

报文检测单元，用于将数据报文集合中的数据报文加载至数据缓存，在数据缓存中依次对数据报文集合中的数据报文进行报文检测；

第一发送单元，用于若报文检测出数据报文集合中存在检验成功的数据报文，则将检验成功的数据报文发送至工作线程中的访问控制节点；

则规则匹配模块还包括：

第二发送单元，用于若报文检测出数据报文集合中存在检验失败的数据报文，则将检验失败的数据报文发送至失败处理节点。

其中，报文检测单元包括：

报文加载子单元，用于将数据报文集合中的数据报文加载至数据缓存，从数据缓存中获取数据报文集合的数据报文S_i；i为小于或等于数据报文集合中的数据报文的报文数量的正整数；

第一检测子单元，用于获取数据报文S_i对应的报文处理指令，将报文处理指令加载至指令缓存，通过指令缓存中的报文处理指令对数据报文S_i进行报文检测；

第二检测子单元，用于从数据缓存中获取数据报文集合的数据报文S_i+1，从指令缓存中获取报文处理指令，通过报文处理指令对数据报文S_i+1进行报文检测。

其中，一个或多个报文处理节点包括路由匹配节点；

第二处理模块包括：

报文分流单元，用于若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的路由匹配节点；

路由匹配单元，用于通过路由匹配节点对业务数据报文携带的目的地址进行路由匹配，得到业务数据报文对应的路由数据报文；

报文解析单元，用于对路由数据报文进行报文协议解析。

其中，一个或多个报文处理节点还包括第一报文解析节点和第二报文解析节点；

报文解析单元包括：

协议识别子单元，用于识别与路由数据报文相关联的报文协议类型；

第一解析子单元，用于若报文协议类型为通用路由封装协议类型，则将路由数据报文发送至第一报文解析节点，通过第一报文解析节点对路由数据报文进行报文协议解析；

第二解析子单元，用于若报文协议类型为虚拟扩展局域网协议类型，则将路由数据报文发送至第二报文解析节点，通过第二报文解析节点对路由数据报文进行报文协议解析。

其中，一个或多个报文处理节点还包括策略节点和隧道处理节点；

第二处理模块还包括：

策略控制单元，用于获取经过报文协议解析所得到的解析数据报文，将解析数据报文发送至策略节点，通过策略节点对解析数据报文进行策略控制，得到策略控制后的解析数据报文；

隧道处理单元，用于将策略控制后的解析数据报文发送至隧道处理节点，通过隧道处理节点对策略控制后的解析数据报文进行隧道处理，得到加密数据报文；

报文发送单元，用于将加密数据报文发送至网卡组件对应的网卡发送队列。

其中，报文发送单元，具体用于通过隧道处理节点将加密数据报文添加至工作线程对应的缓冲发送队列；

报文发送单元，还具体用于通过网卡组件获取缓冲发送队列中的加密数据报文，将网卡组件所获取到的加密数据报文存放至网卡组件对应的网卡发送队列。

其中，装置还包括：

报文存放模块，用于通过网卡组件获取数据报文，将网卡组件所获取到的数据报文存放至网卡组件对应的网卡接收队列；

拦截中断模块，用于通过网卡组件对网卡接收队列中的数据报文进行拦截中断处理，将拦截中断处理后的数据报文均衡分配至缓冲接收队列。

其中，工作线程的线程数量为至少两个，至少两个工作线程中的每个工作线程对应于一个缓冲接收队列；

拦截中断模块，具体用于通过网卡组件对网卡接收队列中的数据报文进行拦截中断处理，为拦截中断处理后的数据报文生成报文标识；

拦截中断模块，还具体用于根据报文标识，将拦截中断处理后的数据报文均衡分配至至少两个工作线程分别对应的缓冲接收队列。

本申请实施例一方面提供了一种网元设备，包括：处理器、存储器、网络接口；

上述处理器与上述存储器、上述网络接口相连，其中，上述网络接口用于提供数据通信网元，上述存储器用于存储计算机程序，上述处理器用于调用上述计算机程序，以使网元设备执行本申请实施例中的方法。

本申请实施例一方面提供了一种计算机可读存储介质，上述计算机可读存储介质中存储有计算机程序，上述计算机程序适于由处理器加载并执行本申请实施例中的方法。

本申请实施例一方面提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中，网元设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该网元设备执行本申请实施例中的方法。

在本申请实施例中，网元设备可以在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合。其中，同一个数据报文集合中的数据报文具有相同的报文格式。可以理解的是，若数据报文集合中存在内核数据报文，则网元设备可以在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理。若数据报文集合中存在业务数据报文，则网元设备可以在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的一个或多个报文处理节点，通过一个或多个报文处理节点对业务数据报文进行流转处理。由此可见，网元设备可以直接在用户态下的工作线程中，将接收到的多个数据报文封装成数据报文集合，进而一次性对数据报文集合中的数据报文进行流转处理。可以理解的是，由于数据报文集合中的数据报文具有相同的报文格式，在通过工作线程对这些数据报文进行流转处理时，可以提高指令缓存的缓存命中率。此外，本申请实施例中的网元设备可以同时兼容业务数据报文和内核数据报文，且在用户态实现对业务数据报文的流转处理，从而减少上下文频繁切换和数据在用户态和内核态之间的相互拷贝，进而可以提高网元设备对数据报文的处理能力。

附图说明

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

图1是本申请实施例提供的一种网络架构的结构示意图；

图2是本申请实施例提供的一种进行数据交互的场景示意图；

图3是本申请实施例提供的一种数据处理方法的流程示意图；

图4是本申请实施例提供的一种进行报文处理的流程示意图；

图5是本申请实施例提供的一种数据处理方法的流程示意图；

图6是本申请实施例提供的一种数据处理方法的流程示意图；

图7是本申请实施例提供的一种进行报文处理的结构示意图；

图8a是本申请实施例提供的一种进行用户态报文流水线处理的流程示意图；

图8b是本申请实施例提供的一种进行用户态报文流水线处理的流程示意图；

图9是本申请实施例提供的一种数据处理装置的结构示意图；

图10是本申请实施例提供的一种网元设备的结构示意图。

具体实施方式

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

具体的，请参见图1，图1是本申请实施例提供的一种网络架构的结构示意图。如图1所示，该网络架构可以包括应用服务器集群、基站4000a、网关4000b以及用户设备集群。其中，应用服务器集群具体可以包括一个或者多个应用服务器，这里将不对应用服务器集群中的应用服务器的数量进行限定。如图1所示，多个应用服务器具体可以包括应用服务器2000a、应用服务器2000b、…、应用服务器2000n，应用服务器2000a、应用服务器2000b、…、应用服务器2000n可以分别与网关4000b进行专线连接，以便于每个应用服务器可以通过该专线连接与网关4000b之间进行数据交互。

可以理解的是，应用服务器集群中的应用服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云数据库、云服务、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器。

可以理解的是，上述网络架构可以应用于支持边缘计算(即移动边缘计算，MobileEdge Computing，简称MEC)的业务场景中，上述应用服务器集群中的应用服务器可以为边缘计算中的边缘应用服务器。边缘计算是指在靠近物或数据源头的网络边缘侧，融合网络、计算存储、应用核心能力的平台，就近提供边缘智能服务，满足行业数字化在敏捷联接、实时业务、数据优化、应用智能安全与隐私保护等方面的关键需求。边缘计算使运营商和第三方服务能够靠近终端设备的接入点进行托管，从而通过减少传输网络上的端到端延迟和负载来实现高效的服务交付。

可以理解的是，上述网络架构可以应用于第五代移动通信技术(5th GenerationMobile Networks，第五代移动通信技术，简称5G)，5G是具有高速率、低时延和大连接特点的新一代宽带移动通信技术，是实现人机物互联的网络基础设施。在5G的应用场景中，5G业务的峰值速率通常超过10Gbps，带宽的要求则高达几十Gbps，故此，会对无线中传、回传移动网络造成巨大的压力。因此，5G业务需求需要将业务尽可能下沉至网络边缘，以实现业务的本地分流，且减少网络传输和多级业务转发带来的网络时延。

其中，用户设备集群具体可以包括一个或者多个用户设备(User Equipment，简称UE)，这里将不对用户设备集群中的用户设备的数量进行限定。如图1所示，多个用户设备具体可以包括用户设备3000a、用户设备3000b、…、用户设备3000m，用户设备3000a、用户设备3000b、…、用户设备3000m可以分别与基站4000a通过5G传输方式进行通信连接，以便于每个用户设备可以通过该通信连接与基站4000a之间进行数据交互。

可以理解的是，用户设备集群中的用户设备可以包括民用、商用、工业、军工等领域的终端应用产品，如智能手机、平板电脑、笔记本电脑、掌上电脑、移动互联网设备(mobile internet device，MID)、可穿戴设备(例如智能手表、智能手环等)、智能电脑、智能车载、智能家居、无人机、ATM机、摄像头、红绿灯、发电机或各类型的传感器等。应当理解，如图1所示的用户设备集群中的每个用户设备均可以集成安装有应用客户端(即应用程序)，当该应用客户端运行于各用户设备中时，可以通过基站4000a和网关4000b分别与上述图1所示的应用服务器集群中的应用服务器之间进行数据交互。其中，应用客户端具体可以包括：车载客户端、智能家居客户端、娱乐客户端(例如，游戏客户端)、多媒体客户端(例如，视频客户端)、社交客户端以及资讯类客户端(例如，新闻客户端)等。

其中，基站4000a所对应的基站的数量可以为多个，多个基站可以负责用户设备在无线侧的接入与管理，不同的用户设备可以对应于不同的基站，不同的用户设备也可以对应于相同的基站，这里不对每个用户设备所对应的基站进行限定，本申请实施例以每个用户设备所对应的基站均为基站4000a为例进行说明。

其中，网关4000b可以为5G核心网(5G Core，可简称为5GC)中的核心网网元(“网元”也可称为“网络功能”)，这里的网关4000b可以为核心网网元中的UPF(User PlaneFunction，用户平面功能)，5GUPF可以负责控制面(即控制平面，Control Plane，简称CP)和用户面(即数据平面，Data Plane，简称DP)的数据路由和转发，并与外部数据网络(DataNetwork)互连，例如，运营商业务、互联网或者第三方业务等。可以理解的是，网关4000b和基站4000a之间可以实现内网连接(即网关4000b和基站4000a可以在同一局域网内进行网络连接)。

可以理解的是，基站4000a可以在用户设备(例如，用户设备3000a)和网关4000b之间建立“控制面”连接(即控制平面)，该控制平面可以用于在两者之间转发信令消息(即通信系统中的控制指令)，这些信令消息包括手机身份验证、注册、移动性管理等；基站可以在用户设备3000a和网关4000b之间建立“用户面”连接(即数据平面)，该数据平面可以用于在两者之间转发用户的数据流量。其中，控制面和用户面彻底分离，网关4000b可以与边缘计算一起分布式部署于更接近用户侧的边缘，从而可降低网络时延。

其中，控制平面可以用于传输业务报文(即业务数据报文)，数据平面可以用于传输内核报文(即内核数据报文)和部分业务数据报文，例如，这里的部分业务数据报文可以为健康监测的ping报文。其中，业务数据报文可以为上述信令消息和部分数据流量，内核数据报文可以为除部分数据流量之外的其他数据流量。

应当理解，在5G网络下，假设某个用户设备(例如，用户设备3000a)希望访问移动通信网外部的数据网络，该用户设备3000a可以发起访问请求，将该访问请求转发至基站4000a，基站4000a可以将用户设备3000a请求的业务流转发至5G核心网中的核心网网元UPF，再通过核心网网元UPF转发后，发送到外部数据网络。

其中，为了获得更高效的服务交付，可以采用边缘计算来满足不同的业务需求。需要说明的是，在边缘计算场景下，一个应用服务可能由通常部署在不同站点的多个边缘应用服务器(例如，图1所示应用服务器2000a、应用服务器2000b、…、应用服务器2000n)提供服务。要想把某个应用客户端(例如，应用客户端Y)的业务流路由到边缘应用服务器，终端设备需要知道为该应用客户端Y提供服务的边缘应用服务器的IP地址(Internet ProtocolAddress)，用户设备可以进行发现以获取合适的边缘应用服务器(比如，离用户设备最近的一个边缘应用服务器(例如，应用服务器2000a))的IP地址，以便流量可以被核心网网元UPF路由到该边缘应用服务器，并且可以优化服务延迟、流量路由路径和用户服务体验。基于此，边缘应用服务器发现是用户设备使用域名系统查找合适的边缘应用服务器的IP地址的过程。其中，域名系统(DNS，Domain Name Server)是互联网的一项服务，它作为将域名和IP地址相互映射的一个分布式数据库，能够使用户更方便地访问互联网。

应当理解，随着通信技术不断发展，涌现出很多之前不存在的需求，对于不方便施工布线且对网络质量有要求的旧城区、博物馆、矿厂机器人远程控制等场景，5G上云是个很好的解决方案，通过端侧接入5G以及云端的专线能力，能够大幅提高网络质量和传输速率，满足业务低时延与高可靠的网络要求。其中，5G上云表示用户设备可以通过5G网络将本地数据上传到云端的应用服务器，或是用户设备可以通过5G网络从云端的应用服务器中下载之前上传的本地数据。

其中，如果5G核心网UPF处理能力不足会导致丢包，产生较大时延，影响业务的平稳运行。因此，5G上云主要解决的产品是让5G核心网UPF能够快速处理数据报文，满足5G峰值10-20Gbit/s传输速率，空中接口(即无线网络(即基站)与用户设备的接口)1ms(即1毫秒)的时延特性。

应当理解，5G核心网UPF主要包括控制平面和数据平面两方面进行优化。控制平面可以用于传输业务数据报文，数据平面可以用于传输业务数据报文和内核数据报文。其中，本申请实施例所优化后的UPF让业务数据报文可以在用户态进行处理，即通过用户态下的工作线程(即用户态线程)对业务数据报文进行流转处理；优化后的UPF同时兼容让内核数据报文可以在内核态进行处理，即通过内核态线程对内核数据报文进行流转处理。

应当理解，5G核心网UPF中的工作线程可以为用户态线程，也可以为内核态线程，本申请实施例以工作线程为用户态线程为例进行说明。

为便于理解，进一步地，请参见图2，图2是本申请实施例提供的一种进行数据交互的场景示意图。如图2所示的用户设备20a可以为上述图1所对应实施例中的用户设备集群中的任意一个用户设备，如图2所示的应用服务器20c可以为上述图1所对应实施例中的应用服务器集群中的任意一个应用服务器，如图2所示的网关20b可以为上述图1所对应实施例中的网关4000b。为便于理解，本申请实施例以上述图1所示的用户设备3000a作为该用户设备20a、以上述图1所示的应用服务器2000a作为该应用服务器20c为例，以阐述图2所示的用户设备20a、网关20b和应用服务器20c进行数据交互的具体过程。

可以理解的是，用户设备20a对应的用户可以为对象20d；用户设备20a上集成安装有应用客户端(例如，应用客户端Y)，网关20b上运行有应用客户端Y对应的工作线程21a；用户设备20a和网关20b之间可以通过基站(例如，图1所对应实施例中的基站4000a)进行数据通信。其中，网关20b中包括多个运行于用户态的工作线程(即用户态线程)，多个用户态线程可以包括图2所示的工作线程21a。

可以理解的是，如图2所示，对象20d可以通过用户设备20a中的应用客户端Y向网关20b发送数据报文，这样，基站4000a可以将用户设备20a中的应用客户端Y所发送的数据报文转发至网关20b。因此，网关20b可以通过基站4000a接收用户设备20a发送的数据报文，进而对该数据报文进行解析以及其他处理，以得到处理后的数据报文，进而将该处理后的数据报文发送到应用服务器20c。

如图2所示，工作线程21a中可以包括缓冲接收队列21b，网关20b在对数据报文进行流转处理时，可以首先将该数据报文加载至工作线程21a的缓冲接收队列21b中。其中，缓冲接收队列21b中可以包括多个数据报文，多个数据报文具体可以包括k个数据报文，这里的k可以为正整数，这里的k个数据报文具体可以包括数据报文22a、数据报文22b、数据报文22c、数据报文22d、…、数据报文22k。其中，数据报文22a可以为图2所示的用户设备20a所发送的数据报文。

如图2所示，在工作线程21a中，该工作线程21a可以从缓冲接收队列21b中获取具有相同报文格式的数据报文，基于具有相同报文格式的数据报文，生成数据报文集合(例如，数据报文集合21c)。比如，缓冲接收队列21b中具有相同报文格式的数据报文可以为数据报文22a、数据报文22b、数据报文22c和数据报文22d。因此，该数据报文集合21c中可以包括数据报文22a、数据报文22b、数据报文22c和数据报文22d，即工作线程21a可以基于数据报文22a、数据报文22b、数据报文22c和数据报文22d，生成数据报文集合21c。

进一步地，工作线程21a可以根据访问控制规则识别数据报文集合21c中的数据报文的报文执行类型，比如，数据报文22a和数据报文22b的报文执行类型可以为内核执行类型，数据报文22c和数据报文22d的报文执行类型可以为业务执行类型。其中，内核执行类型对应的数据报文为内核数据报文，业务执行类型对应的数据报文为业务数据报文。因此，数据报文22a和数据报文22b可以为内核数据报文，数据报文22c和数据报文22d可以为业务数据报文。

如图2所示，工作线程21a可以根据访问控制规则将数据报文集合21c中的内核数据报文分流至内核态线程，即工作线程21a可以将数据报文22a和数据报文22b分流至内核态线程，以通过内核态线程分别对数据报文22a和数据报文22b进行流转处理，得到处理后的数据报文22a(即处理数据报文23a)和处理后的数据报文22b(即处理数据报文23b)。

如图2所示，工作线程21a可以根据访问控制规则将数据报文集合21c中的业务数据报文分流至工作线程21a中的报文处理节点，即工作线程21a可以将数据报文22c和数据报文22d分流至报文处理节点，以通过报文处理节点分别对数据报文22c和数据报文22d进行流转处理，得到处理后的数据报文22c(即处理数据报文23c)和处理后的数据报文22d(即处理数据报文23d)。其中，报文处理节点的数量可以为一个或多个，这里不对报文处理节点的数量进行限定。

因此，网关20b可以将上述处理后的数据报文22a(即处理数据报文23a)转发至应用服务器20c，以使应用服务器20c可以接收用户设备20a通过网关20b转发的处理数据报文23a。

可选的，对象20d还可以通过用户设备20a中的应用客户端Y向应用服务器20c请求获取数据报文，这样，应用服务器20c可以向网关20b发送数据报文，以使基站可以将网关20b所获取的数据报文转发至用户设备20a中的应用客户端Y。其中，网关20b可以接收应用服务器20c发送的数据报文，进而对该数据报文进行流转处理，以得到处理后的数据报文，进而通过基站将该处理后的数据报文发送到用户设备20a。

由此可见，本申请实施例可以从用户态下的工作线程对应的缓冲接收队列中获取批量数据报文(即数据报文集合中的数据报文)，进而对这一批量数据报文进行并发处理。可以理解的是，网元设备可以同时兼容内核数据报文和业务数据报文，因此，这一批量数据报文中可以包括内核数据报文和业务数据报文，对于不同报文执行类型的数据报文而言，可以被流转到不同的流水线进行处理。其中，内核数据报文可以通过内核态线程进行流转处理，业务数据报文可以通过上述工作线程(即用户态线程)进行流转处理。因此，本申请实施例可以实现在用户态对数据报文集合中的数据报文进行流转处理，进而提高网元设备对数据报文的处理能力。

进一步地，请参见图3，图3是本申请实施例提供的一种数据处理方法的流程示意图。该方法可以由网元设备执行，该网元设备可以为用户面功能网元(即核心网网元UPF)，该核心网网元UPF可以为上述图1所对应实施中的网关4000b。其中，该数据处理方法可以包括以下步骤S101-步骤S103：

步骤S101，在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；

具体的，用户面功能网元可以在用户态下的工作线程(即用户态线程)中，对工作线程对应的缓冲接收队列进行轮询，识别轮询得到的数据报文的报文格式。其中，报文格式包括目标报文格式。进一步地，若具有目标报文格式的数据报文的报文数量大于或等于数量阈值，则用户面功能网元可以基于具有目标报文格式的数据报文，生成目标报文格式对应的数据报文集合。其中，同一个数据报文集合中的数据报文具有相同的报文格式。

可以理解的是，用户面功能网元中可以包括多个用户态线程(即多个工作线程)，本申请实施例不对用户面功能网元中的用户态线程的线程数量进行限定，这里以多个用户态线程中任意一个用户态线程(例如，用户态线程X)为例进行说明。其中，多个用户态线程中的每个用户态线程均对应一个缓冲接收队列，例如，用户态线程X对应的缓冲接收队列可以为缓冲接收队列D。

其中，可以理解的是，用户态线程X可以根据时间片大小周期性轮询缓冲接收队列D，比如，用户态线程X可以在T₁时刻识别缓冲接收队列D中的数据报文的报文格式，用户态线程X也可以在T₂时刻识别缓冲接收队列D中的数据报文的报文格式，这里的T₂时刻可以为T₁时刻的下一时刻，T₁时刻和T₂时刻之间的时间间隔为一个时间片的大小。其中，缓冲接收队列D在T₁时刻和T₂时刻所对应的数据报文是不一定相同的，即用户态线程X在T₁时刻和T₂时刻所轮询得到的数据报文是不一定相同的。

其中，数据报文的报文格式可以为IPv4(Internet Protocol Version 4)报文格式，也可以为IPV6(Internet Protocol Version 6)报文格式，还可以为ARP(AddressResolution Protocal，地址解析协议)报文格式，还可以为MPLS(Multi-Protocol LabelSwitching，多协议标签交换)报文格式，还可以为LLC(Local Link Control，逻辑链路控制协议)报文格式。应当理解，本申请实施例不对报文格式的格式数量进行限定。

可以理解的是，报文格式可以包括第一报文格式和第二报文格式，用户面功能网元可以统计具有第一报文格式的数据报文的报文数量(例如，第一报文数量)，统计具有第二报文格式的数据报文的报文数量(例如，第二报文数量)，比如，这里的第二报文格式可以为IPv4报文格式，这里的第二报文格式可以为IPV6报文格式。其中，若在缓冲接收队列中，第一报文数量大于或等于数量阈值，则该第一报文格式(即IPv4报文格式)即为目标报文格式；若在缓冲接收队列中，第二报文数量大于或等于数量阈值，则该第二报文格式(即IPv6报文格式)即为目标报文格式。应当理解，本申请实施例不对数量阈值的具体取值进行限定。

可选的，若工作线程在某一时刻轮询得到的数据报文中，具有第一报文格式和具有第二报文格式的数据报文的报文数量均大于或等于数量阈值，则用户面功能网元可以将第一报文格式和第二报文格式均分别作为目标报文格式，进而基于具有第一报文格式的数据报文，生成第一报文格式对应的数据报文集合(例如，数据报文集合J₁)，且基于具有第二报文格式的数据报文，生成第二报文格式对应的数据报文集合(例如，数据报文集合J₂)。其中，数据报文集合J₁中的数据报文具有第一报文格式，数据报文集合J₂中的数据报文具有第二报文格式。

可选的，若工作线程在某一时刻轮询得到的数据报文的报文数量大于数据报文集合所包括的最大数量，则工作线程可以基于轮询得到的数据报文，生成两组或两组以上的数据报文集合。比如，若工作线程在某一时刻轮询得到的具有相同报文格式的数据报文的报文数量为300个，且数据报文集合所包括的最大数量为256个，则工作线程可以基于具有相同报文格式的300个数据报文，生成两组数据报文集合。

可选的，若在某一时刻轮询得到的数据报文中，不具有某一报文格式的数据报文的报文数量大于或等于数量阈值(即所有报文格式的数据报文分别对应的报文数量均小于数量阈值)，则用户面功能网元可以忽略本次轮询，无需生成数据报文集合，在下一次轮询时，对轮询得到的数据报文的报文格式进行统计。

应当理解，本申请实施例中的数据报文集合可以实现对数据报文进行批量处理，该报文批量处理方式可以把一批底层硬件队列(即缓冲接收队列)收到的一组报文，组成报文集合(即数据报文集合)，等报文集合组装完毕后作为一个整体发送到用户态空间中的报文处理图(Packet Processing Graph)(即流图)进行流转，这样可以减少缓存的未命中数来增加转发吞吐量，进而可以提高CPU缓存的利用率。

其中，报文处理图中可以包括多个图节点(Graph Node)，图节点可以把整个处理流程分解为一个个先后连接的服务节点，数据报文可以通过报文处理图中的连接线进行流转，报文集合被第一个图节点(即流水线Input节点(即以太网输入节点))的任务处理，然后根据类型依次被第二个图节点的任务处理，依次类推。可以理解的是，通过插件(即Plugin)的形式可以在报文处理图中引入新的图节点，或者重新排列报文处理图中的图节点，将插件添加到插件目录中，运行程序的时候就会自动加载插件。

其中，插件机制使得开发者可以充分利用现有模块、快速开发出新功能，实际上，插件的本质就是实现了某一特定功能的图节点，该图节点能够被插入到报文处理图中的任意位置。

为便于理解，通过报文处理图中的图节点对报文集合进行流转的具体过程可以参见图4，图4是本申请实施例提供的一种进行报文处理的流程示意图。如图4所示的报文处理图中可以包括多个图节点(例如，10个图节点)，这里的10个图节点可以为节点G₁(即Ethernet-input)、节点G₂(即MPLS-Ethernet-input)、节点G₃(即Ip6-input)、节点G₄(即Ip4-input)、节点G₅(即Arp-input)、节点G₆(即llc-input)、节点G₇(即Ip6-lookup)、节点G₈(即Ip6-rewrite-transmit)、节点G₉(即Ip6-local)和节点G₁₀(即Plugin-node(s))。其中，节点G₁为报文处理图中的第一个图节点；节点G₂、节点G₃、节点G₄、节点G₅或者节点G₆为报文处理图中的第二个图节点；节点G₇为报文处理图中的第三个图节点；节点G₈和节点G₉为报文处理图中的第四个图节点。

如图4所示的数据包处理图(即报文处理图)可以将数据包的处理管道被分解为一个或多个节点，这种模块化方法意味着任何人都可以在数据包处理图中插入新的图节点。包处理图逐个节点(包括插件)应用于整个包向量(即数据报文集合)，当每个图节点表示的网络依次应用于每个数据包时，接收到的数据包通常会遍历向量中的包处理图节点。其中，节点G₁₀表示可以在报文处理图中新增或删除节点。其中，数据报文是由数据包进行组装所得到的，在数据报文较短时，数据报文即为数据包。

如图4所示的数据报文集合40a中可以包括多个数据报文，多个数据报文可以为M个数据报文，这里的M可以为正整数，这里的M个数据报文具体可以包括数据报文B₁、数据报文B₂、…、数据报文B_M。其中，数据报文B₁、数据报文B₂、…、数据报文B_M具有相同的报文格式。

应当理解，工作线程在对数据报文集合中的数据报文进行流转之前，可以确定数据报文集合中是否存在内核数据报文和业务数据报文，进而可以确定数据报文集合中的数据报文的执行路径。比如，若数据报文集合中存在内核数据报文，则可以将内核数据报文执行下述步骤S102；若数据报文集合中存在业务数据报文，则可以将业务数据报文执行下述步骤S103。其中，工作线程确定数据报文集合中是否存在内核数据报文和业务数据报文的具体过程可以参见下述图5所对应实施例的描述。

步骤S102，若数据报文集合中存在内核数据报文，则在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理；

可以理解的是，内核态线程在对内核数据报文进行流转处理时，可以根据网络通信模型(例如，OSI(Open System Interconnection Reference Model，开放式系统互联通信参考模型))对数据报文进行逐层解析、逐层封装。

可选的，若数据报文集合中不存在内核数据报文，则可以通过步骤S103对数据报文集合中的全部数据报文进行流转处理。其中，这里的全部数据报文均为业务数据报文。

步骤S103，若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的一个或多个报文处理节点，通过一个或多个报文处理节点对业务数据报文进行流转处理。

具体的，若数据报文集合中存在业务数据报文，则用户面功能网元可以在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的路由匹配节点。其中，一个或多个报文处理节点包括路由匹配节点。进一步地，用户面功能网元可以通过路由匹配节点对业务数据报文携带的目的地址进行路由匹配，得到业务数据报文对应的路由数据报文。进一步地，用户面功能网元可以对路由数据报文进行报文协议解析。

可以理解的是，从业务数据报文中可以获取业务数据报文所要发送的目的地址(即目的IP地址)，路由匹配节点可以查询路由表，根据目的地址，将业务数据报文路由到目的地址所对应的网元设备。在用户设备向应用服务器发送数据报文时，这里的网元设备可以为应用服务器；在应用服务器向用户设备发送数据报文时，这里的网元设备可以为用户设备。应当理解，本申请实施例不对通过路由匹配节点进行路由匹配的具体过程进行限定。

其中，一个或多个报文处理节点还可以包括第一报文解析节点和第二报文解析节点。应当理解，用户面功能网元对路由数据报文进行报文协议解析的具体过程可以描述为：用户面功能网元可以识别与路由数据报文相关联的报文协议类型。进一步地，若报文协议类型为通用路由封装协议类型，则用户面功能网元可以将路由数据报文发送至第一报文解析节点，通过第一报文解析节点对路由数据报文进行报文协议解析。可选的，若报文协议类型为虚拟扩展局域网协议类型，则用户面功能网元可以将路由数据报文发送至第二报文解析节点，通过第二报文解析节点对路由数据报文进行报文协议解析。

可以理解的是，在数据报文集合中的数据报文的报文格式为IPv4报文格式时，第一报文解析节点可以为gre4-encap节点，第二报文解析节点可以为vxlan4-encap节点。可选的，在数据报文集合中的数据报文的报文格式为IPv6报文格式时，第一报文解析节点可以为gre6-encap节点，第二报文解析节点可以为vxlan6-encap节点。其中，encap表示拆包与解包，可以用于对数据报文进行解析。

其中，通用路由封装协议类型为通用路由封装(Generic RoutingEncapsulation，简称GRE)协议对应的报文协议类型，虚拟扩展局域网协议类型为虚拟扩展局域网(Virtual eXtensible Local Area Network，简称vxlan)协议对应的报文协议类型。可以理解的是，第一报文解析节点可以基于通用路由封装协议，对路由数据报文进行报文协议解析；第二报文解析节点可以基于虚拟扩展局域网协议，对路由数据报文进行报文协议解析。

其中，一个或多个报文处理节点还可以包括策略节点和隧道处理节点。应当理解，用户面功能网元在对路由数据报文进行报文协议解析之后，可以获取经过报文协议解析所得到的解析数据报文，将解析数据报文发送至策略节点，通过策略节点对解析数据报文进行策略控制，得到策略控制后的解析数据报文。进一步地，用户面功能网元可以将策略控制后的解析数据报文发送至隧道处理节点，通过隧道处理节点对策略控制后的解析数据报文进行隧道处理，得到加密数据报文。进一步地，用户面功能网元可以将加密数据报文发送至网卡组件对应的网卡发送队列。

可以理解的是，策略控制可以为限速，此时，策略节点可以用于对解析数据报文进行限速，策略控制后的解析数据报文可以理解为限速后的解析数据报文。

可以理解的是，隧道处理可以为加密处理，此时，隧道处理节点可以用于建立加密隧道，通过加密隧道对策略控制后的解析数据报文进行加密处理，得到加密处理后的数据报文(即加密数据报文)，进而可以保证数据报文传输的完整性和私密性。

应当理解，用户面功能网元将加密数据报文发送至网卡组件对应的网卡发送队列的具体过程可以描述为：用户面功能网元可以通过隧道处理节点将加密数据报文添加至工作线程对应的缓冲发送队列。进一步地，用户面功能网元可以通过网卡组件(即网卡设备)获取缓冲发送队列中的加密数据报文，将网卡组件所获取到的加密数据报文存放至网卡组件对应的网卡发送队列。

可以理解的是，用户面功能网元的多个用户态线程(即工作线程)中的每个用户态线程均对应一个缓冲发送队列，例如，用户态线程X对应的缓冲发送队列可以为缓冲发送队列L。

可选的，若数据报文集合中不存在业务数据报文，则可以通过步骤S102对数据报文集合中的全部数据报文进行流转处理。其中，这里的全部数据报文均为内核数据报文。

由此可见，本申请实施例中的网元设备可以直接在用户态下的工作线程中，将接收到的多个数据报文封装成数据报文集合，进而一次性对数据报文集合中的数据报文进行流转处理。可以理解的是，由于数据报文集合中的数据报文具有相同的报文格式，在通过工作线程对这些数据报文进行流转处理时，可以提高指令缓存的缓存命中率。此外，本申请实施例中的网元设备可以同时兼容业务数据报文和内核数据报文，且在用户态实现对业务数据报文的流转处理，从而减少上下文频繁切换和数据在用户态和内核态之间的相互拷贝，进而可以提高网元设备对数据报文的处理能力。

进一步地，请参见图5，图5是本申请实施例提供的一种数据处理方法的流程示意图。该方法可以由网元设备执行，该网元设备可以为用户面功能网元(即核心网网元UPF)，该核心网网元UPF可以为上述图1所对应实施中的网关4000b。其中，该数据处理方法可以包括以下步骤S201-步骤S203：

步骤S201，将数据报文集合发送至工作线程中的访问控制节点，在访问控制节点中，基于访问控制列表对数据报文集合中的数据报文进行匹配；

具体的，用户面功能网元可以将数据报文集合中的数据报文加载至数据缓存，在数据缓存中依次对数据报文集合中的数据报文进行报文检测。进一步地，若报文检测出数据报文集合中存在检验成功的数据报文，则用户面功能网元可以将检验成功的数据报文发送至工作线程中的访问控制节点。

可以理解的是，工作线程中可以包括以太网输入节点，该以太网输入节点可以对工作线程对应的缓冲接收队列进行轮询，生成不同报文格式对应的数据报文集合(例如，目标报文格式对应的数据报文集合)。进一步地，以太网输入节点可以根据数据报文集合中的数据报文的报文格式，将数据报文结合流转至工作线程中不同的报文输入节点。这样，报文输入节点在获取到数据报文集合之后，可以一次性将数据报文集合中的数据报文加载至数据缓存。

可以理解的是，不同报文格式可以对应于不同的报文输入节点，为便于理解，请再参见图4，如图4所示的节点G₂可以MPLS报文格式对应的报文输入节点，节点G₃可以为IPV6报文格式对应的报文输入节点、节点G₄可以为IPv4报文格式对应的报文输入节点、节点G₅可以为ARP报文格式对应的报文输入节点、节点G₆可以为LLC报文格式对应的报文输入节点。

应当理解，用户面功能网元在数据缓存中依次对数据报文集合中的数据报文进行报文检测的具体过程可以描述为：用户面功能网元可以将数据报文集合中的数据报文加载至数据缓存，从数据缓存中获取数据报文集合的数据报文S_i。其中，这里的i可以为小于或等于数据报文集合中的数据报文的报文数量的正整数。进一步地，用户面功能网元可以获取数据报文S_i对应的报文处理指令，将报文处理指令加载至指令缓存，通过指令缓存中的报文处理指令对数据报文S_i进行报文检测。进一步地，用户面功能网元可以从数据缓存中获取数据报文集合的数据报文S_i+1，从指令缓存中获取报文处理指令，通过报文处理指令对数据报文S_i+1进行报文检测。

可以理解的是，当报文输入节点被调度时，它可以利用双循环(Dual-Loop)和预取报文方式到CPU缓存来处理报文。其中，双循环和预取报文方式可以通过队列的读取方式将数据报文集合加入到缓存，先处理第一个数据报文，处理完第一个数据报文，再处理第二个数据报文，依次类推，直到处理完最后一个数据报文。

其中，数据报文S_i+1可以为数据报文S_i的下一个数据报文。比如，在数据报文S_i为第一个数据报文时，数据报文S_i+1可以为第二个数据报文；又比如，在数据报文S_i为第二个数据报文时，数据报文S_i+1可以为第三个数据报文。

可以理解的是，报文处理指令可以用于对数据报文S_i进行报文检测。可选的，用户面功能网元还可以在获取报文处理指令时，一并获取用于对数据报文S_i进行报文处理的其他处理指令，通过其他处理指令和报文处理指令对数据报文S_i进行报文检测和报文处理。

可以理解的，通过数据报文集合的方式对数据报文进行处理可以称之为矢量报文处理方式，该矢量报文处理方式可以积极利用缓存的时间局限性特征，如果指令缓存命中，则数据报文集合中的数据报文都会命中，否则都未命中。在命中指令缓存时，通过数据报文集合中的第一个数据报文为指令缓存镜像预热，为数据报文集合中的后续数据报文进行缓存加速。

应当理解，由于数据报文集合中的第一个数据报文为指令缓存进行了预热，数据报文集合中的剩下数据报文的处理性能可以达到极限，指令缓存中指令缺失的固定开销平摊到了整个数据报文集合中，使得单个数据报文的处理开销显著降低，进而可以解决指令缓存抖动的问题，提高缓存吞吐量，且数据报文集合可以缓解读时延问题，高性能并且更加稳定。

可选的，若报文检测出数据报文集合中存在检验失败的数据报文，则用户面功能网元可以将检验失败的数据报文传递至失败处理节点(即Error-drop节点)。

可以理解的是，访问控制规则包括属于访问控制列表(Access Control List，简称ACL)中的内核报文匹配规则和业务报文匹配规则，即访问控制列表中可以包括访问控制规则，访问控制规则中可以包括与内核数据报文相关联的内核报文匹配规则和与业务数据报文相关联的业务报文匹配规则。其中，访问控制列表ACL是由一条或多条规则组成的集合，所谓规则，是指描述报文匹配条件的判断语句，这些条件可以是报文的源地址，源端口，目的地址，目的端口和传输层协议等。其中，访问控制列表是一种基于包过滤的访问控制技术，它可以根据设定的条件对接口上的数据包进行过滤，允许其通过或丢弃。借助于访问控制列表，可以有效地控制用户对网络的访问，从而最大程度地保障网络安全。

应当理解，工作线程可以将数据报文集合中的数据报文与访问控制列表中的访问控制规则进行匹配，确定数据报文集合中是否存在内核数据报文和业务数据报文。比如，若数据报文集合中存在与内核报文匹配规则相匹配的数据报文，则可以执行下述步骤S202；若数据报文集合中存在与业务报文匹配规则相匹配的数据报文，则可以执行下述步骤S203。

步骤S202，若数据报文集合中存在与内核报文匹配规则相匹配的数据报文，则确定数据报文集合中存在内核数据报文；

可以理解的是，用户面功能网元可以将与内核报文匹配规则相匹配的数据报文，作为内核数据报文，即内核数据报文为与内核报文匹配规则相匹配的数据报文。其中，内核报文匹配规则可以用于在数据报文集合中筛选内核数据报文。

步骤S203，若数据报文集合中存在与业务报文匹配规则相匹配的数据报文，则确定数据报文集合中存在业务数据报文。

可以理解的是，用户面功能网元可以将与业务报文匹配规则相匹配的数据报文，作为业务数据报文，即业务数据报文为与业务报文匹配规则相匹配的数据报文。其中，业务报文匹配规则可以用于在数据报文集合中筛选业务数据报文。

可选的，若数据报文集合中存在既不与内核报文匹配规则相匹配、也不与业务报文匹配规则相匹配的数据报文，则用户面功能网元可以将不相匹配的数据报文确定为不合法数据报文(即非法数据报文)，进而丢弃该数据报文集合中的非法数据报文。可选的，访问控制列表中还可以包括非法访问控制规则，若数据报文集合中存在与非法访问控制规则相匹配的数据报文，则用户面功能网元可以将与非法访问控制规则相匹配的数据报文，确定为非法数据报文。

由此可见，本申请实施例可以通过访问控制列表中的报文匹配规则识别数据报文的报文执行类型，这里的报文匹配规则可以包括内核报文匹配规则和业务报文匹配规则，因此，这里的数据报文可以包括内核报文匹配规则对应的内核数据报文和业务报文匹配规则对应的业务数据报文。可以理解的是，不同报文执行类型的数据报文可以被后续分流至不同的流水线处理，进而可以提高数据报文的解析处理效率。

进一步地，请参见图6，图6是本申请实施例提供的一种数据处理方法的流程示意图。该方法可以由网元设备执行，该网元设备可以为用户面功能网元(即核心网网元UPF)，该核心网网元UPF可以为上述图1所对应实施中的网关4000b。其中，该数据处理方法可以包括以下步骤S301-步骤S310：

步骤S301，通过网卡组件获取数据报文，将网卡组件所获取到的数据报文存放至网卡组件对应的网卡接收队列；

步骤S302，通过网卡组件对网卡接收队列中的数据报文进行拦截中断处理，将拦截中断处理后的数据报文均衡分配至缓冲接收队列；

具体的，用户面功能网元可以通过网卡组件对网卡接收队列中的数据报文进行拦截中断处理，为拦截中断处理后的数据报文生成报文标识。其中，工作线程的线程数量为至少两个，至少两个工作线程中的每个工作线程分别对应于一个缓冲接收队列。进一步地，用户面功能网元可以根据报文标识，将拦截中断处理后的数据报文均衡分配至至少两个工作线程分别对应的缓冲接收队列。

可以理解的是，报文标识可以为哈希标识，网卡驱动可以对每个数据报文生成一个哈希标识(即哈希值)，这个哈希值可以通过四元组(源IP地址、源四层端口、目的IP地址、目的四层端口)来计算，然后由中断处理的地方根据这个哈希标识分配到相应的CPU核(简称核)上去。其中，将工作线程的某个缓冲接收队列分配给某个核，从该缓冲接收队列中收到的所有报文都应当在该指定的核上处理结束。

可以理解的是，UIO(Userspace I/O)是运行在用户空间的I/O技术，UIO可以实现对数据报文的拦截中断处理。Linux系统中一般的驱动设备都是运行在内核空间，而在用户空间用应用程序调用即可，而UIO则是可以将驱动的很少一部分运行在内核空间，而在用户空间实现驱动的绝大多数功能。

其中，拦截报文处理流程本质上是对用户空间暴露文件接口，对文件的读写就是对设备内存的读写，这样基于轮询方式收包，避免了中断开销。由于操作系统中断强制去应对报文处理，会频繁切换上下文，并遍历调用堆栈，CPU缓存频繁进出调度，导致CPU无法运行其他程序，时间开销大，产生较高的性能开销。采用轮询机制，不会打断当前报文处理的连续性，处理报文任务可由应用程序根据资源情况编排，这样的内核旁路技术减少了很多的中断和内存拷贝。

可以理解的是，用户面功能网元的内存中可以有多个缓冲区，多个缓冲区的每个缓冲区中创建有一组队列，这里的一组队列可以包括发送队列(即缓冲发送队列)和接收队列(即缓冲接收队列)，即一个工作线程对应于一个缓冲发送队列和一个缓冲接收队列。

其中，内存指内存池，缓冲区指环缓冲区，队列指缓存队列。内存池由一个环缓冲区和一组核本地缓存队列组成，每个核从自己的缓存队列分配内存块，当本地缓存队列减少到一定程度时，可以从内存环缓冲区中申请内存块来补充本地队列。

可以理解的是，操作系统可以实现对CPU的调度，将不同的工作线程运行在CPU的不同核上，一个CPU核上可以运行有一个或多个工作线程，合适的工作线程的数量可以提高CPU的运行效率。将某个工作线程绑定到特定的一个或者多个核上执行，而不被迁移到其它核上运行，一旦工作线程绑定到某个CPU核后，线程就会一直在指定的CPU核上运行，操作系统不会将其调度到其他的CPU核上，节省了调度的性能消耗，从而提升了程序执行的效率。应当理解，本申请实施例不对工作线程的数量进行限定。

应当理解，一个完整的TCP连接，中断发生在一个CPU核(例如，CPU1)上，但应用数据处理可能会在另外一个核(例如，CPU2)上，不同CPU核心处理，带来了锁竞争、频繁的上下文切换、CPU缓存不能马上命中，将导致时延和丢包。

为便于理解，请参见图7，图7是本申请实施例提供的一种进行报文处理的结构示意图。用户态空间中可以包括多个应用程序，例如，图7所示的4个应用程序。其中，不同的应用程序可以用于处理与不同的应用客户端相关联的数报文。如图7所示的软硬件环境抽象层为应用程序提供了一个屏蔽具体平台特性的通用接口，隐藏了与底层库和设备打交道的相关细节。

如图7所示的网络工具库可以包括队列管理、报文流转和轮询管理，可选的，网络工具库还可以包括网络协议工具。其中，队列管理可以对每个工作线程对应的队列进行管理，例如，动态扩展和缩容队列，队列回收等；报文流转可以控制报文在用户态的处理流程，例如，对报文的处理状态进行变更；轮询管理可以控制工作线程对报文的轮询，例如，控制工作线程每隔一定时间对队列中的报文的组装打包；网络协议工具可以进行协议解析，例如，解析RIP协议(Routing Information Protocol，路由信息协议)、OSPF(Open ShortestPath First，开放式最短路径优先)协议、IP协议(Internet Protocol，网际互连协议)等。

可以理解的是，Linux内核可以将上述应用程序看作是一个普通的用户态进程，该用户态进程中可以包括一个主线程和多个工作线程，一个应用程序可以看做一个进程，该进程可以包括一个主线程和多个工作线程，多个工作线程可以用于对网卡的接收队列进行轮询操作，主线程可以用于对多个工作线程进行管理，这样设计最大的优势是可以根据业务场景进行个性化定制，让性能有很大的提升。其中，多个应用程序分别可以对应于多个进程，不同进程可以用于处理用户面功能网元收到的用户设备上的不同应用程序所发送的数据报文。

如图7所示，应用程序运行在用户空间，利用网络协议工具来处理数据报文，通过UIO技术进行拦截中断，绕过了Linux内核协议栈对数据报文处理。可以理解的是，从网卡组件直接到内核中进行数据报文处理的流程可以包括9个步骤，这9个步骤可以为：(1)硬件中断，(2)取报文分发至内核线程，(3)软件中断，(4)内核线程在协议栈中处理包，(5)处理完毕通知用户层，(6)用户层收报文，(7)网络层，(8)逻辑层，(9)业务层。其中，网络层可以将以太网数据帧转换为IP报文；逻辑层可以实现逻辑地址寻址，分发到不同应用或者相同应用中的不同模块；业务层可以实现业务处理模块。

应当理解，本申请实施例将内核对数据报文的处理流程转移至用户态中，通过用户态进行数据报文处理，使得进行数据报文处理的流程可以从9个步骤减少到6个步骤，这6个步骤可以为：(1)硬件中断，(2)放弃中断流程，(3)用户层设备映射，(4)用户层协议栈，(5)逻辑层，(6)业务层。其中，硬件中断可以指示网卡在接收到数据包时，UIO可以拦截网卡组件向CPU核所发送的硬件中断；放弃中断流程可以指示网卡组件将数据包从网卡接收队列中拷贝到用户空间的内存(或者CPU缓存)中；用户层设备映射可以指示将数据包在内存中所对应的接口作为文件接口，用户空间可以通过文件接口对数据包实现解析等操作；用户层协议栈可以指示应用层的应用程序可以对数据包进行报文解析；逻辑层和业务层是具体应用的业务模块，可以用于校验数据报文是否有权限、路由给哪个模块去处理等。

如图7所示的流程绕过了linux内核(即操作系统内核)的网络驱动模块，直接从硬件与链路到达用户空间，不需要进行频繁的内存拷贝和系统调用。UIO技术将设备驱动分为用户空间驱动和内核空间驱动两部分，内核空间驱动主要负责设备资源分配、UIO设备注册以及小部分中断响应函数，驱动的大部分工作在用户空间的驱动程序下完成。通过UIO框架提供的API接口(Application Programming Interface，应用程序接口)将UIO的驱动注册到内核，注册完成后将生成存有设备物理地址等信息的映射文件，用户态进程访问该文件将设备对应的内存空间地址映射到用户空间，即可直接操作设备的内存空间，UIO技术使得应用程序可以通过用户空间驱动直接操作设备的内存空间，避免了数据在内核缓冲区和应用程序缓冲区的多次拷贝，提高数据处理效率。

步骤S303，在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；

可以理解的是，网卡可以将网卡接收队列中的报文均衡分配到不同工作线程的队列缓存中。这样，工作线程可以轮询各自的队列缓存，对各自队列缓存中的报文进行类型分析，得到数据报文所对应的不同报文执行类型，进而可以将不同报文执行类型的报文打包为不同的报文集合。

其中，用户面功能网元基于缓冲接收队列中的数据报文，生成数据报文集合的具体过程，可以参见上述图3所对应实施例中对步骤S101的描述，这里将不再进行赘述。

应当理解，本申请实施例所提供的用户态处理流水线可以同时兼容内核数据报文和业务数据报文的流转，在数据报文属于不同的报文执行类型时，可以将数据报文流转至不同的流水线进行流转处理。其中，内核数据报文可以执行下述步骤S304所对应的流水线，业务数据报文可以执行下述步骤S305-步骤S310所对应的流水线。

步骤S304，若数据报文集合中存在内核数据报文，则在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理；

为便于理解，请参见图8a和图8b，图8a和图8b是本申请实施例提供的一种进行用户态报文流水线处理的流程示意图。如图8a和图8b所示应用程序可以包括一个主线程和多个工作线程，多个工作线程可以用于对缓冲接收队列进行轮询操作，主线程可以用于对多个工作线程进行管理。

其中，这里以工作线程的线程数量为3个为例进行说明，3个工作线程具体可以包括工作线程50a、工作线程50b和工作线程50c，为便于理解，本申请实施例以工作线程50a为例说明该用户态报文流水线的处理流程，工作线程50b和工作线程50c中的用户态报文流水线的处理流程可以参见对工作线程50a的描述。

如图8a和图8b所示的网卡接收队列和网卡发送队列可以分别包括N个位置，N个位置可以用于存放N个数据报文。可以理解的是，在网卡接收队列为满时，网卡接收队列无法接收数据报文；在网卡发送队列为空时，网卡发送队列无法发送数据报文。其中，图8a以数据报文集合中的数据报文的报文格式为IPv4报文格式为例进行说明，图8b以数据报文集合中的数据报文的报文格式为IPv6报文格式为例进行说明。其中，图8a和图8b所示的节点可以统称为报文处理节点。

如图8a所示的以太网输入节点可以为ethernet-input节点，报文输入节点P₀可以为arp-input节点，报文输入节点P₈可以为ip6-input节点，路由匹配节点P₆可以为ip6-lookup节点，重写节点P₂可以为ip6-rewrite节点，报文输入节点P₇可以为ip4-input节点，路由匹配节点P₅可以为ip4-lookup节点，重写节点P₁可以为ip4-rewrite节点，本地节点P₁₁可以为ip4-local节点，第一报文解析节点P₃可以为gre4-encap节点，第二报文解析节点P₄可以为vxlan4-encap节点，第一报文解析节点P₉可以为gre4-input节点，第二报文解析节点P₁₀可以为vxlan4-input节点，网络分路器节点可以为tap-inject节点，访问控制节点可以为acl plugin节点，策略节点可以为policer plugin节点，隧道处理节点可以为ipsecplugin节点。

如图8b所示的以太网输入节点可以为ethernet-input节点，报文输入节点P₀可以为arp-input节点，报文输入节点P₈可以为ip6-input节点，路由匹配节点P₆可以为ip6-lookup节点，重写节点P₂可以为ip6-rewrite节点，报文输入节点P₇可以为ip4-input节点，路由匹配节点P₅可以为ip4-lookup节点，重写节点P₁可以为ip4-rewrite节点，本地节点P₁₄可以为ip6-local节点，第一报文解析节点P₁₂可以为gre6-encap节点，第二报文解析节点P₁₃可以为vxlan6-encap节点，第一报文解析节点P₁₅可以为gre6-input节点，第二报文解析节点P₁₆可以为vxlan6-input节点，网络分路器节点可以为tap-inject节点，访问控制节点可以为acl plugin节点，策略节点可以为policer plugin节点，隧道处理节点可以为ipsecplugin节点。

如图8a所示，在内核报文流水线中，网卡接收队列在收到数据报文之后，可以通过以太网输入节点(即Ethernet节点)转发到IP4节点(即ip4-input节点、报文输入节点P₇)，进而根据报文的ACL访问控制规则进行分发，如果是合法报文，则通过tap口(即tap-inject节点)将数据报文发送至Linux内核。可选的，如果不合法，则丢弃数据报文。

如图8b所示，在内核报文流水线中，网卡接收队列在收到数据报文之后，可以通过以太网输入节点(即Ethernet节点)转发到IP6节点(即ip6-input节点、报文输入节点P₈)，进而根据报文的ACL访问控制规则进行分发，如果是合法报文，则通过tap口(即tap-inject节点)将数据报文发送至Linux内核。可选的，如果不合法，则丢弃数据报文。

其中，tap口可以理解为用户态到内核态的接口，在内核态数据报文处理完数据报文后，若要发送数据，内核可以直接将数据发送至网卡发送队列，而无需再通过tap口将数据传回用户空间。

其中，用户面功能网元通过内核态线程对内核数据报文进行流转处理的具体过程，可以参见上述图3所对应实施例中对步骤S102的描述，这里将不再进行赘述。

步骤S305，若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的路由匹配节点；

步骤S306，通过路由匹配节点对业务数据报文携带的目的地址进行路由匹配，得到业务数据报文对应的路由数据报文；

请再参见图4，图4以节点G₃的执行路径为例进行说明，在报文输入节点(即节点G₃)将数据报文集合中的数据报文加载至数据缓存之后，可以将数据报文传输至访问控制节点(未在图上示出)，进而通过访问控制节点将数据报文分流至节点G₇。进一步地，节点G₇在对数据报文进行路由匹配之后，可以将路由数据报文传输至不同的报文操作节点，以通过报文操作节点识别与路由数据报文相关联的报文协议类型。其中，这里的报文操作节点可以包括图4所示的节点G₈和节点G₉。

可以理解的是，如图4所示的节点G₈和节点G₉表示对数据报文作不同的处理，节点G₈可以表示重写和平移(即不处理)，节点G₉可以表示丢弃和转发数据包。其中，平移类似理解于函数传参，把报文作为入参变量传到函数，让函数知道这个变量的引用。

其中，用户面功能网元通过路由匹配节点进行路由匹配的具体过程，可以参见上述图3所对应实施例中对步骤S103的描述，这里将不再进行赘述。

步骤S307，对路由数据报文进行报文协议解析；

其中，用户面功能网元对路由数据报文进行报文协议解析的具体过程，可以参见上述图3所对应实施例中对步骤S103的描述，这里将不再进行赘述。

步骤S308，获取经过报文协议解析所得到的解析数据报文，将解析数据报文发送至策略节点，通过策略节点对解析数据报文进行策略控制，得到策略控制后的解析数据报文；

步骤S309，将策略控制后的解析数据报文发送至隧道处理节点，通过隧道处理节点对策略控制后的解析数据报文进行隧道处理，得到加密数据报文；

步骤S310，将加密数据报文发送至网卡组件对应的网卡发送队列。

具体的，用户面功能网元可以通过隧道处理节点将加密数据报文添加至工作线程对应的缓冲发送队列。进一步地，用户面功能网元可以通过网卡组件获取缓冲发送队列中的加密数据报文，将网卡组件所获取到的加密数据报文存放至网卡组件对应的网卡发送队列。

为便于理解，请再参见图8a，在业务报文流水线中，网卡接收队列在收到数据报文之后，可以通过以太网输入节点(即Ethernet节点)转发到IP4节点(即ip4-input节点、报文输入节点P₇)，进而根据报文的ACL访问控制规则进行分发，如果是业务数据报文，则通过访问控制节点(即ACL节点)将业务数据报文流转至路由匹配节点(例如，路由匹配节点P₅)。

如图8a所示的路由匹配节点P₅可以查找对应的路由表，通过报文操作节点(例如，重写节点P₁)将解析IP报文后查找是GRE协议还是Vxlan协议的数据包，并分发到对应的业务处理(例如，第一报文解析节点P₃)，处理后的报文通过缓冲发送队列送到网卡的网卡发送队列中，进而通过网络传输到远端。其中，第一报文解析节点P₃处理后的报文还可以发送至策略节点进行策略控制和隧道处理节点进行加密隧道处理，进而将策略节点和隧道处理节点将处理后的报文发送至网卡发送队列。

可选的，重写节点P₁还可以将报文分发到第二报文解析节点P₄进行业务处理，进而通过策略节点和隧道处理节点将处理后的报文发送至网卡发送队列。可选的，路由匹配节点P₅还可以将报文传递至本地节点P₁₁，以通过本地节点P₁₁将报文传递至第一报文解析节点P₉或者第二报文解析节点P₁₀。

为便于理解，请再参见图8b，在业务报文流水线中，网卡接收队列在收到数据报文之后，可以通过以太网输入节点(即Ethernet节点)转发到IP6节点(即ip6-input节点、报文输入节点P₈)，进而根据报文的ACL访问控制规则进行分发，如果是业务数据报文，则通过访问控制节点(即ACL节点)将业务数据报文流转至路由匹配节点(例如，路由匹配节点P₆)。

如图8b所示的路由匹配节点P₆可以查找对应的路由表，通过报文操作节点(例如，重写节点P₂)将解析IP报文后查找是GRE协议还是Vxlan协议的数据包，并分发到对应的业务处理(例如，第二报文解析节点P₁₃)，处理后的报文通过缓冲发送队列送到网卡的网卡发送队列中，进而通过网络传输到远端。其中，第二报文解析节点P₁₃处理后的报文还可以发送至策略节点进行策略控制和隧道处理节点进行加密隧道处理，进而将策略节点和隧道处理节点处理后的报文发送至网卡发送队列。

可选的，重写节点P₂还可以将报文分发到第一报文解析节点P₁₂进行业务处理，进而通过策略节点和隧道处理节点将处理后的报文发送至网卡发送队列。可选的，路由匹配节点P₆还可以将报文传递至本地节点P₁₄，以通过本地节点P₁₄将报文传递至第一报文解析节点P₁₅或者第二报文解析节点P₁₆。

可以理解的是，本申请实施例可以创建本方案所设计的流水线的协议，该协议可以在图8a和图8b所示的处理流水线中增加或删除节点，其中，通过代码开发实现协议的plugin，可以在配置文件中对plugin进行增加和删除。应当理解，图8a和图8b所示的节点可以位于同一个图中，这里不对该图所包括的节点进行一一列举。

请再参见图4，数据报文会根据图4所指示的处理流水线，依次通过对应的流图节点(即图节点)，直到被output节点发送出去。其中，这里的output节点可以为网卡组件所对应的网卡发送队列。可以理解的是，用户态数据报文处理流水线可以避免网关在用户态和内核态之间的频繁切换，提出步骤的优化，可加速报文处理能力，能够为UDP(UserDatagram Protocol，用户数据报协议)，TCP(Transmission Control Protocol，传输控制协议)，TLS(Transport Layer Security，安全传输层协议)提供高性能协议支持。

应当理解，本申请实施例通过旁路内核协议栈、基于轮询模式的报文无中断收发、内存/缓冲区/队列管理优化、网卡多队列等技术，提供一种用户态数据报文处理流水线，以代替Linux内核协议栈，主要考虑两个方面的数据流量，一方面是给内核的内核数据报文，另一方面是给业务的业务数据报文。其中，网卡在获取到数据报文之后可以将数据报文均衡分配至用户态的队列缓存，用户态应用程序可以开启多个工作线程，以报文集合为单位对队列缓存中的数据报文进行并发处理。其中，每个空闲的工作线程不断轮询报文接收队列(即缓冲接收队列)，不同于Linux内核被中断，轮询是主动查询，这样可以降低上下文切换的开销。基于此，本申请实施例可以提高CPU缓存的命中率，加快报文流转，有效提高吞吐能力，在用户态实现高性能报文转发能力；本申请实施例也可以降低上下文频繁切换开销导致的时延。

进一步地，请参见图9，图9是本申请实施例提供的一种数据处理装置的结构示意图，该数据处理装置1可以包括：集合生成模块11，第一处理模块12，第二处理模块13；进一步地，该数据处理装置1还可以包括：规则匹配模块14，第一匹配模块15，第二匹配模块16，报文存放模块17，拦截中断模块18；

集合生成模块11，用于在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；同一个数据报文集合中的数据报文具有相同的报文格式；

其中，集合生成模块11包括：格式识别单元111，集合生成单元112；

格式识别单元111，用于在用户态下的工作线程中，对工作线程对应的缓冲接收队列进行轮询，识别轮询得到的数据报文的报文格式；报文格式包括目标报文格式；

集合生成单元112，用于若具有目标报文格式的数据报文的报文数量大于或等于数量阈值，则基于具有目标报文格式的数据报文，生成目标报文格式对应的数据报文集合。

其中，格式识别单元111和集合生成单元112的具体实现方式，可以参见上述图3所对应实施例中对步骤S101的描述，这里将不再进行赘述。

第一处理模块12，用于若数据报文集合中存在内核数据报文，则在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理；

第二处理模块13，用于若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的一个或多个报文处理节点，通过一个或多个报文处理节点对业务数据报文进行流转处理。

其中，一个或多个报文处理节点包括路由匹配节点；

第二处理模块13包括：报文分流单元131，路由匹配单元132，报文解析单元133；可选的，第二处理模块13可以进一步包括：策略控制单元134，隧道处理单元135，报文发送单元136；

报文分流单元131，用于若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的路由匹配节点；

路由匹配单元132，用于通过路由匹配节点对业务数据报文携带的目的地址进行路由匹配，得到业务数据报文对应的路由数据报文；

报文解析单元133，用于对路由数据报文进行报文协议解析。

其中，一个或多个报文处理节点还包括第一报文解析节点和第二报文解析节点；

报文解析单元133包括：协议识别子单元1331，第一解析子单元1332，第二解析子单元1333；

协议识别子单元1331，用于识别与路由数据报文相关联的报文协议类型；

第一解析子单元1332，用于若报文协议类型为通用路由封装协议类型，则将路由数据报文发送至第一报文解析节点，通过第一报文解析节点对路由数据报文进行报文协议解析；

第二解析子单元1333，用于若报文协议类型为虚拟扩展局域网协议类型，则将路由数据报文发送至第二报文解析节点，通过第二报文解析节点对路由数据报文进行报文协议解析。

其中，协议识别子单元1331，第一解析子单元1332和第二解析子单元1333的具体实现方式，可以参见上述图3所对应实施例中对步骤S103的描述，这里将不再进行赘述。

可选的，一个或多个报文处理节点还包括策略节点和隧道处理节点；

策略控制单元134，用于获取经过报文协议解析所得到的解析数据报文，将解析数据报文发送至策略节点，通过策略节点对解析数据报文进行策略控制，得到策略控制后的解析数据报文；

隧道处理单元135，用于将策略控制后的解析数据报文发送至隧道处理节点，通过隧道处理节点对策略控制后的解析数据报文进行隧道处理，得到加密数据报文；

报文发送单元136，用于将加密数据报文发送至网卡组件对应的网卡发送队列。

其中，报文发送单元136，具体用于通过隧道处理节点将加密数据报文添加至工作线程对应的缓冲发送队列；

报文发送单元136，还具体用于通过网卡组件获取缓冲发送队列中的加密数据报文，将网卡组件所获取到的加密数据报文存放至网卡组件对应的网卡发送队列。

其中，报文分流单元131，路由匹配单元132，报文解析单元133，策略控制单元134，隧道处理单元135和报文发送单元136的具体实现方式，可以参见上述图3所对应实施例中对步骤S103的描述，这里将不再进行赘述。

可选的，访问控制规则包括属于访问控制列表中的内核报文匹配规则和业务报文匹配规则；

规则匹配模块14，用于将数据报文集合发送至工作线程中的访问控制节点，在访问控制节点中，基于访问控制列表对数据报文集合中的数据报文进行匹配；

其中，规则匹配模块14包括：报文检测单元141，第一发送单元142；可选的，规则匹配模块14可以进一步包括：第二发送单元143；

报文检测单元141，用于将数据报文集合中的数据报文加载至数据缓存，在数据缓存中依次对数据报文集合中的数据报文进行报文检测；

其中，报文检测单元141包括：报文加载子单元1411，第一检测子单元1412，第二检测子单元1413；

报文加载子单元1411，用于将数据报文集合中的数据报文加载至数据缓存，从数据缓存中获取数据报文集合的数据报文S_i；i为小于或等于数据报文集合中的数据报文的报文数量的正整数；

第一检测子单元1412，用于获取数据报文S_i对应的报文处理指令，将报文处理指令加载至指令缓存，通过指令缓存中的报文处理指令对数据报文S_i进行报文检测；

第二检测子单元1413，用于从数据缓存中获取数据报文集合的数据报文S_i+1，从指令缓存中获取报文处理指令，通过报文处理指令对数据报文S_i+1进行报文检测。

其中，报文加载子单元1411，第一检测子单元1412和第二检测子单元1413的具体实现方式，可以参见上述图3所对应实施例中对步骤S201的描述，这里将不再进行赘述。

第一发送单元142，用于若报文检测出数据报文集合中存在检验成功的数据报文，则将检验成功的数据报文发送至工作线程中的访问控制节点；

可选的，第二发送单元143，用于若报文检测出数据报文集合中存在检验失败的数据报文，则将检验失败的数据报文发送至失败处理节点。

其中，报文检测单元141，第一发送单元142和第二发送单元143的具体实现方式，可以参见上述图5所对应实施例中对步骤S201的描述，这里将不再进行赘述。

第一匹配模块15，用于若数据报文集合中存在与内核报文匹配规则相匹配的数据报文，则确定数据报文集合中存在内核数据报文；

第二匹配模块16，用于若数据报文集合中存在与业务报文匹配规则相匹配的数据报文，则确定数据报文集合中存在业务数据报文。

可选的，报文存放模块17，用于通过网卡组件获取数据报文，将网卡组件所获取到的数据报文存放至网卡组件对应的网卡接收队列；

拦截中断模块18，用于通过网卡组件对网卡接收队列中的数据报文进行拦截中断处理，将拦截中断处理后的数据报文均衡分配至缓冲接收队列。

其中，工作线程的线程数量为至少两个，至少两个工作线程中的每个工作线程对应于一个缓冲接收队列；

拦截中断模块18，具体用于通过网卡组件对网卡接收队列中的数据报文进行拦截中断处理，为拦截中断处理后的数据报文生成报文标识；

拦截中断模块18，还具体用于根据报文标识，将拦截中断处理后的数据报文均衡分配至至少两个工作线程分别对应的缓冲接收队列。

其中，集合生成模块11，第一处理模块12，第二处理模块13，规则匹配模块14，第一匹配模块15，第二匹配模块16，报文存放模块17和拦截中断模块18的具体实现方式，可以参见上述图3所对应实施例中对步骤S101-步骤S103、图5所对应实施例中对步骤S201-步骤S203以及图6所对应实施例中对步骤S301-步骤S310的描述，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

进一步地，请参见图10，图10是本申请实施例提供的一种网元设备的结构示意图。如图10所示，该网元设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，上述网元设备1000还可以包括：至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。可选的，网络接口1004可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatilememory)，例如至少一个磁盘存储器。可选的，存储器1005还可以是至少一个位于远离前述处理器1001的存储装置。如图10所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块以及设备控制应用程序。

在如图10所示的网元设备1000中，网络接口1004可提供网络通讯功能；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：

在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；同一个数据报文集合中的数据报文具有相同的报文格式；

若数据报文集合中存在内核数据报文，则在工作线程中，根据访问控制规则将内核数据报文分流至内核态线程，通过内核态线程对内核数据报文进行流转处理；

若数据报文集合中存在业务数据报文，则在工作线程中，根据访问控制规则将业务数据报文分流至工作线程中的一个或多个报文处理节点，通过一个或多个报文处理节点对业务数据报文进行流转处理。

应当理解，本申请实施例中所描述的网元设备1000可执行前文图3、图5或图6所对应实施例中对数据处理方法的描述，也可执行前文图9所对应实施例中对数据处理装置1的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且计算机可读存储介质中存储有前文提及的数据处理装置1所执行的计算机程序，且计算机程序包括程序指令，当处理器执行程序指令时，能够执行前文图3、图5或图6所对应实施例中对数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。

上述计算机可读存储介质可以是上述实施例提供的数据处理装置1或者上述网元设备的内部存储单元，例如网元设备的硬盘或内存。该计算机可读存储介质也可以是该网元设备的外部存储设备，例如该网元设备上配备的插接式硬盘，智能存储卡(smart mediacard，SMC)，安全数字(secure digital，SD)卡，闪存卡(flash card)等。进一步地，该计算机可读存储介质还可以既包括该网元设备的内部存储单元也包括外部存储设备。该计算机可读存储介质用于存储该计算机程序以及该网元设备所需的其他程序和数据。该计算机可读存储介质还可以用于暂时地存储已经输出或者将要输出的数据。

此外，需要说明的是：本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序可以包括计算机指令，该计算机指令可以存储在计算机可读存储介质中。网元设备的处理器从计算机可读存储介质读取该计算机指令，处理器可以执行该计算机指令，使得该网元设备执行前文图3、图5或图6所对应实施例中对数据处理方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品或者计算机程序实施例中未披露的技术细节，请参照本申请方法实施例的描述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (15)

1.一种数据处理方法，其特征在于，包括：

在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；同一个数据报文集合中的数据报文具有相同的报文格式；

若所述数据报文集合中存在内核数据报文，则在所述工作线程中，根据访问控制规则将所述内核数据报文分流至内核态线程，通过所述内核态线程对所述内核数据报文进行流转处理；

若所述数据报文集合中存在业务数据报文，则在所述工作线程中，根据所述访问控制规则将所述业务数据报文分流至所述工作线程中的一个或多个报文处理节点，通过所述一个或多个报文处理节点对所述业务数据报文进行流转处理。

2.根据权利要求1所述的方法，其特征在于，所述在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合，包括：

在用户态下的工作线程中，对所述工作线程对应的缓冲接收队列进行轮询，识别轮询得到的数据报文的报文格式；所述报文格式包括目标报文格式；

若具有所述目标报文格式的数据报文的报文数量大于或等于数量阈值，则基于具有所述目标报文格式的数据报文，生成所述目标报文格式对应的数据报文集合。

3.根据权利要求1所述的方法，其特征在于，所述访问控制规则包括属于访问控制列表中的内核报文匹配规则和业务报文匹配规则；

所述方法还包括：

将所述数据报文集合发送至所述工作线程中的访问控制节点，在所述访问控制节点中，基于所述访问控制列表对所述数据报文集合中的数据报文进行匹配；

若所述数据报文集合中存在与所述内核报文匹配规则相匹配的数据报文，则确定所述数据报文集合中存在内核数据报文；

若所述数据报文集合中存在与所述业务报文匹配规则相匹配的数据报文，则确定所述数据报文集合中存在业务数据报文。

4.根据权利要求3所述的方法，其特征在于，所述将所述数据报文集合发送至所述工作线程中的访问控制节点，包括：

将所述数据报文集合中的数据报文加载至数据缓存，在所述数据缓存中依次对所述数据报文集合中的数据报文进行报文检测；

若报文检测出所述数据报文集合中存在检验成功的数据报文，则将所述检验成功的数据报文发送至所述工作线程中的访问控制节点；

则所述方法还包括：若报文检测出所述数据报文集合中存在检验失败的数据报文，则将所述检验失败的数据报文发送至失败处理节点。

5.根据权利要求4所述的方法，其特征在于，所述将所述数据报文集合中的数据报文加载至数据缓存，在所述数据缓存中依次对所述数据报文集合中的数据报文进行报文检测，包括：

将所述数据报文集合中的数据报文加载至数据缓存，从所述数据缓存中获取所述数据报文集合的数据报文S_i；所述i为小于或等于所述数据报文集合中的数据报文的报文数量的正整数；

获取所述数据报文S_i对应的报文处理指令，将所述报文处理指令加载至指令缓存，通过所述指令缓存中的所述报文处理指令对所述数据报文S_i进行报文检测；

从所述数据缓存中获取所述数据报文集合的数据报文S_i+1，从所述指令缓存中获取所述报文处理指令，通过所述报文处理指令对所述数据报文S_i+1进行报文检测。

6.根据权利要求1所述的方法，其特征在于，一个或多个报文处理节点包括路由匹配节点；

所述若所述数据报文集合中存在业务数据报文，则在所述工作线程中，根据所述访问控制规则将所述业务数据报文分流至所述工作线程中的一个或多个报文处理节点，通过所述一个或多个报文处理节点对所述业务数据报文进行流转处理，包括：

若所述数据报文集合中存在业务数据报文，则在所述工作线程中，根据所述访问控制规则将所述业务数据报文分流至所述工作线程中的所述路由匹配节点；

通过所述路由匹配节点对所述业务数据报文携带的目的地址进行路由匹配，得到所述业务数据报文对应的路由数据报文；

对所述路由数据报文进行报文协议解析。

7.根据权利要求6所述的方法，其特征在于，所述一个或多个报文处理节点还包括第一报文解析节点和第二报文解析节点；

所述对所述路由数据报文进行报文协议解析，包括：

识别与所述路由数据报文相关联的报文协议类型；

若所述报文协议类型为通用路由封装协议类型，则将所述路由数据报文发送至所述第一报文解析节点，通过所述第一报文解析节点对所述路由数据报文进行报文协议解析；

若所述报文协议类型为虚拟扩展局域网协议类型，则将所述路由数据报文发送至所述第二报文解析节点，通过所述第二报文解析节点对所述路由数据报文进行报文协议解析。

8.根据权利要求6所述的方法，其特征在于，所述一个或多个报文处理节点还包括策略节点和隧道处理节点；

所述方法还包括：

获取经过报文协议解析所得到的解析数据报文，将所述解析数据报文发送至所述策略节点，通过所述策略节点对所述解析数据报文进行策略控制，得到策略控制后的解析数据报文；

将所述策略控制后的解析数据报文发送至所述隧道处理节点，通过所述隧道处理节点对所述策略控制后的解析数据报文进行隧道处理，得到加密数据报文；

将所述加密数据报文发送至网卡组件对应的网卡发送队列。

9.根据权利要求8所述的方法，其特征在于，所述将所述加密数据报文发送至网卡组件对应的网卡发送队列，包括：

通过所述隧道处理节点将所述加密数据报文添加至所述工作线程对应的缓冲发送队列；

通过网卡组件获取所述缓冲发送队列中的加密数据报文，将所述网卡组件所获取到的加密数据报文存放至所述网卡组件对应的网卡发送队列。

10.根据权利要求1所述的方法，其特征在于，所述方法还包括：

通过网卡组件获取数据报文，将所述网卡组件所获取到的数据报文存放至所述网卡组件对应的网卡接收队列；

通过所述网卡组件对所述网卡接收队列中的数据报文进行拦截中断处理，将拦截中断处理后的数据报文均衡分配至所述缓冲接收队列。

11.根据权利要求10所述的方法，其特征在于，所述工作线程的线程数量为至少两个，至少两个工作线程中的每个工作线程对应于一个缓冲接收队列；

所述通过所述网卡组件对所述网卡接收队列中的数据报文进行拦截中断处理，将拦截中断处理后的数据报文均衡分配至所述缓冲接收队列，包括：

通过所述网卡组件对所述网卡接收队列中的数据报文进行拦截中断处理，为拦截中断处理后的数据报文生成报文标识；

根据所述报文标识，将所述拦截中断处理后的数据报文均衡分配至所述至少两个工作线程分别对应的缓冲接收队列。

12.一种数据处理装置，其特征在于，包括：

集合生成模块，用于在用户态下的工作线程中，基于缓冲接收队列中的数据报文，生成数据报文集合；同一个数据报文集合中的数据报文具有相同的报文格式；

第一处理模块，用于若所述数据报文集合中存在内核数据报文，则在所述工作线程中，根据访问控制规则将所述内核数据报文分流至内核态线程，通过所述内核态线程对所述内核数据报文进行流转处理；

第二处理模块，用于若所述数据报文集合中存在业务数据报文，则在所述工作线程中，根据所述访问控制规则将所述业务数据报文分流至所述工作线程中的一个或多个报文处理节点，通过所述一个或多个报文处理节点对所述业务数据报文进行流转处理。

13.一种网元设备，其特征在于，包括：处理器、存储器以及网络接口；

所述处理器与所述存储器、所述网络接口相连，其中，所述网络接口用于提供数据通信功能，所述存储器用于存储程序代码，所述处理器用于调用所述程序代码，以使所述网元设备执行权利要求1-11任一项所述的方法。

14.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行权利要求1-11任一项所述的方法。

15.一种计算机程序产品，其特征在于，所述计算机程序产品包括计算机指令，该计算机指令存储在计算机可读存储介质中，且适于由处理器读取并执行，以使得具有所述处理器的网元设备执行权利要求1-11任一项所述的方法。

Images