CN100448227C - 业务流的识别方法 - Google Patents

Abstract

本发明公开了一种业务流的识别方法，所述方法以需要识别的业务流特征信息为依据，找到具有所述特征信息的数据包，再从该数据包中提取匹配参数并以匹配参数为基础建立业务流表，只要后续数据包命中该流表，即可判断属于需要识别的业务流。由于本发明不是按照传统的业务流识别方法以数据包包头中的固定参数为依据，因此不受数据包包头中IP、端口号等固定参数变化的影响。即使固定参数为动态应用的情况下，也可以将业务流的数据包正确识别出来。

Description

业务流的识别方法

技术领域

本发明涉及数据通讯方法，尤其涉及一种业务流的识别方法。

背景技术

网络上传输的大量数据可以看作是多项业务流的组成，每项业务流具有特定的业务特征。比如HTTP应用业务流采用的都是超文本传输协议，FTP应用业务流采用的都是文件传输协议。

正是由于网络上存在着纷繁复杂的业务流，因此有时需要将某些业务流的数据识别出来，以便进一步的处理和加工。比如禁止某些有危害的数据在网络上传输，分析网络上通过了多少满足要求的数据包，为满足要求的数据包选择特定的路由以及进行QOS(服务质量)处理等等。

一项业务流可能包含一个数据流，也可能包含几个数据流。数据流，是指具有相同的源、目的地的一串连续的数据包序列。对于3层IP数据流就是源I P和目的IP都相同的数据包序列，对于4层IP数据流则是源IP、目的IP、源端口、目的端口、协议类型都相同的数据包序列。对于非IP协议类似。因此，要识别出一项业务流，实质就是识别出满足一定特征的一系列数据包。换而言之，识别出某项业务流，就是识别出属于该项业务流的所有数据包。

目前业务流的识别方法，主要是在路由器或交换机之类的网络设备上，设置某项业务流的识别条件，该些识别条件以数据包包头中的固定参数为依据，如果网络设备接收的数据包包头中的信息满足设置的识别条件，就认为该数据包属于要识别的业务流。

上述识别方法的典型应用可以参考ACL访问控制列表，其工作原理是：预先在ACL表中设置一定的参数条件，一般包括源地址、目的地址、源端口、目的端口和协议类型五个参数(也称为五元组)。当数据包到来时，在路由器上读取其第三层及第四层包头中的固定参数信息：源地址、目的地址、源端口、目的端口和协议类型，将该些信息与ACL列表中定义的参数条件进行匹配，如果匹配一致，则认为接收的该数据包属于要识别的业务流。

下面列举一个利用ACL控制列表进行业务流识别的实例，例如，需要识别出HTTP应用的业务流。实现方法如下：

第1步，由于HTTP应用业务流的数据包使用的目的端口号通常是80，因此，在ACL列表中定义目的端口号为80这个识别条件。

第2步，当数据包到达时，在路由器上读取该包第三层及第四层包头中的固定参数信息：目的端口号。

第3步，将读取的目的端口号与列表中定义的目的端口号进行匹配，如果读取的数据包目的端口号为80，则认为该数据包属于HTTP应用业务流；否则认为其不属于HTTP应用业务流。

以上可以看出，以数据包包头中固定参数为依据的业务流识别方法可以将使用80端口作为目的端口的数据包识别出来，认为其属于HTTP应用业务流。但是，并不是所有HTTP应用都无一例外地使用80端口作为目的端口。一旦某些HTTP应用数据包采用的目的端口是动态分配所得，而不是80端口，则该些数据包就不能被正确识别出属于HTTP应用业务流。

类似的动态应用情况还有很多，比如现在较流行的P2P(Peer-to-peer)是一种点对点的网络应用，网络中现有的许多服务都可以归入P2P的行列，例如即时通讯***，譬如ICQ、微软的MSN Messenger以及国内的OICQ等都是最流行的P2P应用。P2P的应用使得用户可以直接连接到其他用户的计算机，进行文件共享与交换，不需要通过服务器。由于P2P的这种点对点特性，使得运行P2P的个人电脑不再需要固定的IP地址，有些甚至没有固定的端口，这点对于用户来说是有利的。但正是由于P2P的动态应用：没有固定IP，甚至没有固定的端口，造成传统的仅以数据包包头中的固定参数为依据的业务流识别方法，无法识别出像P2P这类动态应用的业务流。

发明内容

本发明的目的是提供一种业务流的识别方法，以解决现有业务流的识别方法以数据包包头中的固定参数为依据，不能对动态应用的业务流进行识别的技术问题。

为此，本发明提供如下的技术方案：

一种业务流的识别方法，所述方法包括步骤：

A、预先在网络设备上配置业务流特征信息；

B、过滤接收的数据包，提取具有特征信息数据包的匹配参数；

C、以匹配参数为基础建立业务流表，判断命中该业务流表的数据包属于需要识别的业务流。

所述步骤B包括：

B1、查找是否存在与接收的数据包相匹配的业务流表；

B2、在没有相匹配业务流表的数据包中，识别出具有所述特征信息的数据包；

B3、提取识别出的数据包中的匹配参数。

所述步骤B3具体包括：

如果配置的特征信息包括匹配参数提取方式，则根据匹配参数提取方式，提取数据包的匹配参数；

如果配置的特征信息不包括匹配参数提取方式，则根据数据包采用的传输协议类型，提取数据包包头中的匹配参数。

所述方法还包括步骤：

D、超过老化时间或收到删除信息时，删除相应业务流表。

优选的，所述业务流特征信息包括特征序列。

