CN113839882B - 一种报文流分流方法及装置 - Google Patents

Abstract

本说明书提供一种应用于分流系统的报文流分流方法，预先根据各个应用的会话特征，构建相应的会话模型，每个会话模型中，依据会话中各个报文的不同属性，将会话中的报文划分为不用类型的报文。用户根据每个应用的会话模型，设置需要分流的报文的类型，得到该应用的分流策略。分流系统接收到报文后，确定报文所属的会话，并将其关联至对应的会话。针对每个会话，确定会话所属的应用，根据会话中每个报文的属性，以及为该会话所属应用设置的分流策略，确定会话中每个报文是否需要分流至对应的分析系统。

Description

一种报文流分流方法及装置

技术领域

本说明书涉及通信技术领域，尤其涉及一种报文流分流方法及装置。

背景技术

大型机构有时会需要对各个应用进行有目的的分析，如，分析各应用在本机构的使用情况、应用是否合法等等，一般情况下，是在大量流量经过的地方部署分流系统与分析系统，分流系统用于获取流经的流量，将流量分流至各个分析系统。

现有技术中，管理人员根据实际需要，配置各个分析系统的分析目的，并根据各个分析系统的分析目的，配置分流系统的分流策略。其中，分流系统的分流策略一般都是根据应用特征制定的，即，应用特征相同的报文会有被分流至同一分析系统，应用特征可能是IP地址+端口号、特定字符串等。

然而，对于分析系统来说，每个应用所产生的流量并不都是可分析的或有分析价值的，即，分流至本系统的报文并不是所有都是可分析的或有分析价值的，大量报文的涌入，使得分析系统的系统压力较大。

发明内容

为克服上述分析系统压力较大的问题，本说明书提供了一种报文分流方法及装置。

本说明书提供了一种报文分流方法，所述方法应用于分流系统；所述分流系统用于将接收到的报文分流至不同分析目的的分析系统；

预先针对每个应用构建会话模型；其中，每个会话模型中，依据会话中各个报文的不同属性，将会话中的各个报文划分为不同的报文类型；所述报文的不同属性至少包括报文所属的会话的连接阶段、报文的应用层协议类型、报文时序、报文方向中的至少一项属性；

预先设置每个应用的分流策略；所述分流策略为用户基于每个应用的分析目的，设置的该应用对应的会话模型中需要分流至对应的分析系统的报文类型；

所述方法包括：

针对任一报文，根据该报文的五元组信息，确定该报文所属会话；

针对任一会话，确定该会话所属的应用；根据该会话所属的应用，确定该会话对应的会话模型；

针对任一会话的任一报文，根据该会话对应的会话模型，确定该报文的报文类型；根据该会话所属应用的分流策略，确定该报文是否为需要分流至对应分析系统的报文类型。

本说明书还提供了一种报文分流装置，所述方法应用于分流系统；所述分流系统用于将接收到的报文分流至不同分析目的的分析系统；

预先针对每个应用构建会话模型；其中，每个会话模型中，依据会话中各个报文的不同属性，将会话中的各个报文划分为不同的报文类型；所述报文的不同属性至少包括报文所属的会话的连接阶段、报文的应用层协议类型、报文时序、报文方向中的至少一项属性；

预先设置每个应用的分流策略；所述分流策略为用户基于每个应用的分析目的，设置的该应用对应的会话模型中需要分流至对应的分析系统的报文类型；

所述装置包括：

会话确定模块，用于针对任一报文，根据该报文的五元组信息，确定该报文所属会话；

应用识别模块，用于针对任一会话，确定该会话所属的应用；根据该会话所属的应用，确定该会话对应的会话模型；

分流模块，用于针对任一会话的任一报文，根据该会话对应的会话模型，确定该报文的报文类型；根据该会话所属应用的分流策略，确定该报文是否为需要分流至对应分析系统的报文类型。

本说明书实施例的技术方案，预先根据各个应用的会话特征，构建相应的会话模型，每个会话模型中，依据会话中各个报文的不同属性，将会话中的报文划分为不用类型的报文。用户根据每个应用的会话模型，设置需要分流的报文的类型，得到该应用的分流策略。分流系统接收到报文后，确定报文所属的会话，并将其关联至对应的会话。针对每个会话，确定会话所属的应用，根据会话中每个报文的属性，以及为该会话所属应用设置的分流策略，确定会话中每个报文是否需要分流至对应的分析系统。

通过本说明书实施例的技术方案，以会话的形式管理各个报文，确定会话中的各个报文是否需要进行分流，使得有分析价值的报文分流至对应的分析系统，没有分析价值的报文直接做丢弃处理，从而使得分流系统分流至各个分析系统的报文都是有分析价值的报文，减少了分析系统的资源消耗，包括内存资源的消耗与计算资源的消耗。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本说明书。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本说明书的实施例，并与说明书一起用于解释本说明书的原理。

图1是本说明书示出的系统框架示意图。

图2是本说明书示出的一种报文分流方法流程示意图。

图3是本说明书根据一具体实施例示出的一种报文方法流程示意图。

图4是本说明书根据一具体实施例示出示出的应用识别流程示意图。

