CN103023670B - 基于dpi的报文业务类型识别方法及装置 - Google Patents

Abstract

本发明公开了一种基于DPI的报文业务类型识别方法。该方法包括：步骤1，将业务报文的会话信息与会话记录表中的会话记录进行匹配，如果会话信息与某一条会话记录匹配成功，则从会话记录表中获取相对应的业务类型，如果未能从会话记录表中获取相对应的业务类型，则执行步骤2，如果未匹配成功，则在会话记录表中创建相应的会话记录，并执行步骤2；步骤2，将业务报文的会话信息与关联记录表中的关联记录进行匹配，如果会话信息与某一条关联记录匹配成功，则从关联记录表中获取与该关联记录相对应的业务类型，如果匹配不成功，则执行步骤3；步骤3，对业务报文的会话信息进行深层载荷分析，获取业务报文的业务类型。

Description

基于DPI的报文业务类型识别方法及装置

技术领域

本发明涉及计算机领域，特别是涉及一种基于深度包检测(Deep PacketInspection，简称为DPI)的报文业务类型识别方法及装置。

背景技术

目前，在互联网(Internet)业务中，业务是基于传输控制协议/因特网互联协议(Transmission Control Protocol/Internet Protocol，简称为TCP/IP)的。传统的业务识别方法是基于网络层国际互联网协议(Internet Protocol，简称为IP)的源地址、目标地址和协议类型及传输层的源端口和目标端口的组合来完成的，包括传输控制协议(Transmission Control Protocol，简称为TCP)或用户数据包协议(User DatagramProtocol，简称为UDP)两种。例如，会话中目的端口为80的TCP流可以认为是超文本传输协议(HyperText Transfer Protocol，简称为HTTP)，而目的端口为21的TCP流则可以认为是文件传输协议(File Transfer Protocol，简称为FTP)；而传统的DPI是在此基础上进行应用层的字符串特征匹配，如果能够匹配到某种协议的明文特征字符串，则认为该会话属于某种业务。例如，BT协议的握手报文中应用层以字符串“0x13BitTorrent protocol”开始。对于具有明确明文载荷特征的TCP或UDP报文，这种DPI有较高的识别率和准确率。

