一种易扩展的多方式融合的核心网用户流量应用识别方法

摘要

一种易于扩展的多方式融合的核心网用户流量应用识别方法，包括层次化的数据报文解析和识别还原隧道流量；解析管理IP层和传输层协议的五元组信息；根据流节点信息，采用预识别、端口识别、HTTP识别、P2P识别和PA识别方法融合的应用识别方法，获取数据报文及其所属数据流的具体应用信息。各识别方法支持单独扩展，并且将处理逻辑简单，响应速度快的识别方法前置，降低后续复杂方法的识别负荷，提高识别处理效率；HTTP支持二级识别，提升识别的有效性和准确性；同时支持DPI和DFI的识别方式，有效识别加密应用协议和P2P协议数据流。

说明书

技术领域

本发明涉及通信网络流量识别领域，更具体的，本发明涉及一种易于扩展的多方法融合的核心网实时用户流量应用识别方法。 

背景技术

为了了解通信网络中，不同网络应用的使用情况和对带宽的占用情况，从而进行有效的流量监控或者网络用户分析，必须首先对通信网络数据流量进行有效的识别。

传统的通信网络用户流量应用识别技术主要有2种，深度包检测（Deep Packet Inspection, DPI）和深度流检测（Deep Flow Inspection, DFI）。

DPI是通过深度读取报文荷载的内容来识别报文，DPI除了对报文L2（数据链路层）、L3（网络层）、L4（传输层）的内容进行分析外，还增加了对L7（应用层）内容的分析，因此可以通过针对知名端口进行应用协议识别，或者基于应用层协议特征码来进行识别。

DFI与DPI进行载荷匹配不同，它采用的是一种基于流量行为的应用识别技术。由于不同的应用类型在会话连接或数据流上的状态各有不同，DFI利用这样的特性进行应用识别。特别是针对通信网络中采用加密协议的应用，或者P2P协议的应用，DFI有着DPI不可比拟的效果。

现今通信网络中的用户上网业务流量中的应用类型纷繁复杂，各种各样的应用所采用的协议及其特征也相差甚远。因此，不论是那种应用识别方法，都有一定的局限性，不能覆盖全部的应用协议类型。再者，通信网络中对用户业务数据的识别要求，已经不仅仅指的是协议的识别，而是更偏向于内容层面的应用识别。例如，很多移动终端第三方应用程序（APP），或者网络视频应用，都会采用HTTP协议进行内容的承载，因此，仅仅识别出HTTP协议显然是不够的。最后，核心网用户业务数据的数量级非常大，但是应用识别需要达到实时效果。

发明内容

为了克服传统单一应用识别方法的局限性，以及满足实时识别的要求，本发明提出了一种应用识别方法，针对通信网络业务数据的特性，采用多种识别方式按设计顺序结合使用的方法进行应用识别，以提升识别率。同时，该方法易于灵活的进行横向扩展，提升现网数据实时识别的处理能力。

本发明的技术方案提供一种易于扩展的多方式融合的核心网用户流量应用识别方法，对接收到的数据报文依次进行识别处理，对某数据报文的识别处理包括以下步骤，

步骤一，从Ethernet II层开始解析，得到IP层开始的业务数据；

步骤二，开始解析IP层和传输层协议，得到数据流五元组信息；

步骤三，根据步骤二所得数据流五元组信息，若数据流节点已存在，并且所代表数据流应用类型已识别，则当前识别处理流程结束，其他情况均继续进行应用识别过程，应用识别过程包括依次执行预识别子过程、端口识别子过程、HTTP识别子过程、P2P识别子过程和PA识别子过程，在某个识别子过程识别出具体的协议类型，则当前识别处理流程结束；

所述预识别子过程，包括根据数据包信息判断当前流是否匹配已识别出的应用协议的控制流所指定的数据流，若为肯定结果则成功识别出应用类型，则当前识别处理流程结束，若为否定结果则进入后续识别子过程；

所述端口识别子过程，包括根据常用端口特征识别协议类型，若成功识别出应用类型则当前识别处理流程结束，若为否定结果则进入后续识别子过程；