图5是本说明书示出的一种报文分流装置示意图。

图6是本说明书示出的一种计算机设备硬件结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本说明书相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本说明书的一些方面相一致的装置和方法的例子。

在本说明书使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书。在本说明书和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

如上所述，相关技术中，分流系统将采集的所有流量按照要求，将每个应用的所有报文都分流(转发)至对应的分析系统，由于分析系统不仅需要分析各个报文是否有分析价值，还需要根据有分析价值的报文得到分析结果，因此大量报文的涌入，使得分析系统不堪负重，即，对于无分析价值的报文，其不仅消耗了分析系统大量的存储资源，还消耗了分析系统一部分的计算资源。随着网络规模的增长，上述问题日渐更甚。

而分流系统是根据设置，将接收到的报文分流至各个分析系统，相较于分析系统而言，其负载压力小于分析系统。

发明人在实践中发现，不同类型的报文包含的信息各不相同，对用户的价值也有所不同(即，用户设置的分析系统的分析目的不同，分析系统所需的报文是不同的)，一般情况下，应用中包含很多种报文，按照不用维度,可划分为很多类型的报文，例如，按照阶段分为连接阶段、身份认证阶段、数据传输阶段、断开连接阶段，各个阶段对应的报文是不同的；按照应用层协议，根据应用层协议头可划分为不同类型的报文；按照报文发送方向，划分为正向报文、反向报文等等。而这些属性的划分，都可以会话的形式进行组织。

基于此，本说明书提出一种应用于分流系统的报文流分流方法，预先根据各个应用的会话特征，构建相应的会话模型，每个会话模型中，依据会话中各个报文的不同属性，将会话中的报文划分为不用类型的报文。用户根据每个应用的会话模型，设置需要分流的报文的类型，得到该应用的分流策略。分流系统接收到报文后，确定报文所属的会话，并将其关联至对应的会话。针对每个会话，确定会话所属的应用，根据会话中每个报文的属性，以及为该会话所属应用设置的分流策略，确定会话中每个报文是否需要分流至对应的分析系统。

通过本说明书一个或多个实施例，以会话的形式管理各个报文，确定会话中的各个报文是否需要进行分流，使得有分析价值的报文分流至对应的分析系统，没有分析价值的报文直接做丢弃处理，从而使得分流系统分流至各个分析系统的报文都是有分析价值的报文，减少了分析系统的资源消耗，包括内存资源的消耗与计算资源的消耗。

本说明书提供了一种报文分流方法，以及与该方法对应的装置、设备、计算机存储设备。

首先对报文分流方法进行详细的说明。

本说明的方法应用的分流系统，如上述，大型机构有时会需要对各个应用进行有目的的分析，因此，会在有大量报文经过的设备旁进行流量的分析，包括分流系统和多个分析系统，分流系统用于将接收到的报文分流至各个分析系统，每个分析系统的分析目的不同，即，会从不同维度对应用对应的报文进行分析，分流系统根据为每个应用设置的分析目的，将对应的报文分流至对应的分析系统。

其中，分流系统获取的报文，一般是通过镜像功能或分光器复制而来，即，本说明书所述的分流系统对应的设备一般是旁路模式部署，其不影响转发设备正常的转发报文，而是将转发设备的报文复制一份至分流系统。如图1所示，为本说明书示出的系统示意图，分流系统通过镜像功能或分光器从各个转发设备中获取到报文，然后根据用户设置的分流策略，将报文分流至各个分析系统。

在本说明书一个或多个实施例中，需要预先针对每个应用确定对应的会话模型以及设置对应的报文分流策略。

首先，为各个应用预先构建不同的会话模型。

例如，按照一次连接中的各个阶段，划分报文类型，一般情况下，很多协议都会有连接阶段、身份认证阶段、数据传输阶段、断开连接阶段：

1)连接阶段：主要存在于基于TCP协议的应用中，基于SCTP协议等的应用也支持建立连接。以TCP协议为例，通信双方进行三次握手，需要往来3个报文。如果是UDP协议通信，则没有连接阶段。

2)身份认证阶段：有的客户端连接到服务器需要进行身份认证，认证过程中的报文会携带客户端身份信息、认证证书信息等。

3)数据传输阶段：传输通信数据。根据应用不同，可再细分为明文数据传输、密文数据传输、网站交互数据传输、低价值应用数据传输、请求、应答等等，每种应用的数据传输阶段可分为其中的一类至几类。

4)断开连接阶段：通信结束，相互发送通知关闭连接的报文。UDP协议通信也没有这个阶段。

也可以根据应用层协议，对报文进行类型划分，以HTTP协议为例，HTTP协议有GET、HEAD、POST、PUT、DELETE、OPT IONS这几种类型报文，每种报文都有其独特的作用，例如，GET报文为向指定的资源发出“显示”请求，PUT报文用于向指定资源位置上传其最新内容等等。

或者还可以按照方向来划分，是正方向报文与反方向报文的分析价值是不同的，即，由服务器发送至终端的报文和由终端发送至服务器的报文的分析价值时不同的，其中，一般正向报文指由终端发送至服务器的报文(即，会话中，源I P为终端的I P，目的I P为服务器的I P)，反向报文指由服务器返回至终端的报文(即，会话中，目的I P为终端的I P，源I P为服务器的I P)。