随着互联网的发展，各种私有协议和加密协议不断涌现，完全基于字符串匹配的DPI就很难识别出这些协议报文。但这些协议(特别是加密协议、点对点(Peer-To-Peer，简称为P2P类的协议)通常应用广泛并占据了网络中的大部分带宽，导致网络拥塞，影响了其他用户的正常业务，例如，HTTP、邮件(MAIL)、FTP等业务。因此，如果没有较好的技术来识别并控制这些协议，将会对网络的健康发展造成巨大的危害。

以SKYPE协议为例，SKYPE是一种分布式网络，SKYPE协议采用了先进的P2P技术、数据加密技术和压缩算法，保证任意两个SKYPE用户可以使用最小的宽带来传输优质的语音数据。SKYPE用户在登陆或通信的过程中，并不直接登陆到SKYPE服务器上，而是登陆到某个超级结点，并通过超级结点转发数据报文从而完成与SKYPE服务器或其他SKEYP用户之间的通信。这种方式可以很容易穿透防火墙，只要防火墙开通了80或443端口，SKYPE用户就可以穿透防火墙，与防火墙外边的用户进行通信。但是，如果要把80或443端口也给关闭了，那就会影响到网络中其他合法用户的正常上网。

现有的DPI技术中，除了对SKYPE极小的一部分数据流可以直接分析出来外，绝大部分SKYPE会话都无法识别出来，而随着网络业务的高速发展，运营商对DPI设备功能的要求也越来越高。

发明内容

本发明提供一种基于DPI的报文业务类型识别方法及装置，以解决现有技术中传统的DPI技术无法识别非公有协议报文的问题。

本发明提供一种基于DPI的报文业务类型识别方法，包括：

步骤1，接收业务报文，将业务报文的会话信息与预先设置的会话记录表中的会话记录进行匹配，如果会话信息与某一条会话记录匹配成功，则从会话记录表中获取与该会话记录相对应的业务类型，作为业务报文的业务类型，如果未能从会话记录表中获取与该会话记录相对应的业务类型，则执行步骤2，如果未匹配成功，则根据会话信息在会话记录表中创建相应的会话记录，并执行步骤2；

步骤2，将业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配，如果会话信息与某一条关联记录匹配成功，则从关联记录表中获取与该关联记录相对应的业务类型，作为业务报文的业务类型，如果匹配不成功，则执行步骤3；

步骤3，对业务报文的会话信息进行深层载荷分析，获取业务报文的业务类型。

本发明还提供了一种基于DPI的报文业务类型识别装置，包括：

会话记录匹配模块，用于接收业务报文，将业务报文的会话信息与预先设置的会话记录表中的会话记录进行匹配，如果会话信息与某一条会话记录匹配成功，则从会话记录表中获取与该会话记录相对应的业务类型，作为业务报文的业务类型，如果未能从会话记录表中获取与该会话记录相对应的业务类型，则调用关联记录匹配模块，如果未匹配成功，则根据会话信息在会话记录表中创建相应的会话记录，并调用关联记录匹配模块；关联记录匹配模块，用于将业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配，如果会话信息与某一条关联记录匹配成功，则从关联记录表中获取与该关联记录相对应的业务类型，作为业务报文的业务类型，如果匹配不成功，则调用深层载荷分析；

深层载荷分析，用于对业务报文的会话信息进行深层载荷分析，获取业务报文的业务类型。

本发明有益效果如下：

通过将业务报文的会话信息与会话记录表和关联记录表进行匹配来快速识别报文的业务类型，在匹配不成功的情况下再进行载荷深度分析获取业务类型，解决了现有技术中传统的DPI技术无法识别非公有协议报文的问题，能够快速、高效、准确地识别当前会话的业务类型。

附图说明

图1是本发明实施例的基于DPI的报文业务类型识别方法的流程图；

图2是本发明实施例的基于DPI的报文业务类型识别方法的详细处理的流程图；

图3是本发明实施例的载荷深层处理的流程图；

图4是本发明实施例的基于DPI的报文业务类型识别装置的结构示意图。

具体实施方式

为了解决现有技术中传统的DPI技术无法识别非公有协议报文的问题，本发明提供了一种基于DPI的报文业务类型识别方法及装置，在本发明实施例的技术方案中，根据协议的业务流量模型，在已经识别的会话基础上，动态设置会话记录表、以及一个或多个N组的关联器(即，关联记录表)，当该协议会话的后续报文再进入到DPI系统时，根据会话记录表和N组关联器的查询结果，可以快速、高效、准确地识别当前会话的业务类型。也就是说，通过对非公有协议(私有协议及加密协议)极小一部分数据流的识别和匹配，设置与用户相关的会话记录表，以及五元组关联器、四元组关联器及三元组关联器，可以在载荷没有明文特征的情况下识别出非公有协议业务的会话。以下结合附图以及实施例，对本发明进行进一步详细说明。应当理解，此处所描述的具体实施例仅仅用以解释本发明，并不限定本发明。

方法实施例

根据本发明的实施例，提供了一种基于DPI的报文业务类型识别方法，图1是本发明实施例的基于DPI的报文业务类型识别方法的流程图，如图1所示，根据本发明实施例的基于DPI的报文业务类型识别方法包括如下处理：

步骤101，接收业务报文，将业务报文的会话信息与预先设置的会话记录表中的会话记录进行匹配，如果会话信息与某一条会话记录匹配成功，则从会话记录表中获取与该会话记录相对应的业务类型，作为业务报文的业务类型，如果未能从会话记录表中获取与该会话记录相对应的业务类型，则执行步骤102，如果未匹配成功，则根据会话信息在会话记录表中创建相应的会话记录，并执行步骤102；

其中，会话信息包括：用户网络协议IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；会话记录包括：用户IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；

例如，当用户开始进行业务时，DPI系统收到该项业务的业务初始会话报文A1，根据A1的五元组信息(上述会话信息)查询会话记录表，并根据查询结果(开始会话记录表是可以没有记录的)创建该业务的会话记录。

当下一个业务报文A2到达时，根据A2的五元组信息查询会话记录表，根据查询的结果可知当前的业务类型为A。因为该会话已经被识别，因此，无需再查询关联器或进行更深层次地分析，直接将A作为该会话的业务结果返回。

步骤102，将业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配，如果会话信息与某一条关联记录匹配成功，则从关联记录表中获取与该关联记录相对应的业务类型，作为业务报文的业务类型，如果匹配不成功，则执行步骤103；

其中，关联记录表包括：五元组关联记录表、四元组关联记录表、和/或三元组关联记录表，其中，五元组关联记录表中的关联记录包括：用户IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；四元组关联记录表中的关联记录包括：用户IP地址、用户端口号、网络IP地址、以及协议类型；三元组关联记录表中的关联记录包括：用户IP地址、用户端口号、以及协议类型。

在步骤102中，如果会话信息与某一条关联记录匹配成功，则从关联记录表中获取与该关联记录相对应的业务类型，作为业务报文的业务类型之后，还需要包括：将业务报文的业务类型保存到会话记录表中，并将业务类型与相应的会话记录设置对应关系。

在步骤102中，将业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配具体包括：将业务报文的会话信息依次与五元组关联记录表、四元组关联记录表和三元组关联记录表中的关联记录进行匹配，也就是说，首先对五元组关联器查询，如果能够查询成功，则以查询到业务类型作为当前会话的业务类型；如果查询不成功，则继续查询四元组关联器，并按此方法查询三元组关联器；如果业务报文的会话信息与某一关联记录表中的关联记录匹配成功，则不再继续与后续关联记录表进行匹配。

例如，如果DPI系统并未能知晓当前A1报文的业务类型，因此需要查询各种关联器。首先查询五元组关联器，查询不成功后，再查询四元组关联器，再查询不成功则进行三元组关联器的查询；

步骤103，对业务报文的会话信息进行深层载荷分析，获取业务报文的业务类型。

执行步骤103之后，可以进行如下处理：

将业务报文的业务类型保存到会话记录表中，并将业务类型与相应的会话记录设置对应关系。

根据业务报文的业务类型获取该业务的网络流量模型，并根据网络流量模型在关联记录表中创建相应的关联记录；将业务报文的业务类型保存到关联记录表中，并将创建的关联记录与业务类型设置对应关系。

举例说明，当前A1报文的业务类型未知，并对A1报文的载荷进行更进一步地深度分析和处理，确定当前A1报文被识别为业务类型A，已知该业务类型为一种P2P业务，根据事先对该业务的分析可以得知：该业务在运行的过程中会发起大量具有如下特征的数据流：1、流的创建都是在短时间内完成；2、用户端口和协议号与当前会话的用户端口和协议号保持一致或可以通过一定的规则转换获得。根据该业务的网络流量模型可知应该设置三元组关联器，即将当前会话的协议类型、用户地址和用户端口作为一条记录保存到三元组关联器表中。

当该业务的一个新会话报文A1'到达时，根据A1'的五元组信息查询会话表，根据查询的结果可知需要创建该会话记录。因会话尚未匹配，则首先查询五元组关联器，查询失败后，再查询四元组关联器，依然未能查询到可以匹配的四元组关联器记录；最后以当前会话的协议类型、用户IP地址和用户端口号查询三元组关联器，查询到满足条件的记录，根据三元组关联器的信息可知当前报文A1'所在的会话对应业务类型A。根据查询结果，首先将当前业务类型保存到会话记录表中，以后该会话后续报文到达时可快速地匹配；最后将当前匹配结果返回，不再进行更深层载荷分析和处理。

在本发明实施例中，会话记录和N元组关联器的关联记录都是有生存期的，不能永远存在记录表中，否则记录表就会很快被插满，从而影响到后续业务报文的识别。因此记录表中的数据就需要老化，数据既不能老化太快，也不能老化太慢，太快就会导致后续的报文查询之前的匹配结果不成功，影响到报文的识别；太慢会导致记录表会被插满，从而影响到新会话的识别和关联器的设置。为了解决上述问题，需要对会话记录和各种关联器记录进行老化，具体进行如下处理：1、在与会话记录表中的会话记录匹配成功或与关联记录表中的关联记录匹配成功的情况下，更新会话记录或关联记录的最后访问时间；也就是说，当会话记录查询成功或关联器查询成功后，需要更新当前查询匹配成功记录的时间戳值；2、以预订周期扫描会话记录表和关联记录表；3、获取会话记录表中各条会话记录以及关联记录表中各条关联记录的最后访问时间，分别将最后访问时间与当前时间进行比较，判断是否超过老化时长，如果超时，则将相应的会话记录或关联记录删除。其中，上述各种参数，例如老化时长、扫描周期等都可以根据实际情况进行动态调整。

此外，需要说明的是，在本发明实施例中，会话记录表的容量及各个关联记录表(关联器)的容量可以根据实际情况进行调整。

本发明实施例的技术方案为了对一些私有协议或加密协议(例如，P2P类协议)进行识别，引入了关联器的概念。在DPI识别过程中，根据对会话现有部分会话的分析和处理，得出当前会话属于某一种业务，再根据这种业务的网络业务流量模型，设置一个或多个N元组关联器，当业务后续的报文达到时，直接查询关联器匹配，而无需再进行深层的载荷分析。与现有技术相比，本发明实施例的技术方案分析了在DPI识别过程中，用户在实际业务使用当中可能发生的各种情况。无论业务如何演变，技术如何发展，基于网络业务流量模型的DPI系统总能根据现有的识别技术在识别出业务的部分流量后，根据业务流量模型的原理识别出该业务的后续会话。

以下结合附图，对本发明实施例的上述技术方案进行详细说明。

图2是本发明实施例的基于DPI的报文业务类型识别方法的详细处理的流程图，如图2所示，包括如下处理：

步骤201，收到报文后，根据当前报文的五元组信息在会话记录表中查询；其中，用户地址是需要根据报文的上下行来确定：如果当前报文是上行报文时，则IP报文中的源IP地址为用户地址，否则目的地址为用户地址。如果当前报文所在的会话并不存在于会话记录表中，则根据当前五元组信息创建该会话记录，该会话记录包括：用户IP地址、网络IP地址、用户端口号、网络端口号和协议类型；

步骤201，判断当前报文会话识别情况，如果当前会话在此之前已经被识别，则执行步骤207；否则需要作进一步地分析，执行步骤203；

步骤203，根据当前会话的五元组信息查询五元组关联器，如果查询成功，则以查询到的业务ID作为当前会话的识别结果，并执行步骤206；否则继续执行步骤204；

步骤204，根据当前会话的四元组信息查询四元组关联器，包括：用户IP地址、用户端口号、网络IP地址及协议类型。如果查询成功，则以查询到的业务ID作为当前会话的识别结果，并执行步骤206；否则继续执行步骤205；

步骤205，根据当前会话的三元组信息查询三元组关联器，包括：用户IP地址、用户端口号、协议类型。如果查询成功，则以查询到的业务ID作为当前会话的识别结果，并执行步骤206；否则继续执行步骤208；

步骤206，根据当前N(N为3、4、5)组关联器的查询结果，设置当前会话的业务类型，以便进行后续会话的处理；

步骤207，根据当前会话的识别结果，设置DPI的返回结果，以便DPI调用者使用；

步骤208，将当前报文进行更深层载荷分析和处理，分析当前报文七层的载荷内容，确定当前会话所属的业务类型；处理完毕后执行步骤209；

步骤209，将当前报文的DPI识别结果返回。

图3是本发明实施例的载荷深层处理的流程图，主要是完成报文载荷的识别，根据报文载荷内容判断当前报文是由何种业务所产生，并根据当前业务的网络业务流量模型设置一个或多个N元组关联器。具体包括如下步骤：

步骤301，进行报文七层载荷分析，例如，协议特征的匹配，需要说明的是，在此步骤中，有可能是单个报文匹配，也有可能是多个报文在一起共同完成协议特征的匹配；

步骤302，根据当前载荷的深度分析后，判断当前会话是否匹配成功。如果未能匹配成功，则执行步骤309；

步骤303，根据当前识别业务类型的网络业务流量模型特征，判断当前会话是否需要设置五元组关联器。通常五元组关联器的设置需要在DPI系统正常启动时配置完成。例如，实时流传输协议(Real Time Streaming Protocol，简称为RTSP)控制面协商媒体面会话后，需要设置实时传送协议(Real-time Transport Protocol，简称为RTP)、RTP控制协议(RTP Control Protocol，简称为RTCP)或RDT的五元组关联器。如果需要设置五元组关联器则执行步骤306，否则执行步骤304；

步骤304，根据当前识别业务类型的网络业务流量模型特征，判断当前会话是否需要设置四元组关联器。通常四元组关联器的设置需要在DPI系统正常启动时配置完成。例如，文件传输协议(File Transfer Protocol，简称为FTP)控制面协商媒体面会话后，需要设置FTP数据(DATA)的四元组关联器。如果需要设置四元组关联器则执行步骤307，否则执行步骤305；

步骤305，根据当前识别业务类型的网络业务流量模型特征，判断当前会话是否需要设置三元组关联器。通常三元组关联器的设置需要在DPI系统正常启动时配置完成。例如，点对点(Point to Point，简称为P2P)类的SKYPE协议，该协议在登陆过程中会发起数十个甚至上百个网络连接，这些网络连接的共同点是用户端的端口号、协议类型相同，网络IP地址和网络端口号不同，而用户端的端口号可以通过识别SKYPE会话的某一个流得出。因此，DPI系统在识别出该会话后设置一个三元组关联器，从而达到将其他SKYPE会话匹配的目的。如果需要设置三元组关联器则执行步骤308，否则执行步骤309；

步骤306，提取需要设置五元组关联器的信息，信息来源不局限于当前会话的五元组信息，可能来源于当前报文载荷中的数据等，需要根据协议具体分析。设置完成后，执行步骤304；

步骤307，提取需要设置四元组关联器的信息，信息来源不局限于当前会话的五元组信息，可能来源于当前报文载荷中的数据等，需要根据协议具体分析。设置完成后，执行步骤305；

步骤308，提取需要设置三元组关联器的信息，信息来源不局限于当前会话的五元组信息，可能来源于当前报文载荷中的数据等，需要根据协议具体分析。设置完成后，执行步骤309；

步骤309，将当前报文的DPI识别结果返回。

借助于本发明实施例的技术方案，通过引入关联器的概念，在识别出业务的部分会话后，根据当前识别协议的网络业务流量模型，设置一种或多种N元组关联器，可以快速、高效及准确地匹配出该业务的后续会话。特别是对一些私有协议及加密的协议效果明显。

装置实施例

根据本发明的实施例，提供了一种基于DPI的报文业务类型识别装置，图4是本发明实施例的基于DPI的报文业务类型识别装置的结构示意图，如图4所示，根据本发明实施例的基于DPI的报文业务类型识别装置包括：会话记录匹配模块40、关联记录匹配模块42、以及深层载荷分析模块44，以下对本发明实施例的各个模块进行详细的说明。

会话记录匹配模块40，用于接收业务报文，将业务报文的会话信息与预先设置的会话记录表中的会话记录进行匹配，如果会话信息与某一条会话记录匹配成功，则从会话记录表中获取与该会话记录相对应的业务类型，作为业务报文的业务类型，如果未能从所述会话记录表中获取与该会话记录相对应的业务类型，则调用关联记录匹配模块42，如果未匹配成功，则根据会话信息在会话记录表中创建相应的会话记录，并调用关联记录匹配模块42；

其中，会话信息包括：用户网络协议IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；会话记录包括：用户IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；

例如，当用户开始进行业务时，会话记录匹配模块40收到该项业务的业务初始会话报文A1，根据A1的五元组信息(上述会话信息)查询会话记录表，并根据查询结果(开始会话记录表是可以没有记录的)创建该业务的会话记录。

当下一个业务报文A2到达时，会话记录匹配模块40根据A2的五元组信息查询会话记录表，根据查询的结果可知当前的业务类型为A。因为该会话已经被识别，因此，无需再查询关联器或进行更深层次地分析，直接将A作为该会话的业务结果返回。

关联记录匹配模块42，用于将业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配，如果会话信息与某一条关联记录匹配成功，则从关联记录表中获取与该关联记录相对应的业务类型，作为业务报文的业务类型，如果匹配不成功，则调用深层载荷分析模块44；

其中，关联记录表包括：五元组关联记录表、四元组关联记录表、和/或三元组关联记录表，其中，五元组关联记录表中的关联记录包括：用户IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；四元组关联记录表中的关联记录包括：用户IP地址、用户端口号、网络IP地址、以及协议类型；三元组关联记录表中的关联记录包括：用户IP地址、用户端口号、以及协议类型。

关联记录匹配模块42进一步用于：在会话信息与某一条关联记录匹配成功的情况下，将业务报文的业务类型保存到会话记录表中，并将业务类型与相应的会话记录设置对应关系；

关联记录匹配模块42具体用于：将业务报文的会话信息依次与五元组关联记录表、四元组关联记录表、和三元组关联记录表中的关联记录进行匹配，也就是说，首先对五元组关联器查询，如果能够查询成功，则以查询到业务类型作为当前会话的业务类型；如果查询不成功，则继续查询四元组关联器，并按此方法查询三元组关联器；如果业务报文的会话信息与某一关联记录表中的关联记录匹配成功，则不再继续与后续关联记录表进行匹配。

例如，如果并未能知晓当前A1报文的业务类型，因此关联记录匹配模块42需要查询各种关联器。首先查询五元组关联器，查询不成功后，再查询四元组关联器，再查询不成功则进行三元组关联器的查询；

深层载荷分析模块44，用于对业务报文的会话信息进行深层载荷分析，获取业务报文的业务类型。

深层载荷分析模块44进一步用于：在获取业务报文的业务类型之后，将业务报文的业务类型保存到会话记录表中，并将业务类型与相应的会话记录设置对应关系；根据业务报文的业务类型获取该业务的网络流量模型，并根据网络流量模型在关联记录表中创建相应的关联记录；将业务报文的业务类型保存到关联记录表中，并将创建的关联记录与业务类型设置对应关系。

举例说明，当前A1报文的业务类型未知，并对A1报文的载荷进行更进一步地深度分析和处理，确定当前A1报文被识别为业务类型A，已知该业务类型为一种P2P业务，根据事先对该业务的分析可以得知：该业务在运行的过程中会发起大量具有如下特征的数据流：1、流的创建都是在短时间内完成；2、用户端口和协议号与当前会话的用户端口和协议号保持一致或可以通过一定的规则转换获得。根据该业务的网络流量模型可知应该设置三元组关联器，即将当前会话的协议类型、用户地址和用户端口作为一条记录保存到三元组关联器表中。

当该业务的一个新会话报文A1'到达时，根据A1'的五元组信息查询会话表，根据查询的结果可知需要创建该会话记录。因会话尚未匹配，则首先查询五元组关联器，查询失败后，再查询四元组关联器，依然未能查询到可以匹配的四元组关联器记录；最后以当前会话的协议类型、用户IP地址和用户端口号查询三元组关联器，查询到满足条件的记录，根据三元组关联器的信息可知当前报文A1'所在的会话对应业务类型A。根据查询结果，首先将当前业务类型保存到会话记录表中，以后该会话后续报文到达时可快速地匹配；最后将当前匹配结果返回，不再进行更深层载荷分析和处理。

在本发明实施例中，会话记录和N元组关联器的关联记录都是有生存期的，不能永远存在记录表中，否则记录表就会很快被插满，从而影响到后续业务报文的识别。因此记录表中的数据就需要老化，数据既不能老化太快，也不能老化太慢，太快就会导致后续的报文查询之前的匹配结果不成功，影响到报文的识别；太慢会导致记录表会被插满，从而影响到新会话的识别和关联器的设置。为了解决上述问题，需要对会话记录和各种关联器记录进行老化，上述装置还包括：

老化删除模块，用于在会话记录匹配模块40匹配成功或与关联记录匹配模块42匹配成功的情况下，更新相应的会话记录或相应的关联记录的最后访问时间；也就是说，当会话记录查询成功或关联器查询成功后，需要更新当前查询匹配成功记录的时间戳值；以预订周期扫描会话记录表和关联记录表；获取会话记录表中各条会话记录以及关联记录表中各条关联记录的最后访问时间，分别将最后访问时间与当前时间进行比较，判断是否超过老化时长，如果超时，则将相应的会话记录或关联记录删除。其中，上述各种参数，例如老化时长、扫描周期等都可以根据实际情况进行动态调整。

此外，需要说明的是，在本发明实施例中，会话记录表的容量及各个关联记录表(关联器)的容量可以根据实际情况进行调整。

本发明实施例的技术方案为了对一些私有协议或加密协议(例如，P2P类协议)进行识别，引入了关联器的概念。在DPI识别过程中，根据对会话现有部分会话的分析和处理，得出当前会话属于某一种业务，再根据这种业务的网络业务流量模型，设置一个或多个N元组关联器，当业务后续的报文达到时，直接查询关联器匹配，而无需再进行深层的载荷分析。与现有技术相比，本发明实施例的技术方案分析了在DPI识别过程中，用户在实际业务使用当中可能发生的各种情况。无论业务如何演变，技术如何发展，基于网络业务流量模型的DPI系统总能根据现有的识别技术在识别出业务的部分流量后，根据业务流量模型的原理识别出该业务的后续会话。

以下结合附图，对本发明实施例的上述技术方案进行详细说明。

图2是本发明实施例的基于DPI的报文业务类型识别方法的详细处理的流程图，如图2所示，包括如下处理：

步骤201，收到报文后，根据当前报文的五元组信息在会话记录表中查询；其中，用户地址是需要根据报文的上下行来确定：如果当前报文是上行报文时，则IP报文中的源IP地址为用户地址，否则目的地址为用户地址。如果当前报文所在的会话并不存在于会话记录表中，则根据当前五元组信息创建该会话记录，该会话记录包括：用户IP地址、网络IP地址、用户端口号、网络端口号和协议类型；

步骤202，判断当前报文会话识别情况，如果当前会话在此之前已经被识别，则执行步骤207；否则需要作进一步地分析，执行步骤203；

步骤203，根据当前会话的五元组信息查询五元组关联器，如果查询成功，则以查询到的业务ID作为当前会话的识别结果，并执行步骤206；否则继续执行步骤204；

步骤204，根据当前会话的四元组信息查询四元组关联器，包括：用户IP地址、用户端口号、网络IP地址及协议类型。如果查询成功，则以查询到的业务ID作为当前会话的识别结果，并执行步骤206；否则继续执行步骤205；

步骤205，根据当前会话的三元组信息查询三元组关联器，包括：用户IP地址、用户端口号、协议类型。如果查询成功，则以查询到的业务ID作为当前会话的识别结果，并执行步骤206；否则继续执行步骤208；

步骤206，根据当前N(N为3、4、5)组关联器的查询结果，设置当前会话的业务类型，以便进行后续会话的处理；

步骤207，根据当前会话的识别结果，设置DPI的返回结果，以便DPI调用者使用；

步骤208，将当前报文进行更深层载荷分析和处理，分析当前报文七层的载荷内容，确定当前会话所属的业务类型；处理完毕后执行步骤209；

步骤209，将当前报文的DPI识别结果返回。

图3是本发明实施例的载荷深层处理的流程图，主要是完成报文载荷的识别，根据报文载荷内容判断当前报文是由何种业务所产生，并根据当前业务的网络业务流量模型设置一个或多个N元组关联器。具体包括如下步骤：

步骤301，进行报文七层载荷分析，例如，协议特征的匹配，需要说明的是，在此步骤中，有可能是单个报文匹配，也有可能是多个报文在一起共同完成协议特征的匹配；

步骤302，根据当前载荷的深度分析后，判断当前会话是否匹配成功。如果未能匹配成功，则执行步骤309；

步骤303，根据当前识别业务类型的网络业务流量模型特征，判断当前会话是否需要设置五元组关联器。通常五元组关联器的设置需要在DPI系统正常启动时配置完成。例如，实时流传输协议(Real Time Streaming Protocol，简称为RTSP)控制面协商媒体面会话后，需要设置实时传送协议(Real-time Transport Protocol，简称为RTP)、RTP控制协议(RTP Control Protocol，简称为RTCP)或RDT的五元组关联器。如果需要设置五元组关联器则执行步骤306，否则执行步骤304；

步骤304，根据当前识别业务类型的网络业务流量模型特征，判断当前会话是否需要设置四元组关联器。通常四元组关联器的设置需要在DPI系统正常启动时配置完成。例如，文件传输协议(File Transfer Protocol，简称为FTP)控制面协商媒体面会话后，需要设置FTP数据(DATA)的四元组关联器。如果需要设置四元组关联器则执行步骤307，否则执行步骤305；

步骤305，根据当前识别业务类型的网络业务流量模型特征，判断当前会话是否需要设置三元组关联器。通常三元组关联器的设置需要在DPI系统正常启动时配置完成。例如，点对点(Point to Point，简称为P2P)类的SKYPE协议，该协议在登陆过程中会发起数十个甚至上百个网络连接，这些网络连接的共同点是用户端的端口号、协议类型相同，网络IP地址和网络端口号不同，而用户端的端口号可以通过识别SKYPE会话的某一个流得出。因此，DPI系统在识别出该会话后设置一个三元组关联器，从而达到将其他SKYPE会话匹配的目的。如果需要设置三元组关联器则执行步骤308，否则执行步骤309；

步骤306，提取需要设置五元组关联器的信息，信息来源不局限于当前会话的五元组信息，可能来源于当前报文载荷中的数据等，需要根据协议具体分析。设置完成后，执行步骤304；

步骤307，提取需要设置四元组关联器的信息，信息来源不局限于当前会话的五元组信息，可能来源于当前报文载荷中的数据等，需要根据协议具体分析。设置完成后，执行步骤305；

步骤308，提取需要设置三元组关联器的信息，信息来源不局限于当前会话的五元组信息，可能来源于当前报文载荷中的数据等，需要根据协议具体分析。设置完成后，执行步骤309；

步骤309，将当前报文的DPI识别结果返回。

通过将业务报文的会话信息与会话记录表和关联记录表进行匹配来快速识别报文的业务类型，在匹配不成功的情况下再进行载荷深度分析获取业务类型，解决了现有技术中传统的DPI技术无法识别非公有协议报文的问题，能够快速、高效、准确地识别当前会话的业务类型。

尽管为示例目的，已经公开了本发明的优选实施例，本领域的技术人员将意识到各种改进、增加和取代也是可能的，因此，本发明的范围应当不限于上述实施例。

Claims (11)

1.一种基于深度包检测DPI的报文业务类型识别方法，其特征在于，包括：

步骤1，接收业务报文，将所述业务报文的会话信息与预先设置的会话记录表中的会话记录进行匹配，如果所述会话信息与某一条会话记录匹配成功，则从所述会话记录表中获取与该会话记录相对应的业务类型，作为所述业务报文的业务类型，如果未能从所述会话记录表中获取与该会话记录相对应的业务类型，则执行步骤2，如果未匹配成功，则根据所述会话信息在所述会话记录表中创建相应的会话记录，并执行步骤2；

步骤2，将所述业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配，如果所述会话信息与某一条关联记录匹配成功，则从所述关联记录表中获取与该关联记录相对应的业务类型，作为所述业务报文的业务类型，如果匹配不成功，则执行步骤3；

步骤3，对所述业务报文的会话信息进行深层载荷分析，获取所述业务报文的业务类型；根据所述业务报文的业务类型获取该业务的网络流量模型，并根据所述网络流量模型在关联记录表中创建相应的关联记录；将所述业务报文的业务类型保存到所述关联记录表中，并将创建的所述关联记录与所述业务类型设置对应关系。

2.如权利要求1所述的方法，其特征在于，在所述步骤2中，如果所述会话信息与某一条关联记录匹配成功，则从所述关联记录表中获取与该关联记录相对应的业务类型，作为所述业务报文的业务类型之后，所述方法还包括：

将所述业务报文的业务类型保存到所述会话记录表中，并将所述业务类型与相应的会话记录设置对应关系。

3.如权利要求1或2所述的方法，其特征在于，执行所述步骤3之后，所述方法还包括：

将所述业务报文的业务类型保存到所述会话记录表中，并将所述业务类型与相应的会话记录设置对应关系。

4.如权利要求1所述的方法，其特征在于，

所述会话信息包括：用户网络协议IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；

所述会话记录包括：所述用户IP地址、所述用户端口号、所述网络IP地址、所述网络端口号、以及所述协议类型；

所述关联记录表包括：五元组关联记录表、四元组关联记录表、和/或三元组关联记录表，其中，所述五元组关联记录表中的关联记录包括：所述用户IP地址、所述用户端口号、所述网络IP地址、所述网络端口号、以及所述协议类型；所述四元组关联记录表中的关联记录包括：所述用户IP地址、所述用户端口号、所述网络IP地址、以及所述协议类型；所述三元组关联记录表中的关联记录包括：所述用户IP地址、所述用户端口号、以及所述协议类型。

5.如权利要求4所述的方法，其特征在于，所述步骤2中，将所述业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配具体包括：

将所述业务报文的会话信息依次与所述五元组关联记录表、所述四元组关联记录表、和所述三元组关联记录表中的关联记录进行匹配，如果所述业务报文的会话信息与某一关联记录表中的关联记录匹配成功，则不再继续与后续关联记录表进行匹配。

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

在与所述会话记录表中的会话记录匹配成功或与所述关联记录表中的关联记录匹配成功的情况下，更新所述会话记录或所述关联记录的最后访问时间；

以预订周期扫描所述会话记录表和所述关联记录表；

获取所述会话记录表中各条会话记录以及所述关联记录表中各条关联记录的最后访问时间，分别将所述最后访问时间与当前时间进行比较，判断是否超时，如果超时，则将相应的会话记录或关联记录删除。

7.一种基于深度包检测DPI的报文业务类型识别装置，其特征在于，包括：

会话记录匹配模块，用于接收业务报文，将所述业务报文的会话信息与预先设置的会话记录表中的会话记录进行匹配，如果所述会话信息与某一条会话记录匹配成功，则从所述会话记录表中获取与该会话记录相对应的业务类型，作为所述业务报文的业务类型，如果未能从所述会话记录表中获取与该会话记录相对应的业务类型，则调用关联记录匹配模块，如果未匹配成功，则根据所述会话信息在所述会话记录表中创建相应的会话记录，并调用所述关联记录匹配模块；,

所述关联记录匹配模块，用于将所述业务报文的会话信息与预先设置的关联记录表中的关联记录进行匹配，如果所述会话信息与某一条关联记录匹配成功，则从所述关联记录表中获取与该关联记录相对应的业务类型，作为所述业务报文的业务类型，如果匹配不成功，则调用深层载荷分析模块；

所述深层载荷分析模块，用于对所述业务报文的会话信息进行深层载荷分析，获取所述业务报文的业务类型；根据所述业务报文的业务类型获取该业务的网络流量模型，并根据所述网络流量模型在关联记录表中创建相应的关联记录；将所述业务报文的业务类型保存到所述关联记录表中，并将创建的所述关联记录与所述业务类型设置对应关系。

8.如权利要求7所述的装置，其特征在于，

所述关联记录匹配模块进一步用于：在所述会话信息与某一条关联记录匹配成功的情况下，将所述业务报文的业务类型保存到所述会话记录表中，并将所述业务类型与相应的会话记录设置对应关系；

所述深层载荷分析模块进一步用于：在获取所述业务报文的业务类型之后，将所述业务报文的业务类型保存到所述会话记录表中，并将所述业务类型与相应的会话记录设置对应关系。

9.如权利要求7所述的装置，其特征在于，

所述会话信息包括：用户网络协议IP地址、用户端口号、网络IP地址、网络端口号、以及协议类型；

所述会话记录包括：所述用户IP地址、所述用户端口号、所述网络IP地址、所述网络端口号、以及所述协议类型；

所述关联记录表包括：五元组关联记录表、四元组关联记录表、和/或三元组关联记录表，其中，所述五元组关联记录表中的关联记录包括：所述用户IP地址、所述用户端口号、所述网络IP地址、所述网络端口号、以及所述协议类型；所述四元组关联记录表中的关联记录包括：所述用户IP地址、所述用户端口号、所述网络IP地址、以及所述协议类型；所述三元组关联记录表中的关联记录包括：所述用户IP地址、所述用户端口号、以及所述协议类型。

10.如权利要求9所述的装置，其特征在于，所述关联记录匹配模块具体用于：将所述业务报文的会话信息依次与所述五元组关联记录表、所述四元组关联记录表、和所述三元组关联记录表中的关联记录进行匹配，如果所述业务报文的会话信息与某一关联记录表中的关联记录匹配成功，则不再继续与后续关联记录表进行匹配。

11.如权利要求7所述的装置，其特征在于，所述装置还包括：

老化删除模块，用于在所述会话记录匹配模块匹配成功或与所述关联记录匹配模块匹配成功的情况下，更新相应的会话记录或相应的关联记录的最后访问时间；以预订周期扫描所述会话记录表和所述关联记录表；获取所述会话记录表中各条会话记录以及所述关联记录表中各条关联记录的最后访问时间，分别将所述最后访问时间与当前时间进行比较，判断是否超时，如果超时，则将相应的会话记录或关联记录删除。