所述HTTP识别子过程，包括根据HTTP的协议规范，利用HTTP中简单特征进行初级匹配，若匹配失败，则说明该流量为非HTTP业务，进入后续识别子过程；若匹配成功，则说明该流为HTTP业务，进行特征串匹配，匹配成功则得到使用HTTP协议的具体应用类型，识别结束，否则标记为“HTTP协议”，识别结束；所述特征串匹配是根据各类使用HTTP协议的应用的头域特征进行匹配；

所述P2P识别子过程，包括针对P2P协议及P2P数据的特性，同时采用DPI和DFI的方式进行识别和统计，当识别为非P2P流时进入后续识别子过程；当识别为P2P流时识别匹配的P2P协议，若成功识别则得到使用P2P协议的具体应用类型，识别结束，否则标记为“P2P协议”，识别结束；

所述PA识别子过程，包括根据预先设定的特征规则进行识别。

而且，所述端口识别子过程的实现包括以下子步骤，

步骤A021，接收IP层起始数据报文及其对应数据流信息，判断接收到的数据流是否是TCP流，是则进入步骤A022，否则进入步骤A023；

步骤A022，在tcp_port_list中查找svrPort信息，找到则得到对应应用类型，识别结束；否则在tcp_port_list中查找msPort信息，找到则得到对应应用类型，识别结束，否则进入后续识别子过程；

步骤A023，在udp_port_list中查找svrPort信息，找到则得到对应应用类型，识别结束；否则在udp_port_list中查找msPort信息，找到则得到对应应用类型，识别结束，否则进入后续识别子过程；

其中，svrPort指数据报文服务端端口信息，msPort指数据报文客户端端口信息，表tcp_port_list保存TCP流的端口表达式规则，表udp_port_list保存UDP流的端口表达式规则。

而且，所述HTTP识别子过程中，进行特征串匹配使用正则匹配方法实现。

而且，所述P2P识别子过程的实现包括以下子步骤，

步骤A041，接收IP层起始数据报文及其对应数据流信息；

步骤A042，提取出数据报文的源IP地址msAddr和源端口msport，判断五元组的源IP地址和源端口对(msaddr，msport)是否存在于p2p_ip_port_set中，若存在，则转入步骤A048；若不存在，则继续步骤A043；其中，p2p_ip_port_set是存放源IP地址和源端口对的集合；

步骤A043，设is_tcp_udp_flag保存flow用到的承载协议类型，判断当前数据包的IP地址对是否同时存在于TCP数据流和UDP数据报文中，若不是则更新is_tcp_udp_flag的状态，进入后续识别子过程，若是则继续步骤A044；

步骤A044，记录存储源IP地址和端口对(msaddr，msport)连接到的各个(IP,PORT)对；

步骤A045，判断数据流的总长度是否大于2MB，若不是，则进入后续识别子过程；若是，则继续步骤A045；

步骤A046；判断是否源(IP, PORT)连接到的目地IP数目和目地PORT数目之间的差值小于相应的阈值，是则为P2P流，继续步骤A045；否则为非P2P流，进入后续识别子过程；

步骤A047，将数据流的源IP地址和端口对(msaddr,msport)加入p2p_ip_port_set；

步骤A048，利用DPI方法对P2P流进行更细化的分类，成功则找到具体的P2P应用，识别结束，若否则标记为“P2P协议”，识别结束。 

而且，所述PA识别子过程的实现利用DPI方法。

而且，所述DPI方法包括以下子步骤，

步骤A051，接收IP层起始数据报文及其对应数据流信息；

步骤A052，判断当前数据报文的端口值是否存在于容器tcp_proto_list/udp_proto_list中，若存在，则按照容器tcp_proto_list/udp_proto_list所存储的特征进行匹配，即继续进行步骤A053；否则，跳转进行步骤A054；所述容器tcp_proto_list和udp_proto_list分别用于存放与TCP协议、UDP协议相应含有端口信息的特征规则，根据步骤二解析结果选用其中之一；