或者直接按照时序对会话中的各个报文进行排序，为会话中的报文按照时序进行编号。

之后，用户根据为各个应用设置对应的分流策略，包括两部分，一部分是需要分流至的分析系统，与相关技术中类似，本说明书没有进行详细的描述。另一部分是需要分流的报文类型，如上述，本说明书在从各个不同的维度，对会话中的报文进行了分类，用户选择会话中需要分流至分析系统的报文类型(即，用户认为有分析价值的报文类型对应的报文)。

假设按照阶段为会话划分报文类型，通常会先进行身份认证，再传输加密数据，其中身份认证阶段会传输涉及用户身份的明文信息(如QQ号、微信I D等)，而加密数据无法通过第三方进行解密，只能通过一些大数据方法识别一些外在特征(如报文长度、通信频度、网络层及传输层特征规律等)，一般分析系统无法进行解析以及分析，因此可以设置身份认证阶段的报文分流至对应的分析系统，加密数据报文(身份验证后的阶段对应的报文)丢弃。

假设按照应用层协议类型划分报文类型，如上述的HTTP协议GET、HEAD、POST、PUT、DELETE、OPT IONS报文，选择其中一些类型报文分流至对应的分析系统，如默认选择GET/POST类报文为分流至对应的分析系统，其他类型分报文直接丢弃。

假设按照报文方向，将会话中的报文划分为正向报文与反向报文，那么可以选择只将正向报文分流至对应的分析系统，或者只将反向报文分流至对对应的分析系统。

假设是对会话中的报文按照时序进行编号，那么可以按照经验，选择需要分流至对应的分析系统的报文编号范围，例如，每个会话的从第A个报文开始的B个报文和/或后C个报文，分流至对应的分析系统，其中A、B、C均为可配置的参数，其中A可为0(相当于转发前B个报文)；也可以选择转发或丢弃该会话的全部报文。

以上只是示例性的给出一些分流策略，实际应用中，针对每个应用，设置多个维度的会话模型对应的分流策略，即，由于可以从多个维度划分会话中各个报文的报文类型，故一个报文可能会属于多种类型，因此，用户可以从各个维度的对应用的会话设置分流策略，设置时，可以设置某几个维度的分流策略，也可以设置全部维度的分流策略，根据实际需求进行设置。

需要说明的是，本申请的应用是一种泛指，可以是网络应用，也可以是应用程序，还可以是一些特殊的协议，如DNS域名解析协议，因此，在识别报文所属的应用是指，是识别报文所属的应用、协议(特殊协议，如DNS的域名解析报文)、网站等，本说明书统一称之为应用。

接下来对报文流分流方法进行详细的说明，如图2所示，为本说明书示出的报文分流方法的流程示意图，包括以下步骤：

步骤201、针对任一报文，根据该报文的五元组信息，确定该报文所属会话。

在本说明书中，以会话为单位，确定会话中的各个报文是否有分析价值，因此，分流系统接收到报文后，需要先确定报文所属的会话。

其中，五元组信息包括目的I P，目的端口，源I P、源端口、I P协议号。

需要说明的是，会话与报文的五元组信息相同时，报文才是该会话的报文，而在确定报文所属的会话时，目的I P、目的端口与源I P、源端口互换之后，属于同一会话，例如，五元组(目的I P A,目的端口1，I P协议号10，源I P B,源端口2)对应的报文与五元组(目的I P B,目的端口2，I P协议号10，源I P A,源端口1)对应的报文属于同一会话。

步骤203、针对任一会话，确定该会话的五元组信息，并确定该会话所属的应用；根据该会话所属的应用，确定针对该会话设置的会话模型。

在本说明书中，预先确定了每个应用的会话模型，并未每个应用设置了对应的报文分流策略，因此，需要确定会话所属的应用，确定以该会话为单位的该应用的分流策略。

步骤205、针对任一会话的任一报文，根据该会话对应的会话模型，确定该报文的报文类型；根据该会话所属应用的分流策略，确定该报文是否为需要分流至对应分析系统的报文类型。

确定会话的会话模型后，根据报文的属性以及会话模型，确定报文的报文类型，例如，为连接阶段的报文，身份验证阶段的报文等等，然后根据用户设置的分流策略，确定该报文是否为需要分流至对应分析系统的报文类型。

如上述所述，假设按照应用层协议类型划分报文类型，以HTTP协议为例，包括GET、HEAD、POST、PUT、DELETE、OPTIONS报文，选择其中一些类型报文分流至对应的分析系统，如默认选择GET/POST类报文为分流至对应的分析系统，其他类型分报文直接丢弃。

需要说明的是，各个应用应该转发至的分析系统是确定的，即，各个应用的报文分流至的分析系统也是预先设置的，与相关技术中的方法相同，不是本说明书关注的重点，因此未进行详细说明。