优选的，所述业务流表的内容包括业务流类型标识和数据包识别次数。

一种业务流的识别方法，所述方法包括步骤：

a、预先在网络设备上配置业务流特征信息；

b、提取接收的数据包包头中的匹配参数；

c、以提取的匹配参数为基础建立业务流表；

d、根据业务流的特征信息，判断命中所述业务流表的数据包是否属于需要识别的业务流。

所述步骤b包括：

b1、查找是否存在与接收的数据包相匹配的业务流表；

b2、对于没有相匹配的业务流表的数据包，根据其采用的传输协议类型，提取数据包包头中的匹配参数。

所述方法还包括步骤：

f、超过老化时间或收到删除信息时，删除相应业务流表。

优选的，所述业务流的特征信息包括特征序列。

优选的，所述业务流表的内容包括业务流类型标识和数据包识别次数。

一种业务流的识别方法，所述方法包括步骤：

预先在网络设备上配置业务流特征信息；

过滤接收的数据包，提取具有特征信息数据包的匹配参数；

接收的后续包中的匹配参数与提取的匹配参数一致时，判断该后续数据包属于需要识别的业务流。

一种业务流的识别方法，所述方法包括步骤：

预先在网络设备上配置业务流特征信息；

过滤接收的数据包，判断具有特征信息的数据包属于要识别的业务流。

从上述方案看出，与现有技术相比，本发明具有以下优点：

本发明公开的业务流识别方法，主要是以业务流特征信息作为识别一项业务流的关键依据，每一项业务流都会有唯一标识其自身的特征信息，这种特征信息虽然不一定存在于该项业务流的每一个数据包之中，但只要具有业务流特征信息的数据包肯定属于要识别的业务流。至于那些不含有特征信息的数据包，只要与具有特征信息的数据包属于同一数据流，即可被判定也属于要识别的业务流。本发明虽然也利用了包头中的固定参数，但目的是识别出属于同一数据流的数据包，而且这些固定参数无需预先知道，是从接收的数据包中提取的。因此，对于那些固定参数值是动态分配所得，预先无法获知的动态应用业务流也可以很好地识别。

附图说明

图1为本发明的第一实施例实现流程图；

图2为本发明的第二实施例实现流程图；

图3为本发明的第三实施例实现流程图；

图4为本发明的第四实施例实现流程图。

具体实施方式

本发明的核心思想是以一项业务流中，能够唯一标识该项业务流的特征信息作为识别的关键。同一数据流的数据包中，只要有一个数据包具有业务流特征信息，该数据流的所有数据包都可被判断出属于需要识别的业务流。

为使本领域技术人员更清楚地理解本发明的技术方案，下面先介绍业务流的基本概念。

业务流，是指完成某项特定功能的应用，比如HTTP超文本传输应用，FTP文件传输应用等。业务流主要包含两部分内容，一是真正的业务数据信息，二是指明前述业务数据信息流向、协议类型等的控制信息。

一项业务流可能由一个数据流组成，也可能由几个数据流组成。一个数据流，指具有相同的源、目的地的一串连续的数据包序列。对于3层IP数据流就是源IP和目的IP都相同的数据包序列，对于4层IP数据流则是源IP、目的IP、源端口、目的端口、协议类型都相同的数据包序列。对于非IP协议类似。因此，任何业务流最终都表现为一系列的数据包从一个节点传输到另一个节点。相应的业务流的控制信息和业务数据信息内容都包含在传输的数据包中。每个数据包通常分为两个区域：包头和数据域。包头中存储该包的控制信息，即该包从哪里来、发到哪里去，以及采用何种协议等；数据域存储该包真正的数据信息。

目前的业务流有两种形式。

第一种业务流，控制信息和业务数据信息在同一数据流中。具体到该业务流中的数据包而言，数据包包头中是该包的控制信息，用来指明该数据包从哪里来(源IP、源端口)、发到哪里去(目的IP、目的端口)以及采用何种协议等。通常情况下，包头中的信息也常被称作数据包的基本参数；数据域含有该项业务流的真正业务数据信息；

第二种业务流，控制信息和业务数据信息不在同一数据流中。业务数据信息在业务数据流中，控制业务数据流的信息在控制流中。要想识别出业务数据流，必须先识别出其对应的控制流。控制流中是控制包，业务数据流中是业务数据包。

控制包的包头中，存储的是该控制包本身的控制信息。用来指明该控制包从哪里来(源IP、源端口)，要到哪里去(目的IP、目的端口)以及遵守何种协议类型等，也称作数据包本身的基本参数。。

控制包的数据域，存储的是业务数据包的控制信息。用来指明业务数据包从哪里来(源IP、源端口)，要到哪里去(目的IP、目的端口)以及遵守何种协议类型等。简而言之，控制包的数据域内容，是其对应的业务数据包的基本参数，这也是“控制包”名称的由来。

业务数据包中，包含的是该项业务流的真正业务数据信息。

以下是本发明具体实施例的描述，根据业务流的两种不同形式分别予以说明。

针对业务流的第一种形式：控制信息和业务数据信息在同一个数据流中的情况，阐述本发明公开的两种实施方式。

这两种实施方式的共同构思都是利用业务流特征信息作为识别关键，两者的区别仅在于：是先根据特征信息识别，而后建立业务流表；还是先建立业务流表，而后根据特征信息识别。这两种实施方式各有优势，用户可以根据识别出的业务流将要进行的处理情况，具体选择采用哪种。