步骤A053，与容器tcp_proto_list/udp_proto_list所存储的特征进行遍历匹配，若匹配某一条规则的所有特征表达式要求，则识别结果为匹配规则条目所对应的应用类型，识别结束；若直至遍历结束也未找到匹配规则，则数据报文及其对应的数据流识别结果暂时为未知，识别结束；

步骤A054，与容器tcp_proto/udp_proto所存储的特征进行遍历匹配，若匹配某一条规则的所有特征表达式要求，则识别结果为匹配规则条目所对应的应用类型，识别结束；若直至遍历结束也未找到匹配规则，则数据报文及其对应的数据流识别结果暂时为未知，识别结束；所述容器tcp_proto和udp_proto分别用于存放与TCP协议、UDP协议相应不含有端口信息的特征规则，根据步骤二解析结果选用其中之一。

本发明采用过滤式的多方法融合的应用识别方式，将处理逻辑简单，响应速度快的识别方法前置，降低后续复杂方法的识别负荷，提高识别处理效率；支持对通信网络中使用HTTP协议的大量应用进行二级扩展识别，而不是简单的将该类应用归类为HTTP协议，有效提升识别的有效性和准确性；同时支持DPI和DFI的识别方式，可以有效识别出加密应用协议和大量无明显特征的P2P协议数据流；根据通信网络流量的分布情况和各方法处理能力，能够灵活方便的独立横向扩展各识别方法。本发明适于应用在移动分组域数据信息采集系统和LTE综合分析系统中。

附图说明

图1为本发明实施例的应用识别整体流程图。

图2为本发明实施例的预识别方法处理流程图。

图3为本发明实施例的端口识别方法处理流程图。

图4为本发明实施例的HTTP识别方法处理流程图。

图5为本发明实施例的P2P识别方法处理流程图。

图6为本发明实施例的PA识别方法处理流程图。

具体实施方式   

以下根据附图和实施例对本发明具体实现进行说明。

本发明实施例的基本原理为：关注源IP地址、目的IP地址、源端口、目的端口和应用层协议（TCP/UDP）五元组所确定的流，每一个数据报文一定属于且仅属于一个流，并且一个流由同一个应用所产生。本发明实施例按照网络协议的分层特性，很自然的使用分层模型。即对网络层、传输层、应用层进行层次化处理。直至解析到应用层数据后，根据获得的源IP地址、目的IP地址、源端口、目的端口和应用层协议（TCP/UDP）所组成的五元组，找到业务数据包所属的流节点。然后再使用过滤式的多方法融合的层次化识别方法，对数据报文/数据流依次进行预识别、端口识别、HTTP识别、P2P识别和PA识别。

参见图1，是本发明实施例的应用识别整体流程图。包括以下步骤：

步骤一，将业务数据从Ethernet II层开始解析，自动识别、还原网络中的隧道协议内封装的正常流量： 接收到数据报文后，首先层次化的解析报文。根据Ethernet II桢格式和各隧道协议结构获取以IP层为起始位置的报文。例如，如果Ethernet II层type字段的值为0x8100，那么该数据报文的Ethernet II上层隧道协议为VLAN，需要根据VLAN的帧结构进行解析。

实施例从前端收到的业务数据（读取或抓取网络数据包）从Ethernet II层开始解析，首先检查各数据的合理性，并且支持自动识别、还原网络中的隧道协议（VLAN, PPPoE, MPLS, GRE, GTP等）内封装的正常流量，最后得到IP层开始的业务数据。

步骤二，然后开始解析IP层和传输层协议，得到数据流五元组信息：经过步骤一最终得到实际业务数据以IP层为起始的报文，接着，根据IP层头部结构，获取数据报文的源IP和目的IP。这里，IP层的版本可能为IPv4或者IPv6。如果为IPv4，那么源IP和目的IP地址长度皆为4个字节；如果为IPv6，IP地址的皆为16个字节。同时，根据IP层所指示的上层协议类型，可以得到该数据报文的传输层协议类型（UDP或者TCP）。相应的，根据传输层协议的头结构，解析得到数据报文的源端口和目的端口信息，查找更新五元组TCP流节点或更新五元组UDP流节点。至此，得到了数据报文的五元组信息。