一般情况下，应用的三元组信息是较为固定的(应用的服务器或者服务器群组相对固定)，因此应用的三元组信息(服务器的IP、服务器的端口、协议号)一般是固定的，在本说明书一个或多个实施例中，为了快速确定每个会话所属的应用，可以预先建立三元组信息与应用ID之间的对应关系。其中，任一三元组信息(服务器节点)对应的应用是固定的，任一应用对应的三元组信息不是固定的(任一应用可能有多个服务器节点)。

当确定某一会话所属的应用时，根据会话的五元组信息，确定该会话的三元组信息(目的IP、目的端口、IP协议号，或者，源IP、源端口、IP协议号)。根据该会话的三元组信息，查询三元组信息与应用ID之间的对应关系，得到该会话三元组信息对应的应用ID，即，该会话所属的应用。

实际应用中，可将三元组信息与应用ID之间的对应关系存储为列表，以三元组信息为唯一标识，得到应用服务器列表。当查询任一会话对应的应用时，根据会话的五元组信息，将源IP、源端口、IP协议号组成一个三元组，将目的IP、目的端口号、IP协议号组成另一个三元组，遍历应用服务器列表中的应用服务器节点的三元组信息，以检查这两个三元组是否有一个与任一应用服务器的三元组信息相同，若有则表示该报文正在和已记录的应用服务器通信，此时从该应用服务器节点的应用I D作为该会话所属的应用。

此外，在实际应用中，为了减少分流系统的存储压力，可以对已经进行分流处理的报文进行删除处理。

因此，在本说明说一个或多个实施例中，针对任一报文，记录该报文的处理状态，所述处理状态包括已进行分流处理、未进行分流处理、已进行丢弃处理。

如上述，针对任一报文，若该报文需要分流至对应的分析系统，那么分流系统会话其进行分流处理，将其分流至对应的分析系统，若该报文不是需要分流至分析系统的报文，那么分流系统会对其执行丢弃处理。对于需要分流至对应的分析系统的报文，若分流系统已对其进行了分流处理，则确定该报文是否被删除，若未被删除，则进行删除处理。对于未进行分流处理的，对其分流后，进行删除。

因此，周期性检测各个会话中，各个报文的处理状态；确定已进行分流处理的报文是否被删除，在未被删除的情况下，对其执行删除处理；对未进行分流处理的报文进行分流；分流后，将处理状态更改为已进行分流处理并删除报文。

实际应用中，分流系统获取的报文可能是不合法的，例如，I P地址是不正确的(如0.0.0.0)，校验和字段不是正确的，对于不合法的报文，没有分析的意义，因此，在确定报文的五元组信息前，可以先对报文进行合法性检查，至少包括I P地址合法性，校验和字段的合法性。

此外，一些情况下，分流系统接收的报文并未查询到对应的会话，此时，可以根据该会话的五元组信息，创建一个新会话，将该新会话作为该报文所属的会话。

实际应用中，会有多通道协议，此时，会有关联的存在，即，源I P、目的I P、I P协议号相同的两个会话，端口号为知名端口号的会话为主会话，端口号为不知名端口号的会话为关联会话。因此，在创建会话时，根据报文的端口号，确定创建的会话是新的主会话，还是某一主会话的关联会话。

在本说明书一个或多个实施例中，当任一会话长时间未收到并未收到新的报文时，可以将会话老化，将关于该会话的所有信息进行删除。

接下来对本说明书的一具体实施例进行详细的说明。

首先，为各个应用预先构建不同的会话模型。

例如，按照一次连接中的各个阶段，划分报文类型，一般情况下，很多协议都会有连接阶段、身份认证阶段、数据传输阶段、断开连接阶段。

也可以根据应用层协议，对报文进行类型划分，以HTTP协议为例，HTTP协议有GET、HEAD、POST、PUT、DELETE、OPT IONS这几种类型报文，每种报文都有其独特的作用，例如，GET报文为向指定的资源发出“显示”请求，PUT报文用于向指定资源位置上传其最新内容等等。

或者还可以按照方向来划分，是正方向报文与反方向报文的分析价值是不同的。

或者直接按照时序对会话中的各个报文进行排序，为会话中的报文按照时序进行编号。

之后，用户根据为各个应用设置对应的分流策略。

假设按照阶段为会话划分报文类型，可以设置身份认证阶段的报文分流至对应的分析系统，加密数据报文(身份验证后的阶段对应的报文)丢弃。

假设按照应用层协议类型划分报文类型，如上述的HTTP协议GET、HEAD、POST、PUT、DELETE、OPT IONS报文，可以默认选择GET/POST类报文为分流至对应的分析系统，其他类型分报文直接丢弃。

假设按照报文方向，将会话中的报文划分为正向报文与反向报文，那么可以选择只将正向报文分流至对应的分析系统，或者只将反向报文分流至对对应的分析系统。

假设是对会话中的报文按照时序进行编号，那么可以按照经验，选择需要分流至对应的分析系统的报文编号范围，例如，每个会话的从第A个报文开始的B个报文和/或后C个报文，分流至对应的分析系统，其中A、B、C均为可配置的参数，其中A可为0(相当于转发前B个报文)；也可以选择转发或丢弃该会话的全部报文。