首先，请参阅图1，其为本发明的第一种实施例实现流程图，该实施例采用的是先根据特征信息识别，而后建立业务流表的识别方式，步骤如下：

101、预先在网络设备上配置业务流的特征信息。

102、接收的数据包到达，以其包头中的参数为基础项，查询有无相匹配的业务流表。如果有，则该数据包属于与其相匹配的业务流表所对应的业务流，进入步骤103；如果没有与其相匹配的业务流表，则进入步骤104。

103、相应的业务流识别流程。

104、根据配置的业务流特征信息，对数据包进行查找，识别出具有特征信息的数据包。

105、对被识别出的数据包，提取匹配参数；

106、以匹配参数为基础建立业务流表，判断命中该流表的数据包属于要识别的业务流。

107、超过老化时间或收到删除信息时，删除建立的业务流表。

在步骤101中，所述的业务流特征信息，是指能够识别该项业务流的特征内容。通常包括：特征序列、匹配参数提取方式、匹配参数编码方式以及建流特性等内容。

其中，特征序列是必需项，其它均为可选项。这是因为特征序列是识别的关键，所以必选。而其它均有缺省处理方式，如果不配置就按缺省处理。多数情况下也是缺省处理即可，定义这么多项内容可以更灵活地适应各种当前和未来的业务需要。

下面详细介绍业务流特征信息中的各项内容：

所述特征序列：

指能够唯一标识某项业务应用的特征，包括协议特征域和应用特征序列。协议特征域指明本应用采用的协议类型，比如IP、TCP、UDP等等。应用的特征序列，用来指明协议数据区中能够表征某项应用的特征，例如可以通过协议数据区中的HTTP/？？(？？是通配符，表示两个任意字符)来识别HTTP应用。

协议特征域可选，可以指定一个默认缺省值，通常是最常用的TCP。特征序列无需存在于该项业务流的每一个数据包中，至少有一个数据包包含这个特征序列即可。显然，每项业务流都会有其唯一标识的特征，能够区别于其它业务流。

所述匹配参数提取方式：

在解释这个概念之前，首先要清楚什么是匹配参数。所谓匹配参数，就是指在步骤106中用来建立业务流表的基础项，其内容包括唯一表示该数据流的基本参数，如源IP、源端口、协议类型、目的IP、目的端口等。但是不限于上述几项，具体匹配参数与特征协议域有关。

清楚匹配参数的概念后，进一步解释什么是匹配参数提取方式。匹配参数提取方式，是指告诉***在数据包的什么地方以及如何提取匹配参数，以便在步骤105中按照预先配置好的方式提取数据包的匹配参数。提取方式是用户根据自己要识别的业务流的特点来配置的，既可以配置为从数据包包头中提取基本参数(和缺省处理时相同)，也可以同时配置从数据域中提取需要的参数。

在匹配参数提取方式为缺省的情况下，根据数据包采用的协议类型提取匹配参数。例如，如果协议类型为IP，则提取的数据包中的匹配参数为源IP和目的IP；如果协议类型为TCP，则提取的数据包中的匹配参数为源IP、源端口、协议类型、目的IP、目的端口。当然，也可以根据数据包本身的其他参数类型，提取相应的匹配参数。

所述匹配参数编码方式：

在匹配参数存在时才用，用来指明匹配参数值如何正确运算，通常有字符编码、二进制编码以及B编码等，缺省为字符编码。

所述建流特性：

指明业务流按正向、反向或双向的方式建立业务流表以及元组数内容。

正向建流，指按照当前收到的数据包的方向建立业务流表。只有和该数据包到达方向一致的后续包才能命中该业务流表。业务流表中定义的源IP、源端口、目的IP、目的端口与接收的数据包中描述的完全一致。举个例子，假设数据包的源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222，则根据该数据包在步骤106中建立的业务流表就会定义：源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222。于是，只有源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222的后续数据包才能命中该业务流表。

反向建流，指按照当前收到的数据包反方向建立业务流表。只有与该数据包到达方向相反的后续数据包才能命中该业务流表。业务流表中定义的源IP、源端口、目的IP、目的端口与该数据包中的描述正好相反。举个例子，假设一个数据包的源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222，则根据该数据包在步骤106中建立的业务流表就会定义：源IP为2.2.2.2，源端口为2222，目的IP为1.1.1.1，目的端口为1111。于是，只有源IP为2.2.2.2，源端口为2222，目的IP为1.1.1.1，目的端口为1111的后续数据包才能命中该业务流表。

双向建流，指按照当前收到的数据包两个方向同时建立业务流表，这样来自两个方向的后续数据包都能命中该业务流表。举个例子，仍然假设一个数据包的源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222的数据包，则通过双向建流后，源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222的后续包和源IP为2.2.2.2，源端口为2222，目的IP为1.1.1.1，目的端口为1111的后数据包都可以命中该业务流表。

元组数内容，指明从数据包中提取的匹配参数内容是什么。通常情况下5元组指源IP、源端口、协议类型、目的IP、目的端口；4元组指源IP、源端口、目的IP和协议类型。

如果业务流的特征信息中没有配置建流特性，则按缺省处理。建流特性的缺省处理是双向5元组建流

以上将步骤101中配置的业务流特征信息各项内容做了详细介绍，这些内容都是用户根据实际业务需要配置的。

在步骤102中，由于路由器上可以同时识别多项业务流，因此，准备识别一项新的业务流时，可能***中已经存在多种业务流表，该些存在的业务流表属于之前识别的业务流。此时，路由器等设备接收到的数据包会有两种情况：