实施例的实现如下：

首先解析IP层，并且进行长度的检查，接着解析其IP头信息，得到用户IP；

然后进行传输层的解析，实现传输层协议分类。

如果上层为TCP协议，那么解析TCP头，然后得到源端口（Port）和目的端口（Port）。所述五元组信息包括一对源、目的端口号信息，IP头中附带的源、目的IP地址对信息，以及传输层TCP协议。五元组唯一确定一个TCP流；实现查找更新五元组TCP流节点。

如果传输层解析为UDP协议，那么首先解析UDP头，然后得到源Port和目的Port，所述五元组信息包括一对源、目的端口号信息，IP头中附带的源、目的IP地址对信息，以及传输层UDP协议。五元组唯一确定一个UDP“流”（之后也用“流”这个概念称呼相同UDP五元组的数据包集合）；实现查找更新五元组UDP流节点。

步骤三，根据五元组管理数据流节点信息，若数据流节点已存在，并且所代表数据流应用类型已识别，则当前识别处理流程结束，其他情况均继续进行应用识别过程：本发明实施例根据五元组信息，查找该数据报文所属数据流，若该数据流属于未识别业务应用流，则进入应用识别过程，应用识别过程包括依次执行预识别子过程、端口识别子过程、HTTP识别子过程、P2P识别子过程和PA识别子过程，在中间某个识别子过程识别出具体的协议类型，则当前识别处理流程结束，否则运行完PA识别子过程后对当前数据报文处理才结束，可以继续对下一数据报文返回步骤一进行上述流程。

实施例的实现如下：

步骤A01，预识别，即根据数据包信息快速判断，当前流是否匹配已识别出的应用协议的控制流所指定的数据流。若为肯定结果，则成功识别出应用类型，识别过程结束；若为否定结果，则继续后续识别，即进入后续识别子过程；

步骤A02，端口识别，即根据常用端口特征快速识别协议类型。若成功识别出应用类型，则识别过程结束；若为否定结果，则继续后续识别；

步骤A03，HTTP识别，即根据HTTP的协议规范，针对HTTP的特性，采用一级与二级解析结合的方式，利用HTTP中GET/POST等简单特征对流进行初级匹配，若匹配失败，则说明该流量为非HTTP业务，则使用后续识别方法进行识别；若匹配成功，则说明该流为HTTP业务，同时进入二级识别——使用正则匹配方法进行特征串匹配。特征串匹配，是根据预先分析统计出的各类使用HTTP协议的应用的头域（Host, User-Agent, Referer,uri 等信息）特征，匹配当前数据包，以确定应用类型的方法；

步骤A04，P2P识别，即针对P2P协议及P2P数据的特性，同时采用DPI和DFI的方式进行识别和统计，为使用P2P协议的应用数据流打标，并可在识别出P2P流时进一步识别匹配的P2P协议，利用预先建立的P2P业务类型特征库进行精确协议识别，解析P2P数据；若成功识别为P2P应用协议，则识别过程结束；否则，则继续后续识别。

步骤A05，PA(Pattern Analysis)识别，即自定义数据包模式特征识别方法，用于根据预先设定的特征规则进行识别。根据数据包的端口、payload长度、特征串数值和偏移等信息，确定当前数据包所在流的应用类型；

步骤A06，结束过程。

具体实施时，对各数据报文可依次按以上步骤一、二、三进行处理。即对当前数据报文执行以上流程进行识别结束后，接收并处理下一个数据报文，重新执行步骤一、二、三进行识别。本领域技术人员可基于计算机软件技术，根据以上流程提供一个相应的软件系统，支持自动化运行流程，供用户安装使用，便于推广使用。

为提高识别效率，本发明提供进一步技术方案如下：