以上只是示例性的给出一些分流策略，实际应用中，针对每个应用，设置多个维度的会话模型对应的分流策略，即，由于可以从多个维度划分会话中各个报文的报文类型，故一个报文可能会属于多种类型，因此，用户可以从各个维度的对应用的会话设置分流策略，设置时，可以设置某几个维度的分流策略，也可以设置全部维度的分流策略，根据实际需求进行设置。

为了更实际的实现上述方法，实际应用中，可设置会话管理模块，针对任一会话，记录以下信息：

1)会话I D；用于唯一标识每个会话。

2)会话最近更新时间；用于记录本会话最近一个报文到达的时间(针对后续会话的老化，会需要查询该记录)。

3)会话类型；用于记录本会话为主会话或关联会话。

4)所属应用I D；用于记录本会话所属的应用。

5)五元组特征；用于记录本会话的源I P、目的I P、I P协议号、源端口、目的端口。

6)报文管理结构列表；用于记录本会话的所有报文。

需要说明的是，实际应用中，有的协议使用关联的控制通道和数据通道分别传输控制报文和数据报文，例如FTP协议被动模式，通过TCP 21端口建立控制通道，需要传输文件(数据)时，经控制通道协商一个数据通信使用的端口号，然后双方使用该端口号进行数据传输。TFTP协议也类似，初始时通过知名端口69进行通信，然后由服务器分配一个未使用的随机端口号进行文件传输(源I P、目的I P、I P协议号均不变)。对于这种协议，知名端口对应的会话为主会话，不知名端口对应的会话为该主会话的关联会话(该主会话与该关联会话的源I P、目的I P、I P协议号是一样的)。

其中，知名端口值为1～1023之间的端口号。

针对任一报文，存储至对应的会话的报文管理列表，并记录以下信息：

1)报文序号；用于记录本报文的时序编号。

2)报文处理状态；用于记录本报文的处理状态，包括已处理和未处理两种状态。

3)报文类型；记录报文的各个维度的类性值(如上述的会话阶段、应用协议层特征、正反向等)。

4)原始报文数据；用于保存本报文的原始报文数据。

需要说明的是，实际网络通信过程中，丢失TCP协议数据报文会导致滑动窗口无法移出该报文覆盖的序列号范围，进而导致通信无法继续进行，不会再有后续的通信流程。如上述，分流系统对应的设备属于旁路模式部署，报文为通过镜像功能或分光器复制而来，可能由于其它原因(例如接口流量超带宽、意外传输错误等)导致丢失或篡改个别报文，而不影响该会话后续报文继续送到本设备。因此，理论上分流系统接收到的报文中，一个会话丢失任意一个或多个报文理论上都是可能的。

在本说明书中，对于上述情况，会话管理模块将按照报文中携带的序列号依次记录所接收的报文，重传报文不记入，乱序和丢失报文空出位置。若所记入的报文为用户所选择要转发的报文，则进行转发，否则丢弃。

之后，当分流系统接收到一个报文后，进行如下处理：

1、检查报文的合法性，检查报文中是否存在各种导致报文无法被确认为正常报文的情况，比如源/目的I P为0.0.0.0这样的报文、后者校验和字段不正确的报文等，对于不合法的报文，直接进行丢弃处理，并且不记入对应的会话(即，不加入至任一会话的报文管理列表)。

检测报文合法后，提取报文的五元组源I P、目的I P、I P协议号、源端口号、目的端口号)信息，查找所属会话，找到则更新会话的最近更新时间。

2、若在步骤1中未找到对应的会话，且源目的端口号均为非知名端口，则查询关联会话管理列表，通过判断其I P、协议号及端口号是否匹配，以检查其是否属于某个主会话的关联会话，是则创建关联会话，设置其最近更新时间，并与相应主会话进行关联，同时更新相应主会话的最近更新时间；若报文源或目的端口号为知名端口，或者未找到匹配的关联会话，则基于其五元组信息建立新的主会话，设置其最近更新时间，并将应用ID置为预设非法值(如非法值设置为-1)，等待应用识别模块进行应用识别；将源IP、源端口、IP协议号组成一个三元组，将目的IP、目的端口号、IP协议号组成另一个三元组，遍历应用服务器列表中的应用服务器节点的三元组信息，以检查这两个三元组是否有一个与任一应用服务器的三元组信息相同，若有则表示该报文正在和已记录的应用服务器通信，此时从该应用服务器节点中提取应用ID。

其中，判断当前报文是否匹配关联会话管理节点的方法是：提取当前报文的源IP(值为a)、目的IP(值为b)、IP协议号(值为c)、源端口号(值为d)、目的端口号(值为e)，构造成4个四元组：

源IP	目的IP	IP协议号	关联会话端口号
				a	b	c	d
b	a	c	d
				a	b	c	e
b	a	c	e

然后将其分别与关联会话管理列表各节点中相应字段作对比，有任一个四元组全部字段相同则视为匹配到了关联会话管理节点。

即，只要交互的双方设备以及协议号、关联端口号是相同的，即可认为是属于某一主会话的关联会话。