一、命中***中存在的某个业务流表，表明该数据包属于已经进行识别的相应业务流，从而进入其所属业务流的识别流程(步骤103)；

二、不能命中***中存在的任何业务流表，则表明该数据包不属于任何已经识别过的业务流，于是有可能属于将要识别的新业务流，需要对其进行进一步判断、识别，进入步骤104。

当然，如果整个***中只识别一项业务流，则不需要执行102步骤，从步骤101直接进入步骤104即可。

在步骤104中，一项业务数据流的所有数据包不可能同一时间到达，总会有先到和后到之分。根据预先配置的业务流特征信息对每一个达到数据包都进行查找，看其是否包含特征信息，主要是特征序列。如果该数据包具有配置的特征序列就认为属于要识别的业务流；否则，不予理睬，转而识别下一个接收的数据包。如此反复，直到识别出一个具有特征序列的数据包为止，进入步骤105。

在步骤105中，根据步骤101中配置的匹配参数提取方式或缺省处理方式提取识别出的数据包的匹配参数。

在步骤106中，以步骤105中提取的匹配参数为基础建立业务流表。其中匹配参数提供业务流表中定义的基础项，比如源IP、源端口、协议类型、目的IP、目的端口等。但是不限于上述几项，具体项目与特征协议域有关。例如，特征协议域为IP，则匹配参数就为源IP和目的IP。如果特征协议域为TCP，则匹配参数就为源IP、源端口、协议类型、目的IP、目的端口。建流特性提供了建流方式，比如正向、反向还是双向建流以及元组数内容等。特性的缺省方式是双向5元组，即源IP、源端口、协议类型、目的IP和目的端口。

建立的业务流表内容不但包括匹配参数的相关信息，还可以包含表示该流特性的内容，例如如果识别出该业务流，会记录识别标识以及指明识别出来的业务流要进行如何处理等等。

后续接收的数据包，将重复102的步骤，如果某些数据包能够命中在步骤106中建立的业务流表，即可判定属于要识别的业务流。根据数据流的定义，对于3层IP数据流而言，只要属于同一数据流，它们的源IP和目的IP都是相同的；对于4层IP数据流而言，只要属于同一数据流，它们的源IP、目的IP、源端口、目的端口和协议类型也都是相同的。其它情况也类似。因此，只要后续数据包的匹配参数与业务流表中定义的匹配参数一致，即命中该流表，就可判断该些数据包与用于建立业务流表的数据包同属一个数据流，进而属于要识别的业务流

在步骤107中，如果一种业务流被识别后，其业务流表仍然长时间存在于***中，会占用***资源而且没有实际意义。于是，本发明增设了这个本步骤。具体删除方式有两种，一种是像TCP这样的面向连接的应用，是有专门的数据包来进行连接删除的，这种情况下，***只要收到连接删除数据包，就将相应的业务流表删除。另一种方式是设置每个业务流表的老化时间，当超过老化时间还没有收到相应数据包时删除该业务流表。当然，增设这个步骤仅仅是为了提高资源利用率，实际操作时也可以省略。

至此，针对控制信息和业务数据信息在同一数据流中的业务流就被正确识别出来。可以清楚的看到本发明中，一项业务流识别过程的关键依据是唯一标识某项业务应用的特征序列，这与现有业务流识别方法的以数据包包头中的固定参数为依据有本质区别，进而有着明显的有益效果：不受几个固定参数的限制，即使IP地址，端口号等发生变化，也不影响数据识别。

举个简单的例子说明本发明的有益效果：比如有个HTTP的应用业务流，为简单起见，假设该项业务流只包含一个数据流，现在为了对其进行统计，需要首先将它识别出来。按照现有的识别方法，会以目的端口号是否为80作为判断依据，但是，此HTTP应用的业务流目的端口号不是采用常规的80端口，而是动态分配的，并且具体分配到哪个端口号也不知道。此时，使用现有的这种识别方法便无法对其正确识别。而采用本发明的识别方法并不需要事先知道该项HTTP业务流采用的目的端口号是多少，因为HTTP应用的特征序列可以描述为TCP数据域的第一行最后几个字符是“HTTP/？？？”，于是通过识别出业务流中的一个拥有该特征序列的数据包之后，就可以提取出该项业务流的IP地址以及端口号等匹配参数，只要是HTTP业务流的数据包都会命中上述匹配参数。至此，动态应用的HTTP应用业务流即被正确识别出来。

下面就以上述识别HTTP应用业务流为例，详细描述本发明的识别过程。

a1、配置TCP协议且数据域的第一行最后几个字符是“HTTP/？.？”的特征作为HTTP业务流识别的特征序列，特征信息中的其他项目均设置为缺省方式。

a2、一个数据包到达，以其本身的匹配参数：源IP1.1.1.1、源端口1111、目的IP2.2.2.2和目的端口2222为基础项，查询***中现存的业务流表是否有匹配一致的，查询完毕未发现可命中的业务流表。

a 3、由于该数据包是TCP协议，且数据域的第一行最后几个字符为HTTP/1.1，满足步骤a1中设置的特征信息，因此判定其属于HTTP业务流。

a4、对该数据包进行解码，提取匹配参数：源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222和TCP协议类型。以一个源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222和TCP协议类型为基础项建立业务流表的正向流信息；以源IP为2.2.2.2，源端口为2222，目的IP为1.1.1.1目的端口为1111，建立业务流表的反向流信息。业务流表内容还包括该数据流类型标识HTTP。

后续数据包的匹配参数只要与建立的业务流表中的匹配参数相同，即命中该业务流表，即可判断属于需要识别的业务流。从而属于HTTP业务流的数据包被正确识别出来。