参见图2，预识别，即根据数据包信息快速判断，当前流是否匹配某个已识别出的应用协议的控制流所指定的数据流，流程可设计为：接收IP层起始数据报文及其对应数据流信息，判断是否匹配某控制流待识别的数据流，是则与对应控制流应用类型相同，识别结束，否则识别继续，即进入端口识别。本发明进行的数据流识别一般在控制流识别后进行，预先存储已经识别的应用协议控制流中所携带的对应数据流信息，则可根据存储信息进行预识别。例如，可以通过端口识别或者PA识别等预先识别出FTP协议的控制流，然后对FTP控制流中的数据报文进行解析，得到该控制流对应的FTP数据流的对应IP和端口信息，并进行存储；当该FTP数据流报文进入本发明实施例的流程进行识别时，会在预识别过程进行匹配，从而快速的将该数据流识别为FTP应用协议。类似的过程还存在于H323、SIP、RTSP等协议中。其中，存储控制流对应数据流的C++数据结构定义如下：

map<ip_tcpudp_pair_t, dc_ip_udp_node_t *> _sipCtls;

map<ip_tcpudp_pair_t, dc_ip_tcp_node_t *> _ftpCtls;   

map<ip_tcpudp_pair_t, dc_ip_tcp_node_t *> _h323Ctls;

map<ip_tcpudp_pair_t, dc_ip_tcp_node_t *> _rtspCtls;

分别表示的是SIP协议、FTP协议、H323协议和RTSP协议控制流中携带的数据流信息sipCtls、ftpCtls、h323Ctls、rtspCtls。

每个map结构的key值为数据流五元组信息ip_tcpudp_pair_t，value为协议控制流节点信息dc_ip_udp_node_t。

预识别方法未识别出来的数据报文流则继续后续的识别方法。

参见图3，端口识别方法根据端口特征，快速的进行数据报文的端口匹配。因此，具体实施时，本领域技术人员可预先建立一个端口特征库，其内容大部分为知名端口(Well Known Ports)，也常称为“常用端口”。这类端口的端口号从0到1024，固定分配给一些特定的服务，明确表明了某种应用服务的协议，通常不可再重新定义它的作用对象。例如，53端口实际上总是 DNS通信所使用的，而23号端口则是Telnet服务专用的。

本发明实施例系统开始运行时，会将端口特征库加载进程序内存中，结合图3中描述的结构名称，存储的C++语言结构如下所示：

static map<port_type_pair_t, unsigned int> tcp_port_list[2];

static map<port_type_pair_t, unsigned int> udp_port_list[2];

其中，表tcp_port_list保存TCP流的端口表达式规则；表udp_port_list保存UDP流的端口表达式规则。static是C++的一个关键字，指该对象是静态成员；map结构的key值port_type_pair_t为端口号及端口类型（客户端/服务器端）；unsigned int是C++的基本数据类型，整形，作为map结构的value值，保存的是该端口对应的应用类型编号。如图3所示，实施例具体的端口识别方法为：

步骤A021，接收IP层起始数据报文及其对应数据流信息，判断接收到的数据流是否是TCP流，TCP流一般记为“TCP Flow”。

将数据报文分流为TCP流和UDP流，不同传输层协议所对应的纯端口特征是不同的，因此数据流相应处理，分别进入步骤A022、步骤A023。

步骤A022，先根据数据报文服务端端口信息svrPort在tcp_port_list/ udp_port_list中查找有无对应的端口值，可在tcp_port_list中查找svrPort信息，找到则得到对应应用类型，识别结束；否则在tcp_port_list中查找msPort信息，找到则得到对应应用类型，识别结束，否则识别继续。 svrPort指数据报文服务端端口信息，msPort指数据报文客户端端口信息。

步骤A023，先根据数据报文客户端端口信息msPort在tcp_port_list/ udp_port_list中查找有无对应的端口值，可在udp_port_list中查找svrPort信息，找到则得到对应应用类型，识别结束；否则在udp_port_list中查找msPort信息，找到则得到对应应用类型，识别结束，否则识别继续。

端口识别方法中的识别继续即进入HTTP识别。

参见图4，HTTP识别方法的详细过程描述如下：

步骤A031，接收IP层起始数据报文及其对应数据流信息；

步骤A032，匹配GET/POST等HTTP的简单规则；

步骤A033，判断是否匹配成功，若否则识别继续，若是则进行HTTP特有特征串匹配，