3、若该报文属于会产生关联会话的协议，且其中指定了关联会话的端口号，则根据源IP、目的IP、关联会话端口号及协议号在关联会话管理列表中创建相应关联会话管理节点，会话模块会记录关联会话的主会话ID、会话双方IP、协议号和关联会话的端口号；若关联会话已存在关联会话列表，则在主会话上会记录有关联会话的会话ID，关联会话上也会记录有主会话的会话ID。

其中，一个主会话可能对应多个关联会话。

4、若该报文所属会话为主会话且未确定所属应用,应用识别模块将异步对其进行识别，识别成功时会将识别结果(应用ID、会话方向)标记到会话上，并根据用户为该应用配置的分流策略对该会话中的各个报文进行相应的分流，将所有已进行分流处理的报文标记为已处理状态，然后销毁相应报文管理结构中的原始报文数据。应用识别模块进行识别和标记识别结果是异步的，即识别成功的时机由应用识别模块决定，应用识别模块可能读取该会话一个报文即能识别成功，也可能读取该会话多个报文才能识别成功。

应用识别模块所属进程异步运行，循环遍历会话列表中的主会话，读取应用ID字段，若为预设的非法值，则读取其已接收到的报文进行应用识别。如果由于会话上的报文数量过少或其它原因导致识别失败，则不作任何处理；成功识别报文所属应用时，除了在相应会话上标记识别结果，还将提取应用服务器信息，包括服务器的IP、端口号和IP协议号，其构成一个三元组，判断应用服务器列表中是否包含相同三元组的节点，若无则在应用服务器列表中创建一个新节点，包含应用ID和三元组信息，其三元组字段值即该三元组的值。

为了提取应用服务器信息，确定会话的发起者(客户端)和响应者(服务器端)很重要，有多种方法。对于某些使用知名端口(如HTTP为80、telnet为23等)的协议来说，目的端口为知名端口的报文往往就是正向报文，反之为反向报文；其它报文需要结合更多报文字段进行判断，比如对于TCP报文来说，发起请求的报文(即来自于客户端的syn报文)是正向报文，响应请求的报文(即来自于服务器端的syn/ack报文)是反向报文；对于UDP报文来说，由于不存在连接，一般一个会话中首个报文作为正向报文。但是由于设备初接入网络中时或重启后，由于很多客户端和服务器之间的通信已经存在，进入分流设备的会话可能并不包含连接中的最前若干个报文，可能导致对报文方向进行误判，因此一般还需要结合更具体的报文特征来判断，比如识别出报文所属应用后，再根据该应用的控制协议或数据特征来判断其属于客户端发出的还是服务器端发出的。

5、若该报文已确定所属应用，根据为该应用构建的会话模型，记录该会话各个维度的报文类型，如上述的各个阶段的报文，或者具有某个应用协议层特征的报文等。

6、针对每个会话的每个报文，根据会话所属的应用，确定用户为该应用设置的分流策略，然后对会话中的每个报文确定其是否需要分流至对应的分析系统。

其中，对于会话中的每个报文，对于已进行分流处理的报文，在报文管理结构上对该报文的处理标记置为已处理，销毁该报文原始报文数据以释放存储空间

最后，会话可能因为连接结束(TCP协议为收到双向fin报文或至少一个方向的rst报文)而关闭，也可能因长时间未收到该会话的报文而关闭，两种情况下都会走会话关闭流程。会话老化进程异步运行，将遍历所有主会话，检查其最近更新时间和当前时刻的差值是否超过了预设的老化时间，是则视为该会话已不再活跃，走会话关闭流程。

会话关闭流程中将删除指定的会话，包括其管理结构和相应关联会话的管理结构及相应的关联会话管理节点，以及相应的所有原始报文数据。

如图3所示，为本说明书示出的报文分流方法的流程示意图。

接收到报文后，先对报文进行合法性检查，合法后确定报文的五元组信息。然后根据报文的五元组信息，确定该报文所述的会话，若该报文存在对应的会话，则将该报文存储至对应的会话的报文管理列表，并对应的会话的最近更新时间。若不存在对应的会话，说明该报文是某会话的第一个报文，或者是某一关联会话对应的报文，因此，可以先确定该报文的端口号是否为知名端口，如果是，说明该报文不是某个主会话的关联会话的报文，创建主会话，设置会话最近更新时间，并将应用ID设置为预设的非法值；如果否，则确定该报文是否为某关联会话的报文，查询匹配的关联会话列表的四元组，确定是某一主会话的关联会话的报文后，创建关联会话，设置会话最近更新时间，并关联至相应的主会话，更新主会话最近更新时间(防止主会话被老化)。

之后，确定会话所属的应用，如果会话已确定所属应用，则根据为应用确定的会话模型，确定会话中的各个报文的报文类型。如果会话未确定所属应用，则查询应用服务器列表，查询是否有与会话相匹配的应用服务器三元组，如果是(查询到相匹配的应用服务器三元组)，则在会话上记录应用的I D，并根据为应用确定的会话模型，确定会话中的各个报文的报文类型。如果否(未相匹配的应用服务器三元组)，则结束，等待如4所示的方法识别应用。

然后根据为每个应用设置的分流策略，对会话中的报文进行分流，并对已经进行处理的报文进行已处理标记，销毁对应的原始报文数据。