a6、如果收到TCP的FIN/RST包(连接删除包)，表明TCP终止，于是删除该业务流表。

上面描述了针对控制信息和业务数据信息在同一数据流的情况，先根据特征信息识别，而后建立业务流表的技术方案实施例。下面介绍先建立业务流表，再根据特征信息识别的技术方案实施例。

请参阅图2，其为本发明的第二实施例，步骤如下：

201、预先在网络设备上配置业务流的特征信息。

202、数据包到达，以其本包头中的参数为基础项，查询有无相匹配的业务流表。如果有，则该数据包属于与其相匹配的业务流表所对应的业务流，如果该项业务流还没有被识别，则进入步骤205；如果没有与其相匹配的业务流表，则进入步骤203。

203、根据接收的数据包采用的传输协议类型，提取数据包的匹配参数。

204、以匹配参数为基础建立业务流表。

205、根据业务流的特征信息，判断命中所述业务流表的数据包是否属于需要识别的业务流。

如果用于建立业务流表的数据包具有特征信息，则该数据包属于要识别的业务流，根据其匹配参数建立的业务流表标识的必然是需要识别的业务流，从而命中该流表的后续数据包都属于要识别的业务流。如果该数据包不具有特征信息，则重复步骤202到步骤205的操作。

206、收到连接删除数据包时删除上述业务流表，或者设置老化时间，当超过老化时间还没有收到数据包时，删除上述业务流表。

在步骤201中，配置业务流特征信息的内容与第一实施例步骤101中介绍的内容是相同。业务流特征信息是指描述能够识别该项业务的特征内容，通常包括：特征序列、匹配参数提取方式、匹配参数编码方式和建流特性等内容。其中，特征序列是必需项，其它均为可选项。由于上文在步骤101中已经对配置业务流特征信息做过详细介绍，因此本步骤不再赘述。

在步骤202中，由于路由器上可以同时识别多项业务流，因此，准备识别一项新的业务流时，可能***中已经存在多个业务流表，该些存在的业务流表属于之前识别的其他业务流或者属于未识别的业务流。此时，路由器等设备接收到的数据包会有两种情况：

一、命中***中存在的某个业务流表，表明该数据包属于所命中流表对应的业务流，该业务流有可能是已经被识别的业务流，也有可能是还未被识别的业务流。如果该业务流还没有被识别，则转入步骤205。

二、不能命中***中存在的任何业务流表，表明该数据包不属于任何已经识别过的业务流，于是有可能属于将要识别的新业务流，需要对其进一步判断、识别，进入步骤203。

当然，如果整个***中只识别一项业务流，则不需要执行202步骤，从步骤201直接进入步骤203即可。

在步骤203中，由于还没有对该数据包根据特征信息进行识别，因此不能像第一实施例：根据配置的匹配参数提取方式，提取数据包的匹配参数。这里只能根据接收的数据包自身采用的传输协议类型，提取匹配参数。例如，如果协议类型为IP，则提取的数据包中的匹配参数为源IP和目的IP；如果协议类型为TCP，则提取的数据包中的匹配参数为源IP、源端口、协议类型、目的IP、目的端口。任何一种协议类型，都有其相应的匹配参数内容。当然，也可以根据数据包本身的其他参数类型，提取相应的匹配参数。

在步骤204中，以提取的匹配参数为基础建立业务流表。其中匹配参数是业务流表内容的基础项，比如源IP、源端口、协议类型、目的IP和目的端口等。但是不限于上述几项，具体项目与特征协议域有关。建流特性提供了建立业务流表的方式，比如是正向、反向或是双向建流以及元组数内容等。建流特性的缺省方式是双向5元组建流，即以源IP、源端口、协议类型、目的IP和目的端口为基础双向建立业务流表。

在步骤205中，根据业务流的特征信息，判断命中业务流的数据包是否属于需要识别的业务流。

后续数据包到达时，执行202步骤，如果该数据包能够命中204中建立的业务流表，即后续数据包的匹配参数与该业务流表的匹配参数相同，则表示后续包与用于建立流表的数据包属于同一数据流。此时，根据配置的特征信息，对用于建立流表的数据包进行识别，如果该数据包具有配置的特征序列，则该数据包属于要识别的业务流，据此建立的业务流表标识的必然是要识别的业务流，从而命中该流表的数据包被判断属于要识别的业务流。

在步骤206中，由于一种业务流被识别后，如果其业务流表还长期存在于***中，就会占用***资源而且没有实际意义。于是，本发明增设了这个本步骤。具体删除方式有两种，一种是像TCP这样的面向连接的应用，是有专门的数据包来进行连接删除的，这种情况下，***只要收到连接删除数据包，就将相应的业务流表删除。另一种方式是设置每个业务流表的老化时间，当超过老化时间还没有收到相应数据包时，删除相应业务流表。当然，增设这个步骤仅仅是为了提高资源利用率，实际操作时也可以省略。。

以上内容阐述了本发明业务流识别方法的两种实施方案，这两种实施方案都是针对控制信息和业务数据信息在同一数据流而言的。另外还有些业务流，它们的控制信息和业务数据信息不在同一数据流，下面详细阐述针对此种情况的业务流识别方法的实施例。