步骤A034，判断是否匹配成功，若是则得到使用HTTP协议的具体应用类型，识别结束，若否则标记为“HTTP协议”，识别结束。

HTTP识别方法中的识别继续即进入P2P识别。

该方法针对HTTP的协议特征，采用一级识别与二级解析识别相结合的方式。识别匹配方式均采用PCRE(Perl Compatible Regular Expressions)库来实现。PCRE是一个Perl语言库，包括 perl 兼容的正则表达式库，是一个成熟的封装完备的正则匹配库，可以较好的解决C/C++语言中使用正则表达式的问题。

与端口识别方法相似，HTTP识别的正常运行识别也需要维护HTTP特征相关的特征库，具体实施时，本领域技术人员可预先建立特征库。

在一级识别中，特征为正则表达式“(POST|GET|HEAD|PUT|CONNECT) .* HTTP/(0.9|1.0|1.1)”， “.*”是正则表达式的特殊字符，“.” 匹配除换行符外的所有单个的字符，“*” 匹配*前面的字符0次或n次，“/”匹配字符/。“(0.9|1.0|1.1)”的含义是匹配0.9或1.0或1.1中的任意一个。该正则表达式可以匹配这样的数据报文的payload部分：以POST/GET/HEAD/PUT/CONNECT中任意一个字符串开始，中间可以是任意字符，以HTTP/加上0.9/1.0/1.1中任意一个字符串结束。“POST/GET/HEAD/PUT/CONNECT”是HTTP协议中的特征字段。

因此，正则表达式描述的特征对应于数据报文的payload部分，判断报文payload部分是否以POST/GET/HEAD/PUT/CONNECT为起始。如果匹配其中一个，则初步判断当前数据报文及其所在数据流为HTTP协议。本发明实施例系统没有像大部分的传统HTTP协议识别方法那样，采用传输层为TCP协议和服务端端口为80端口结合的方式来进行协议识别，而是直接对内容进行判断。因为，现今通信网络中，很多常用应用（例如微信、ECP、易信、快播等）都采用TCP协议和80端口进行通信，但是它们并不使用HTTP协议。本发明实施例系统中的HTTP识别一级识别过程，可以有效的过滤掉上述类型的应用，无需再进行无意义的二级识别，提高了效率和准确性。若匹配失败，则说明该流量为非HTTP业务，则使用后续识别方法进行识别；若匹配成功，则说明该流为HTTP业务，同时进入二级识别——使用正则匹配方法进行特征串匹配。

在二级识别中，需要维护一个包含应用类型及其对应的HTTP头部字段特征库。例如，即时通信软件QQ的HTTP正则特征为Host字段中含有”qq”字符串，同时，User-Agent字段中含有“QQ|QQClinet“字符串。本发明实施例系统开始运行时，会将端口特征库加载进程序内存中，结合图4中的描述，在“HTTP特有特征串匹配阶段”对HTTP头部提取出来的各字段进行正则匹配。数据报文提取出的字段，存储的C++语言结构如下所示：

map<string, string> m_http_upField;

map<string, string> m_http_downField;

用map结构分别存放解析某数据流上行和下行数据报文的http头部字段内容m_http_upField、m_http_downField。map的key值为字段名（例如HTTP协作中的Host, User-Agent, Referer,uri 等）；map的value值为key值字段所对应的内容信息。

在二级识别过程中未匹配成功的数据流，无法标记为除HTTP协议以外更具体的应用类型，那么此时的数据流就仅标记为HTTP协议，识别结束。此时，可能数据流为普通的HTTP页面浏览应用；也可能是其他的应用类型。后者的情况下，需要更新特征库文件。

参见图5，针对经过HTTP识别方法的处理后，应用协议类型仍然未知的数据报文及其对应数据流，本发明实施例采用基于DFI和DPI相结合的P2P识别方法来继续对数据报文进行识别。图5中描述的存储结构的C++语言结构如下所示：

set<ms_addr_port>    p2p_ip_port_set;

int is_tcp_udp_flag;