如图4所示，为本说明书示出的确定每个会话所属的应用的确定方法的流程示意图。

定期遍历会话列表中的各个主会话，找到为确定所属应用的会话。根据该会话上已有的报文，进行应用是识别(应用识别方法与相关技术中相同，此处不进行详细的赘述)。若识别成功，则根据识别结果，对会话进行应用I D的标记，如果未识别成功，说明会话已有的报文不足以识别出应用，等待会话报文数量足够识别出所属应用后，再对其进行应用识别。

识别成功后，确定会话的方法，以确定出应用服务器的三元组信息。查询确定出的三元组信息是否已经存在与服务器节点，如果不存在，则创建相应的服务器节点，加入至应用服务器列表。然后根据为该应用确定的会话模型，确定会话中的各个报文的报文类型，以及根据为该个应用设置的分流策略，对会话中的报文进行分流，并对已经进行处理的报文进行已处理标记，销毁对应的原始报文数据。

需要说明的是，图4的流程是对图3的流程的补充，两者互相并不冲突。

以上是对报文分流方法的详细说明，接下来对报文分流装置进行详细的说明。

本说明书提供了一种报文分流装置，应用于分流系统；所述分流系统用于将接收到的报文分流至不同分析目的的分析系统；

预先针对每个应用构建会话模型；其中，每个会话模型中，依据会话中各个报文的不同属性，将会话中的各个报文划分为不同的报文类型；所述报文的不同属性至少包括报文所属的会话的连接阶段、报文的应用层协议类型、报文时序、报文方向中的至少一项属性；

预先设置每个应用的分流策略；所述分流策略为用户基于每个应用的分析目的，设置的该应用对应的会话模型中需要分流至对应的分析系统的报文类型；

如图5所示，所述装置包括：

会话确定模块501，用于针对任一报文，根据该报文的五元组信息，确定该报文所属会话；

应用识别模块503，用于针对任一会话，确定该会话所属的应用；根据该会话所属的应用，确定该会话对应的会话模型；

分流模块505，用于针对任一会话的任一报文，根据该会话对应的会话模型，确定该报文的报文类型；根据该会话所属应用的分流策略，确定该报文是否为需要分流至对应分析系统的报文类型。

其中，所述应用识别模块还可以具体用于：

预先建立三元组信息与应用的对应关系；

针对任一会话，根据该会话对应的五元组信息，确定该会话的三元组信息；所述三元组信息为源I P、源端口号、I P协议号，或目的I P、目的端口号、I P协议号；

查询该会话的三元组信息对应的应用，确定为该会话所属的应用。

此外，所述装置还可以包括识别模块，所述识别模块用于：

在基于所确定的三元组信息未查询到对应的应用的情况下，根据该会话的报文，识别该会话的报文所属的应用；

将识别出的应用确定为该会话的应用，并保存该会话的三元组信息与识别出的应用之间的对应关系。

所述装置还可以包括会话创建模块，所述会话创建模块用于：

针对任一报文，若根据该报文的五元组信息，未确定出该报文所属的会话，则根据该报文的五元组信息创建新会话，并确定该报文的所属会话为该新会话。

本说明书报文分流方法的实施例可以应用在计算机设备上。装置实施例可以通过软件实现，也可以通过硬件或者软硬件结合的方式实现。以软件实现为例，作为一个逻辑意义上的装置，是通过其所在文件处理的处理器将非易失性存储器中对应的计算机程序指令读取到内存中运行形成的。从硬件层面而言，如图6所示，为本说明书实施例的装置所在计算机设备的一种硬件结构图，除了图6所示的处理器1010、存储器1020、输入/输出接口1030、以及通信接口1040之外，实施例中会话表控制装置所在的设备，通常根据该计算机设备的实际功能，还可以包括其他硬件，对此不再赘述。

上述装置中各个模块的功能和作用的实现过程具体详见上述方法中对应步骤的实现过程，在此不再赘述。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本说明书方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

相应的，本说明书还提供一种计算机设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其中，所述处理器被配置为执行上述任一方法。

本说明书实施例还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行上述任一方法。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的单元或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(trans itory med ia)，如调制的数据信号和载波。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

本领域技术人员在考虑说明书及实践这里申请的发明后，将容易想到本说明书的其它实施方案。本说明书旨在涵盖本说明书的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本说明书的一般性原理并包括本说明书未申请的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本说明书的真正范围和精神由下面的权利要求指出。

应当理解的是，本说明书并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本说明书的范围仅由所附的权利要求来限制。

以上所述仅为本说明书的较佳实施例而已，并不用以限制本说明书，凡在本说明书的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本说明书保护的范围之内。

Claims (10)

1.一种报文分流方法，其特征在于，所述方法应用于分流系统；所述分流系统用于将接收到的报文分流至不同分析目的的分析系统；

预先针对每个应用构建会话模型；其中，每个会话模型中，依据会话中各个报文的不同属性，将会话中的各个报文划分为不同的报文类型；所述报文的不同属性至少包括报文所属的会话的连接阶段、报文的应用层协议类型、报文时序、报文方向中的至少一项属性；

预先设置每个应用的分流策略；所述分流策略为用户基于每个应用的分析目的，设置的该应用对应的会话模型中需要分流至对应的分析系统的报文类型；