此时，需要注意一个问题：一项需要识别的业务流的控制流中，每个控制包的数据域信息不一定都是相同的。一种情况是控制流中所有的控制包指向的是同一业务数据流，即该项业务流只包含一个控制流和一个业务数据流。另一种情况是控制流中的控制包指向属于同一业务流的几个不同的业务数据流。举个简单的例子，FTP应用业务流就需要在控制流上不断建新的业务数据流，即该项业务流包含一个控制流和多个业务数据流。其直观意义就是使用FTP协议传输多个文件，传输完一个文件后，再传其他文件。虽然这些文件属于不同的数据流，但都采用的是FTP协议，因而都属于需要识别的FTP业务流。

如果控制流中的所有控制包中的数据域信息是完全相同的，即指向同一个业务数据流。则只需识别出一个控制包的数据域信息，即可得到属于该项业务流的所有业务数据包的控制信息。无需对每个控制包进行识别，即只识别一次控制包。

如果要识别FTP业务流满足FTP应用的所有业务数据流可能为多个。多个满足FTP应用的业务数据流会有多个不同的控制包进行控制，这些控制包同属于一个控制流，因此该些控制包报头中的参数信息是相同的。但数据域的信息可能是不同的，指向不同的业务数据流。从而在识别类似FTP业务流时，需要识别出所有控制包，进而找到它们对应的不同种类的业务数据流。即需要多次识别控制包。

对控制信息和业务数据信息不在同一数据流的情况，本发明也有两种实施方案，一是先根据特征信息识别，而后建立业务流表；二是先建立业务流表，再根据特征信息识别。

请参阅图3，其为本发明的第三实施例实现流程图，采用的是先根据特征信息识别，然后建立业务流表的技术方案，步骤如下：

301、预先在网络设备上配置业务流特征信息。

302、接收的数据包到达，以其本身包头中的参数为基础项，查询有无相匹配的业务流表。如果有，则该数据包属于与其相匹配的业务流表所对应的业务流，进入步骤303；如果没有与其相匹配的业务流表，则进入步骤304。

303、进入与其相应的业务流识别流程。

304、根据配置的业务流特征信息，对接收的数据包进行查找，识别出具有特征信息的数据包。

305、对被识别出的数据包，提取其包头中的匹配参数和位于数据域中的参数信息。

306、以包头中的匹配参数为基础建立控制流表，同时，以数据域的参数为基础建立业务数据流表。

后续包到达时，与控制流表和业务数据流表分别进行匹配。如果命中控制流表，则重复302步骤和305、306步骤中关于建立业务数据流表的相关操作；如果后续包命中业务数据流表，则属于要识别的业务流。

307、超过老化时间或收到连接删除数据包时，删除该业务流表。

在步骤301中，所述的配置业务流特征信息，与第一实施例的101步骤中介绍的配置业务流特征信息基本思路是一样的，主要是配置唯一标识业务应用的特征序列，再配置一些辅助信息，比如匹配参数提取方式、匹配参数编码方式以及建流特性等。由于配置内容大体相同，只是个别项的具体操作有些不同。因此，对于相同的部分本处不再赘述，只对配置的不同之处做详细说明。

首先，由于控制信息和业务数据信息不在同一数据流，业务数据流的控制信息在控制流中。因此，要想得到业务数据流的信息，必须先要找到控制流。因此根据本步骤配置的特征序列首先要识别是控制包。比如要想识别FTP应用业务，就可以通过配置TCP数据域的前几个字符为“PORT”或“PASV”的特征序列来识别FTP业务的控制包。

其次，配置的匹配参数提取方式也有所不同。就像上文中提过的，由于控制信息和业务数据数据信息不在同一个包中，因此后续接收的数据包既可能是控制包又可能是业务数据包。因此，匹配参数提取方式中既要配置控制包的匹配参数提取方式，又要配置业务数据包的匹配参数提取方式。提取方式缺省的情况下，控制包的匹配参数提取是在控制包的包头中。业务数据包的匹配参数提取只能由***配置在控制包的数据域中提取。

再次，上文中提过，不同控制包中的数据域信息可能是不同的。因此，在建流特性中除了配置建流方向和元组数内容外，还要配置对控制包的识别方式。如果要识别的业务流只有一个业务数据流，则只需配置对控制包一次识别；如果控制流之上不断建新业务数据流，即控制包数据域的信息不同，则需要配置多次识别控制包。

在步骤302中，由于路由器上可以同时识别多项业务流，因此，准备识别一项新的业务流时，可能***种已经存在多种业务流表，该些存在的业务流表属于之前识别的业务流。此时，路由器等设备接收到的数据包会有两种情况：

一、命中***中存在的某个业务流表，表明该数据包属于已经进行识别的业务流，从而进入其所属业务流的识别流程(步骤303)；

二、不能命中***中存在的任何业务流表，则表明该数据包不属于任何已经识别过的业务流，于是有可能属于马上要识别的新业务流，需要对其进行识别，进入步骤304。

当然，如果整个***中只识别一项业务流，则不需要执行302步骤，从步骤301直接进入步骤304即可。

在步骤304中，由于在步骤301中配置的特征序列是针对控制流的，因此具有特征信息的数据包是该项业务流的控制包。

在步骤305中，由于业务流特征信息中已经配置好匹配参数提取方式，于是对步骤304识别出的控制包提取其包头中的匹配参数以及数据域中的参数信息。该包数据域中的参数信息就是相应的业务数据流的匹配参数。

在步骤306中，以提取的控制包包头中的匹配参数为基础，建立针对控制流的控制流表，同时以提取的控制包数据域中的匹配参数为基础建立针对业务数据流的业务数据流表。控制流表的内容中不仅包含控制包的匹配参数信息，还可以记载对控制包的识别方式：多次识别或一次识别。这是根据步骤301中配置的多次识别或一次识别信息而记载的。另外，建立的这两个业务流表还可以包含表示该项业务流特性的内容，例如识别出该项业务流，会记录识别标识以及指明识别出来的业务流将要进行如何处理等。