其中，ms_addr_port结构是源IP地址和源端口对。p2p_ip_port_set是一个存放源IP地址和源端口对的集合，已经判定为P2P流量的(IP, PORT)对都存储于该集合中。is_tcp_udp_flag保存当前报文的源/目的IP地址对存在于传输层协议类型的统计状态：0为初始值；1表示仅存在于TCP数据流中；2表示仅存在于UDP数据报文中；3表示同时存在于TCP数据流和UDP数据报文中。

步骤A041，接收IP层起始数据报文及其对应数据流信息：接收到目前为止仍然未识别出应用类型的数据报文及其对应数据流信息，其中，数据报文内容从IP层起始；

步骤A042，判断五元组的(msAddr，msport)是否在p2p_ip_port_set中：提取出数据报文的源IP地址msAddr和源端口msport，判断源IP地址和源端口对(msaddr，msport)是否存在于p2p_ip_port_set中。若存在，则转入步骤A048；若不存在，则继续步骤A043；

步骤A043，判断is_tcp_udp_flag的状态，当前flow是否同时包含TCP和UDP？判断当前数据包的IP地址对（源/目的IP地址对）是否同时存在于TCP数据流和UDP数据报文中，is_tcp_udp_flag保存flow用到的承载协议类型。若不是，则更新is_tcp_udp_flag的状态（可根据当前is_tcp_udp_flag的状态及当前包承载协议类型更新is_tcp_udp_flag的状态），识别继续，即退出P2P识别方法，进行后续PA识别；若是，则转入继续步骤A044；

步骤A044，记录源(msaddr,msport)连接到的各个ip、port：实施例记录存储源IP地址和端口对(msaddr，msport)连接到的各个(IP,PORT)对；

步骤A045，判断数据流的总长度是否大于2MB，若不是，则识别继续，即退出P2P识别方法，进行后续PA识别；若是，则继续步骤A045；

步骤A046；判断是否连接到的ip与port的差数<阈值D? 

根据步骤A044所记录存储源IP地址和端口对(msaddr，msport)连接到的各个(IP,PORT)对，可获得源(IP, PORT)（即源(msaddr,msport)）连接到的目地IP数目、目地PORT数目，两者的差值小于阈值（具体实施时，本领域技术人员可预设阈值取值方式，例如在连接到的目地IP数目与目地PORT数目均大于20时，阈值取10），是则为P2P流，继续步骤A045；否则为非P2P流，该flow不再继续P2P识别处理，对数据报文进行后续识别；

步骤A047，将当前流的源IP地址和端口对(msaddr,msport)加入p2p_ip_port_set；

步骤A048，利用DPI方法对P2P流进行更细化的分类，识别结束。P2P协议分类，判断是否找到匹配的P2P协议？若是则找到具体的P2P应用，识别结束，若否则因无法标记为除P2P协议以外更具体的应用类型，此时的数据流仅标记为P2P协议，识别结束。 

其中，步骤A048中所使用的DPI方法与后续PA识别方法一致，仅仅是特征库的范围为使用P2P协议的应用协议特征库，具体实施时，本领域技术人员可根据相关协议预先建立该特征库，存放含有端口信息的特征规则的容器和存放不含有端口信息的特征规则可分别称为p2p_proto_list、p2p_proto。具体的实现和处理方式见下文描述。

P2P识别方法中的识别继续即进入PA识别。

参见图6，本发明实施例的最后一个识别方法为PA识别方法。PA(Pattern Analysis，模式识别)是本发明自定义的一个识别方式。它主要采用DPI的识别方法，即对数据报文的payload内容和信息与特征库进行特征匹配。特征库为本发明实施例前期需要分析统计和维护的各类应用的Pattern信息，具体实施时，本领域技术人员可预先建立特征库。例如，数据报文的端口、payload长度、特征串的值及其在payload中的偏移等等。本发明实施例系统开始运行时，加载特征库，在内存存储特征库的信息。图6中描述的存储结构的C++语言结构如下所示：

vector<proto_record *> tcp_proto[2];

vector<proto_record *> udp_proto[2];