所述方法包括：

针对任一报文，根据该报文的五元组信息，确定该报文所属会话；

针对任一会话，确定该会话所属的应用；根据该会话所属的应用，确定该会话对应的会话模型；

针对任一会话的任一报文，根据该会话对应的会话模型，确定该报文的报文类型；根据该会话所属应用的分流策略，确定该报文是否为需要分流至对应分析系统的报文类型。

2.如权利要求1所述的方法，其特征在于，所述针对任一会话，确定该会话所属的应用，包括：

预先建立三元组信息与应用的对应关系；

针对任一会话，根据该会话对应的五元组信息，确定该会话的三元组信息；所述三元组信息为源IP、源端口号、IP协议号，或目的IP、目的端口号、IP协议号；

查询该会话的三元组信息对应的应用，确定为该会话所属的应用。

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

在基于所确定的三元组信息未查询到对应的应用的情况下，根据该会话的报文，识别该会话的报文所属的应用；

将识别出的应用确定为该会话的应用，并保存该会话的三元组信息与识别出的应用之间的对应关系。

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

针对任一报文，若根据该报文的五元组信息，未确定出该报文所属的会话，则根据该报文的五元组信息创建新会话，并确定该报文的所属会话为该新会话。

5.如权利要求4所述的方法，其特征在于，所述根据该报文的五元组信息创建新会话包括：

确定该报文的端口号是否为知名端口号；其中，知名端口号为1～1023之间的端口号；

在该报文的端口号为知名端口号的情况下，根据该报文的五元组信息创建新的主会话；

在该报文的端口号为非知名端口号的情况下，根据该报文的源IP、目的IP、IP协议号，确定是否存在相匹配的主会话；在存在相匹配的主会话的情况下，根据该报文的五元组信息创建该匹配的主会话的新的关联会话；在不存在相匹配的主会话的情况下，根据该报文的五元组信息创建新的主会话。

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

针对任一报文，记录该报文的处理状态，所述处理状态包括已进行分流处理、未进行分流处理、已进行丢弃处理；

周期性检测各个会话中，各个报文的处理状态；

确定已进行分流处理的报文是否被删除，在未被删除的情况下，对其执行删除处理；

对未进行分流处理的报文进行分流；分流后，将处理状态更改为已进行分流处理并执行删除处理。

7.如权利要求6所述的方法，其特征在于，所述针对任一报文，确定该报文所属会话，包括：

针对任一报文，确定该报文所属会话，记录该报文的报文序号、报文处理状态、报文类型、原始报文数据至所属会话的报文管理列表；其中所述报文序号为该报文在所属会话中，以时序为序的编号；所述报文处理状态用于记录该报文是否已进行分流处理；所述报文类型用于记录该报文在所属会话对应的会话模型中所属的报文类型；所述原始报文数据为该报文的全部数据内容；

所述针对任一会话，确定该会话所属的应用，包括：

针对任一会话，确定该会话所属的应用；其中，所述会话ID用于唯一标识该会话；所述会话最新更新时间用于记录该会话最新接收到的报文的时间；所述会话类型用于记录该会话为主会话还是关联会话；所述应用ID用于记录该会话所属的应用；所述五元组信息用于记录该会话的五元组信息；所述报文管理列表用户记录该会话接收的所有报文。

8.一种报文分流装置，其特征在于，应用于分流系统；所述分流系统用于将接收到的报文分流至不同分析目的的分析系统；

预先针对每个应用构建会话模型；其中，每个会话模型中，依据会话中各个报文的不同属性，将会话中的各个报文划分为不同的报文类型；所述报文的不同属性至少包括报文所属的会话的连接阶段、报文的应用层协议类型、报文时序、报文方向中的至少一项属性；

预先设置每个应用的分流策略；所述分流策略为用户基于每个应用的分析目的，设置的该应用对应的会话模型中需要分流至对应的分析系统的报文类型；

所述装置包括：

会话确定模块，用于针对任一报文，根据该报文的五元组信息，确定该报文所属会话；

应用识别模块，用于针对任一会话，确定该会话所属的应用；根据该会话所属的应用，确定该会话对应的会话模型；

分流模块，用于针对任一会话的任一报文，根据该会话对应的会话模型，确定该报文的报文类型；根据该会话所属应用的分流策略，确定该报文是否为需要分流至对应分析系统的报文类型。

9.如权利要求8所述的装置，其特征在于，所述应用识别模块具体用于：

预先建立三元组信息与应用的对应关系；

针对任一会话，根据该会话对应的五元组信息，确定该会话的三元组信息；所述三元组信息为源IP、源端口号、IP协议号，或目的IP、目的端口号、IP协议号；

查询该会话的三元组信息对应的应用，确定为该会话所属的应用。

10.如权利要求9所述的装置，其特征在于，所述装置还包括识别模块，所述识别模块用于：

在基于所确定的三元组信息未查询到对应的应用的情况下，根据该会话的报文，识别该会话的报文所属的应用；

将识别出的应用确定为该会话的应用，并保存该会话的三元组信息与识别出的应用之间的对应关系。