后续包到达时，与控制流表和业务数据流表分别进行匹配。如果命中控制流表，则说明该数据包是要识别业务流的控制包。如果控制流表中记载了对控制包多次识别，则重复步骤305中提取数据域中匹配参数的操作以及以及步骤306中建流业务数据流表的操作，进而可以识别出建立在一个控制流之上的新业务数据流的数据包；如果后续包命中业务数据流表，则为业务数据包，属于要识别的业务流。

可以看出，针对后续数据包是控制包的情况，有两种处理方式：

如果在步骤301的业务流特征信息中配置了对控制包需要多次识别，进而在建立的控制流表内容中会记载需要多次识别控制包。于是，每来一个控制包都会提取其数据域中的信息，并以此为基础建立新的业务数据流表。当然也可能出现这样的控制流：有些控制包数据域信息相同，有些控制包数据域信息不同。此时，在配置对控制包多次识别的同时，还可以配置仅根据识别出的数据域信息不同的控制包建立业务数据流表，这样便不会出项重复建立相同业务数据流表的情况，节省了***资源；

如果在步骤301的业务流特征信息中配置了对控制包仅一次识别，则后续控制包命中控制流表之后，不会再提取该些包的数据域信息。即使提取数据域信息也是相同的，没有实质意义。

下面以识别FTP应用业务流为例，对控制信息和业务数据信息不在同一数据流，而且在控制流之上不断建立新业务数据流的情况进行识别方法的描述：

b1、配置特征序列为TCP协议且数据域开始的字符是“PORT”或“PASV”；特征编码方式为FTP编码；匹配参数提取方式为在包头提取匹配参数和在数据域提取匹配参数；建流特性为控制包双向5元组建流，业务数据包4元组双向建流；同时配置对控制包多次识别。

b2、一个数据包到达，以其包头中的参数信息：源IP1.1.1.1、源端口1111、目的IP为2.2.2.2、目的端口2222为基础项查询***中现存的业务流表，没有发现相符的业务流表，于是进入步骤b3。

b3、该数据包使用的是TCP协议，且数据域的开始几个字符为PORT1，1，1，2，4，88，与步骤b1中设置的特征序列“PORT”相同，于是该数据包属于FTP应用，显然，该数据包是FTP应用业务流的控制包。

b4、提取该控制包包头中的信息，即匹配参数：源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222和使用的是TCP协议类型。

b5、根据步骤b4获得的控制包匹配参数，进行5元组双向建流。以源IP为1.1.1.1，源端口为1111，目的IP为2.2.2.2，目的端口为2222和TCP协议类型为基础项建立业务流表的正向流信息，同时以目的IP为1.1.1.1，目的端口为1111，源IP为2.2.2.2，源端口为2222和TCP协议类型建立业务流表的反向流信息。如此建立的业务流表实际为FTP的控制流表，该控制流表内容还记录了要识别的业务流类型标识FTP以及对控制包多次识别。

b6、提取该控制包数据域中的信息，即其对应的业务数据包的匹配参数：源IP 1.1.1.2，源端口为4×256+88＝1112，与目的IP 2.2.2.2和TCP协议类型，这里的IP号以及端口号是根据“PORT”后的“1，1，1，2，4，112”计算所得，之所以这样计算，依据的是步骤b1中配置的匹配参数编码方式。因为匹配参数编码方式定义的就是参数值算法。

b7、根据步骤b6获得的业务数据包匹配参数进行4元组双向建流。以源IP 1.1.1.2，源端口4×256+112＝1112，目的IP 2.2.2.2和TCP协议类型为基础项建立业务流表的正向流信息，以目的IP 1.1.1.2，目的端口为4×256+112＝1112，与源IP 2.2.2.2和TCP协议类型建立业务流表的反向流信息。业务流表内容还包括该流类型标识FTP，且不需要再次识别。该业务流表实际为FTP应用的业务数据流表。

后续的数据包到达时，如果后续包的匹配参数与业务数据流表中的匹配参数相同，即命中业务数据流表，表明该包属于FTP应用业务流，而且是FTP的业务数据包；如果后续包的匹配参数与控制流表中的匹配参数相同，即命中控制流表，表明该包属于FTP应用业务流，而且是FTP的控制包。于是重复步骤b6和b7，建立新的业务数据流表，进而识别出新的FTP业务数据流。

b8、如果收到TCP的FIN/RST报文，表明TCP终止，删除建立的两种业务流表

上面介绍了是先根据特征信息识别，然后建立业务流表的技术方案；下面介绍先建立业务流表，再根据特征信息识别的技术方案。。

请参阅图4，其为本发明的第4实施例实现流程图，步骤如下：

401、预先在网络设备上配置业务流特征信息。

402、接收的数据包到达，以其本包头中的参数为基础项，查询有无相匹配的业务流表。如果有，则该数据包属于与其相匹配的业务流表所对应的业务流，如果该业务流还没有被识别，进入步骤404；如果没有与其相匹配的业务流表，则进入步骤403。

403、根据接收的数据包采用的传输协议类型，提取数据包包头中的匹配参数并以此为基础建立控制流表。

404、根据业务流的特征信息，判断用于建立控制流表的数据包是否属于要识别的业务流，如果该数据包具有配置的特征序列，则可判断该数据包为要识别业务流的控制包，据此建立的流表标识的自然是要识别的业务流，进入步骤405。