map<port_type_pair_t, proto_info *> tcp_proto_list[2];

map<port_type_pair_t, proto_info *> udp_proto_list[2];

tcp_proto和udp_proto用于存放不含有端口信息的特征规则，即容器tcp_proto和udp_proto分别用于存放与TCP协议、UDP协议相应不含有端口信息的特征规则，根据步骤二解析结果选用其中之一。它们均是C++的vector结构类型，vector结构中存储的数据类型为proto_record，它是自定义的单条特征规则的储存结构，其定义如下：

typedef struct proto_record_t proto_record;

struct proto_record_t

{

       unsigned int app_proto;                  /* 应用类型ID */

       unsigned short flag_total_len;    /* 数据报文总长度特征 */

                     unsigned short datalen_offset;    /* 数据报文payload程度特征 */ 

       unsigned char byte_num;        /* 字节特征 */  

       unsigned char or_byte_num;     /* 选择字节特征 */

       unsigned char nbyte_num;      /* N(no) 一定不匹配的与字节特征 */  

       unsigned char or_nbyte_num;    /*N(no) 一定不匹配的或字节特征 */

       unsigned char exp_num;       /* 自定义表达式 */

       unsigned short str_offset;                           /* 字符串特征 */

       };

proto_record_t是proto_record的别名，tcp_proto_list和udp_proto_list用于存放同时有端口特征和其他表达式的特征规则，即用于存放含有端口信息的特征规则，即容器tcp_proto_list和udp_proto_list分别用于存放与TCP协议、UDP协议相应含有端口信息的特征规则，根据步骤二解析结果选用其中之一。它们均是C++的map结构类型，map的key为端口和应用类型对结构，map的value为实施例定义的proto_info结构，它是一组proto_record，即存放一组多条特征规则，其定义如下：

typedef struct proto_info_t   proto_info;

struct proto_info_t

{

       unsigned short record_num;                  /* 特征规则数目 */

       proto_record record_list[MAX_RECORD_NUM];

};

record_list指多条特征规则的集合。MAX_RECORD_NUM指最大特征规则数目。

如图6所示的具体的实现流程如下描述：

步骤A051，接收IP层起始数据报文及其对应数据流信息：接收到目前为止仍未识别出应用类型的数据报文及其对应数据流信息。其中，数据报文内容从IP层起始，提取数据报文中的IP地址、端口及payload部分信息；

步骤A052，判断是否满足特征中的端口信息：判断当前数据报文的端口值是否存在于容器tcp_proto_list/udp_proto_list中，若存在，则按照tcp_proto_list/udp_proto_list所存储的特征进行匹配，即继续进行步骤A053；否则，跳转进行步骤A054；

步骤A053，在tcp_proto_list/udp_proto_list容器中找到对应的信息进行匹配：与tcp_proto_list/udp_proto_list容器所存储的特征进行匹配，需要遍历proto_info中的每条规则，若匹配某一条规则的所有特征表达式要求，则识别结果为匹配规则条目所对应的应用类型；若直至遍历结束也未找到匹配规则，则数据报文及其对应的数据流识别结果暂时为未知。所有情况皆跳转到步骤A055；

步骤A054，在tcp_proto/udp_proto容器中找到对应的信息进行匹配：与tcp_proto/udp_proto容器所存储的特征进行匹配，需要遍历proto_record中的每条规则，若匹配某一条规则的所有特征表达式要求，则识别结果为匹配规则条目所对应的应用类型；若直至遍历结束也未找到匹配规则，则数据报文及其对应的数据流识别结果暂时为未知。继续进行步骤A055；

步骤A055，识别结束。

具体实施时，一般都需要对数据报文/数据流依次进行预识别、端口识别、HTTP识别、P2P识别和PA识别，根据具体情况也可以省略HTTP识别、P2P识别子过程。

本文中所描述的具体实施例仅仅是对本发明精神作举例说明。本发明所属技术领域的技术人员可以对所描述的具体实施例做各种各样的修改或补充或采用类似的方式替代，但并不会偏离本发明的精神或者超越所附权利要求书所定义的范围。