405、根据配置的匹配参数提取方式，提取控制包数据域中的匹配参数，并以此为基础建流业务数据流表。

406、收到连接删除数据包时删除该业务流表，或者设置老化时间，当超过老化时间而没有收到数据包时，删除该业务流表。

在步骤401中，配置业务流的特征信息内容与步骤301中讲述的配置特征信息内容是相同的，因此不再赘述。业务流特征信息中定义了特征序列、匹配参数提取方式、匹配参数编码方式以及建流特性。建流特性中定义了建流方向、元组数内容以及对控制包的识别方式：一次识别或多次识别。

在步骤403中，由于还没有对该数据包根据特征信息进行识别，因此匹配参数提取方式无法配置，只能根据接收的数据包自身采用的传输协议类型，提取相应的匹配参数。例如，如果协议类型为IP，则提取的数据包中的匹配参数为源IP和目的IP；如果协议类型为TCP，则提取的数据包中的匹配参数为源IP、源端口、协议类型、目的IP、目的端口。任何一种协议类型，都有其相应的匹配参数内容。当然，也可以根据数据包本身的其它参数信息类型，提取相应的匹配参数。

在步骤404中，实质就是要判断建立的控制流表是否标识的是要识别的业务流。只要用于建流表的数据包具有配置的特征序列，便是要识别的业务流的控制包，以该数据包匹配参数为基础的业务流表即为要识别业务流的控制流表。

在步骤405中，因为已经识别出用于建流表的控制包属于要识别的业务流，于是就可根据配置的匹配参数提取方式提取该控制包的数据域信息。提取的数据域信息内容，就是该控制包对应的业务数据包的匹配参数，根据此匹配参数建立的业务流表即为要识别业务流的业务数据流表。

如果后续到达的数据包命中业务数据流表，则可判断该后续包属于需要识别的业务流，而且是该项业务流的业务数据包；如果后续到达的数据包命中404步骤中建立的控制流表，则该数据包属于要识别业务流，而且是该项业务流的控制包，于是重复步骤405。

以上对本发明所提供的一种业务流识别方法进行了详细介绍，本文中应用了具体实施例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想，但本发明并不局限于此：

例如，对于某些业务流的每个数据包都具有特征信息的情况，就无需提取匹配参数和建立业务流表的步骤，只要查找到具有配置的特征信息数据包，即可判定其属于需要识别的业务流。

再例如，提取匹配参数之后，不一定必须用列表的方式承载匹配参数信息，也可以采用其它的承载体或者直接存储这些信息。而且即使建立业务流表，也不仅限于每项业务流建立一个流表，实际运用时可以建立一张大的列表，将需要识别的各项业务流的流表内容都记载进去。这样既方便接收的数据包查找相匹配业务流表，又节省了***资源。

同时，对于本领域的一般方法人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本发明的限制。

Claims (12)

1、一种业务流的识别方法，其特征在于，包括：

A、预先在网络设备上配置业务流特征信息；

B、过滤接收的数据包，提取具有特征信息数据包的匹配参数；

C、以匹配参数为基础建立业务流表，判断命中该业务流表的数据包属于需要识别的业务流。

2、如权利要求1所述的业务流的识别方法，其特征在于，所述步骤B包括：

B1、查找是否存在与接收的数据包相匹配的业务流表；

B2、在没有相匹配业务流表的数据包中，识别出具有所述特征信息的数据包；

B3、提取识别出的数据包中的匹配参数。

3、如权利要求2所述的业务流的识别方法，其特征在于，所述步骤B3包括：

如果配置的特征信息包括匹配参数提取方式，则根据匹配参数提取方式，提取数据包的匹配参数；

如果配置的特征信息不包括匹配参数提取方式，则根据数据包采用的传输协议类型，提取数据包包头中的匹配参数。

4、如权利要求1所述的业务流的识别方法，其特征在于，所述方法还包括步骤：

D、超过老化时间或收到删除信息时，删除相应业务流表。

5、如权利要求1所述的业务流的识别方法，其特征在于，所述业务流特征信息包括特征序列。

6、如权利要求1所述的业务流的识别方法，其特征在于，所述业务流表的内容包括业务流类型标识和数据包识别次数。

7、一种业务流的识别方法，其特征在于，包括：

a、预先在网络设备上配置业务流特征信息；

b、提取接收的数据包包头中的匹配参数；

c、以提取的匹配参数为基础建立业务流表；

d、根据业务流的特征信息，判断命中所述业务流表的数据包是否属于需要识别的业务流。

8、如权利要求7所述的业务流的识别方法，其特征在于，所述步骤b包括：

b1、查找是否存在与接收的数据包相匹配的业务流表；

b2、对于没有相匹配的业务流表的数据包，根据其采用的传输协议类型，提取数据包包头中的匹配参数。

9、如权利要求7所述的业务流的识别方法，其特征在于，所述方法还包括步骤：

f、超过老化时间或收到删除信息时，删除相应业务流表。

10、如权利要求7所述的业务流的识别方法，其特征在于，所述业务流的特征信息包括特征序列。

11、如权利要求7所述业务流的识别方法，其特征在于，所述业务流表的内容包括业务流类型标识和数据包识别次数。

12、一种业务流的识别方法，其特征在于，包括

12-1、预先在网络设备上配置业务流特征信息；

12-2、过滤接收的数据包，提取具有特征信息数据包的匹配参数；

12-3、接收的后续包中的匹配参数与提取的匹配参数一致时，确定该后续数据包属于需要识别的业务流。

Images