CN110943873B

CN110943873B - 一种报文流的处理方法、装置和可读介质

Info

Publication number: CN110943873B
Application number: CN201811105422.XA
Authority: CN
Inventors: 曾英佩; 池伟; 田永兴; 王国栋; 陈远发
Original assignee: China Mobile Communications Group Co Ltd; China Mobile Hangzhou Information Technology Co Ltd
Current assignee: China Mobile Communications Group Co Ltd; China Mobile Hangzhou Information Technology Co Ltd
Priority date: 2018-09-21
Filing date: 2018-09-21
Publication date: 2021-08-17
Anticipated expiration: 2038-09-21
Also published as: CN110943873A

Abstract

本发明公开了一种报文流的处理方法、装置和可读介质，涉及报文检测技术领域。本发明提供的方法中，获取待检测的报文流；根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则；确定所述报文流满足的DSM规则所属的协议类型；利用确定出的协议类型对应的协议解析器处理所述报文流。通过采用上述方法，不再是接收到报文流后，立即大量的调用协议解析器对报文流中的数据包进行尝试匹配，而是确定报文流是否满足预设的DSM规则，在确定出满足DSM规则后，利用满足的DSM规则对应的协议类型的协议解析器来处理报文流，大大降低了匹配尝试的次数，且提高了报文流的匹配效率。

Description

一种报文流的处理方法、装置和可读介质

技术领域

本发明涉及报文检测技术领域，尤其涉及一种报文流的处理方法、装置和可读介质。

背景技术

深度报文检测(Deep Packet Inspection，DPI)被集成在多种网络***中。如防火墙、网络安全检测器，以及入侵检测***IDS等使用DPI来识别报文的协议来进一步检测应用层上的可能威胁。因政府法律和法规要求(如公安部82号令等要求酒店等提供公共WiFi的场所需要有审计功能)或者公司管理要求(如监视员工的因特网访问)而部署的网络安全审计***，会使用DPI来识别用户访问什么网站以及使用什么应用。DPI的处理速度非常关键，这是因为一个DPI实例经常需要处理来自很多终端的流量，这个数据量常常很大。因此在DPI产品中，处理速度是一个很重要的考量。

而DPI的核心工作是将接收到的报文流与已知的特征或模式进行匹配，简称特征匹配或模式匹配，目前有很多研究多集中在为模式匹配开发新算法上，如Kumar等人提出时滞型确定有限状态自动机(Delayed Input deterministic finite automaton，DelayedInput DFA)，极大地减少了DFA所需要的存储空间，以及Dharmapurikar等人提出将特征存储在bloom filter中来在硬件中实现快速匹配，但这都是对算法本身的改进。当接收到每一个报文流时，对报文流的处理依然还会立即调用各种类型的协议解析器尝试匹配该报文流，这样一来，不仅会增加匹配尝试次数，而且会存在不相关的协议解析器也尝试进行匹配所造成的资源的浪费。

因此，如何快速为报文流匹配一个合适的协议解析器是首要考虑的问题之一。

发明内容

本发明实施例提供一种报文流的处理方法，用以为每一报文流快速匹配到合适的协议解析器。

第一方面，本发明实施例提供一种报文流的处理方法，包括：

获取待检测的报文流；

根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则；

确定所述报文流满足的DSM规则所属的协议类型，其中，不同的协议类型对应不同的DSM规则；

利用确定出的协议类型对应的协议解析器处理所述报文流。

采用上述方法，通过设置DSM规则，不再是现有技术中直接用所有协议解析器均去匹配该报文流，以确定出该报文流合适的协议解析器，而是确定报文流符合的DSM规则的协议类型，然后再利用确定出的协议类型对应的协议解析器去匹配该报文流，从而大大降低了协议解析器进行匹配尝试的次数，提高了报文流的处理效率。

较佳地，所述协议类型至少包括以下一项：文件传输FTP协议、邮局协议POP3、超文本传输协议HTTP和安全传输的超文本传输协议HTTPS。

较佳地，所述数据包的属性信息包括数据包的传输层协议、服务器端口号和携带有负载的数据包的预设索引处的字节，所述数据包的统计信息包括携带有负载的数据包的数量；以及

根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则，具体包括：

在确定出获得的数据包的传输层协议为传输控制协议TCP后，判断所述数据包的服务器端口号是否为第一设定端口号；

在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；

在确定出所述数量不小于第一数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第一设定字符；

在判断结果为是时，确定所述报文流满足第一协议对应的延迟签名匹配DSM规则，所述第一协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种。

可选地，所述数据包的统计信息还包括已从所述报文流中获得的数据包的总数；以及

在确定出所述数量小于所述第一数量阈值时，或者在判断出携带有负载的数据包的预设索引处的字节不为第一设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第一设定总数阈值；

在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

较佳地，所述方法，还包括：

在判断出所述数据包的服务器端口号不为第一设定端口号时，判断所述数据包的服务器端口号是否为第二设定端口号；

在确定出所述数量不小于第二数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第二设定字符；

在判断结果为是时，确定所述报文流满足第二协议对应的延迟签名匹配DSM规则，所述第二协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，且所述第二协议不同于所述第一协议。

可选地，在确定出所述数量小于所述第二数量阈值时，或者在确定出携带有负载的数据包的预设索引处的字节不为第二设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第二设定总数阈值；

较佳地，所述数据包的统计信息还包括具有安全传输层协议的数据包的数量；以及所述方法，还包括：

在判断出所述数据包的服务器端口号不为第一设定端口号时，或者在判断出所述数据包的服务器端口号不为第二设定端口号时，判断所述数据包的服务器端口号是否为第三设定端口号；

在判断结果为是时，确定已从所述报文流中获得具有安全传输层协议的数据包的数量；

在确定出所述数量不小于第三数量阈值时，判断已从所述报文流中获得的携带有负载的数据包的数量是否不小于第四数量阈值；

在判断结果为是时，确定所述报文流满足第三协议对应的延迟签名匹配DSM规则，所述第三协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，所述第三协议不同于所述第一协议和所述第二协议。

可选地，在确定出所述数量小于第三数量阈值，或确定出所述数量小于第四数量阈值时，判断已从所述报文流中获得的数据包的总数是否不大于第三设定总数阈值；

较佳地，利用确定出的协议类型对应的协议解析器处理所述报文流，具体包括：

利用确定出的协议类型对应的协议解析器匹配所述报文流；

在匹配成功后，标记所述报文流为检测完成。

较佳地，若所述协议类型为HTTPS协议，则在匹配不成功后，判断是否已获取服务器标识，或者判断ssl_stage是否大于设定值；

在任一判断结果为是时，标记所述报文流以使下一时刻利用HTTPS协议对应的协议解析器处理所述报文流。

优选地，在根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流满足的延迟签名匹配DSM规则所属的协议类型之前，还包括

确定所述报文流未被标记。

第二方面，本发明实施例提供一种报文流的处理装置，包括：

获取单元，用于获取待检测的报文流；

第一确定单元，用于根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则；

第二确定单元，用于确定所述报文流满足的DSM规则所属的协议类型，其中，不同的协议类型对应不同的DSM规则；

处理单元，用于利用确定出的协议类型对应的协议解析器处理所述报文流。

优选地，所述数据包的属性信息包括数据包的传输层协议、服务器端口号和携带有负载的数据包的预设索引处的字节，所述数据包的统计信息包括携带有负载的数据包的数量；以及

所述第一确定单元，具体用于在确定出获得的数据包的传输层协议为传输控制协议TCP后，判断所述数据包的服务器端口号是否为第一设定端口号；在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；在确定出所述数量不小于第一数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第一设定字符；在判断结果为是时，确定所述报文流满足第一协议对应的延迟签名匹配DSM规则，所述第一协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种。

所述第一确定单元，还用于在确定出所述数量小于所述第一数量阈值时，或者在判断出携带有负载的数据包的预设索引处的字节不为第一设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第一设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

较佳地，所述第一确定单元，还用于在判断出所述数据包的服务器端口号不为第一设定端口号时，判断所述数据包的服务器端口号是否为第二设定端口号；在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；在确定出所述数量不小于第二数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第二设定字符；在判断结果为是时，确定所述报文流满足第二协议对应的延迟签名匹配DSM规则，所述第二协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，且所述第二协议不同于所述第一协议。

可选地，所述第一确定单元，还用于在确定出所述数量小于所述第二数量阈值时，或者在确定出携带有负载的数据包的预设索引处的字节不为第二设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第二设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

较佳地，所述数据包的统计信息还包括具有安全传输层协议的数据包的数量；以及

所述第一确定单元，还用于在判断出所述数据包的服务器端口号不为第一设定端口号时，或者在判断出所述数据包的服务器端口号不为第二设定端口号时，判断所述数据包的服务器端口号是否为第三设定端口号；在判断结果为是时，确定已从所述报文流中获得具有安全传输层协议的数据包的数量；在确定出所述数量不小于第三数量阈值时，判断已从所述报文流中获得的携带有负载的数据包的数量是否不小于第四数量阈值；在判断结果为是时，确定所述报文流满足第三协议对应的延迟签名匹配DSM规则，所述第三协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，所述第三协议不同于所述第一协议和所述第二协议。

可选地，所述第一确定单元，还用于在确定出所述数量小于第三数量阈值，或确定出所述数量小于第四数量阈值时，判断已从所述报文流中获得的数据包的总数是否不大于第三设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

优选地，所述处理单元，具体用于利用确定出的协议类型对应的协议解析器匹配所述报文流；在匹配成功后，标记所述报文流为检测完成。

较佳地，所述处理单元，具体用于若所述协议类型为HTTPS协议，则在匹配不成功后，判断是否已获取服务器标识，或者判断ssl_stage是否大于设定值；在任一判断结果为是时，标记所述报文流以使下一时刻利用HTTPS协议对应的协议解析器处理所述报文流。

较佳地，所述装置，还包括：

第三确定单元，用于在所述第一确定单元根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流满足的延迟签名匹配DSM规则所属的协议类型之前，确定所述报文流未被标记。

第三方面，本发明实施例提供一种通信设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序；所述处理器执行所述程序时实现如本申请提供的任一项所述的报文流的处理方法。

第四方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本申请提供的任一项所述的报文流的处理方法中的步骤。

本发明有益效果：

本发明实施例提供的报文流的处理方法、装置和可读介质，获取待检测的报文流；根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则；确定所述报文流满足的DSM规则所属的协议类型，其中，不同的协议类型对应不同的DSM规则；利用确定出的协议类型对应的协议解析器处理所述报文流。通过采用上述方法，不再是接收到报文流后，立即大量的调用协议解析器对报文流中的数据包进行尝试匹配，而是确定报文流是否满足预设的DSM规则，在确定出满足DSM规则后，利用满足的DSM规则对应的协议类型的协议解析器来处理报文流，大大降低了匹配尝试的次数，且提高了报文流的匹配效率。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本发明的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1为现有技术中典型FTP连接的前9个数据包的示意图；

图2为现有技术中nDPI引擎处理图1中的FTP连接的数据包的流程示意图；

图3为本发明实施例提供的实施报文流的处理方法的计算装置10的结构示意图；

图4为本发明实施例提供的报文流的处理方法的流程示意图；

图5为本发明实施例提供的确定报文流是否满足预设的延迟签名匹配DSM规则的流程示意图之一；

图6为本发明实施例提供的确定报文流是否满足预设的延迟签名匹配DSM规则的流程示意图之二；

图7为本发明实施例提供的确定报文流是否满足预设的延迟签名匹配DSM规则的流程示意图之三；

图8为本发明实施例提供的协议解析器处理报文流的流程示意图；

图9为本发明实施例提供的HTTPS协议对应的协议解析器在匹配不成功后执行的流程示意图；

图10为本发明实施例提供的报文流的处理装置的结构示意图。

具体实施方式

本发明实施例提供的报文流的处理方法，用以为每一报文流快速匹配到合适的协议解析器，减少匹配尝试次数，同时提高报文流的处理效率且节约处理资源。

以下结合说明书附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明，并且在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。

便于理解本发明，本发明涉及的技术术语中：

1、文件传输协议，即(File Transfer Protocol，FTP)是TCP/IP协议组中的协议之一。FTP协议包括两个组成部分，其一为FTP服务器，其二为FTP客户端。其中FTP服务器用来存储文件，用户可以使用FTP客户端通过FTP协议访问位于FTP服务器上的资源。在开发网站的时候，通常利用FTP协议把网页或程序传到Web服务器上。此外，由于FTP传输效率非常高，在网络上传输大的文件时，一般也采用该协议。默认情况下FTP协议使用TCP端口中的20和21这两个端口，其中20用于传输数据，21用于传输控制信息。

2、邮局协议-版本3，即(Post Office Protocol-Version 3，POP3)，它是一个关于接收电子邮件的客户/服务器协议。它是因特网电子邮件的第一个离线协议标准，允许用户从服务器上把邮件存储到本地主机(即自己的计算机)上，同时根据客户端的操作删除或保存在邮件服务器上的邮件。

3、超文本传输协议(HTTP,HyperText Transfer Protocol)是互联网上应用最为广泛的一种网络传输协议，所有的WWW文件都必须遵守这个标准。

4、安全传输的超文本传输协议，即(Hyper Text Transfer Protocol overSecureSocket Layer，HTTPS)，HTTPS是以安全为目标的HTTP通道，简单讲是HTTP的安全版。即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。它是一个URI scheme(抽象标识符体系)，句法类同http:体系，用于安全的HTTP数据传输。

5、协议类型，是指根据应用层协议划分的，应用层协议一般有POP3、POP3S、FTP、HTTP、HTTPS、TELNET、SMTP和DNS协议等等。相应地，本发明中协议类型对应的协议解析器也是应用层协议对应的协议解析器。

目前有很多DPI***，它们的一些性能比较可以参见。DPI***可以被大致分为两类：基于正则表达式和混合式的(结合正则表达式和代码)。L7filter是一个典型的基于正则表达式的DPI***，为不同协议定义了很多不同的正则表达式，一个协议的检测主要依赖于它相对应的正则表达式(但是它的正则表达式自2009年就没有被更新)。nDPI是一个混合式的DPI***，它从OpenDPI衍生(forked)出来，而OpenDPI又是从PACE这个前面提到的商业产品的早期版本中衍生出来，nDPI主要使用代码来匹配不同的协议，但是它在一些步骤如host name匹配中也支持自动机和Hyperscan。nDPI在Github上开源并由ntop公司活跃开发中。它可以检测240+的应用协议，并也在ntop的另一个产品nProbe中使用。nDPI中的一个guess_protocol_id技术是利用包端口等信息先猜测相应的协议解析器来尝试进行匹配，但是其guess_protocol_id技术只是基于端口和IP头中的protocol域的值，而且也无法完全消除无用的匹配尝试。

以判断报文流是否为FTP协议的报文流为例进行说明，参考图1所示。图1为典型FTP连接的前9个数据包的示意图。它包含了3次TCP握手，以及稍后的USER和PASS命令用于验证客户端“demo”。然后，图2中展示了nDPI引擎如何处理图1中的FTP连接的包。前3个数据包由10～12个协议解析器处理以进行特征匹配，因为只有少数解析器对TCP且无负载这种类型的数据包感兴趣。一些解析器分析后发现该flow与它们完全不匹配，因此它们很早就从报文流flow中排除了自己，以不去检测这个flow将来的包。对于数据包#4(图1中第4个数据包)，引擎首先尝试基于端口21猜测到的FTP协议解析器(基于前面提到的guess_protocol_id技术)，但是，FTP解析器此时仍然无法确认它是一个FTP报文流(它需要更多的数据包来确认)。接下来的数据包仍然没有被协议解析器检测成功，但更多的协议解析器排除自己检测该flow(即不再检测该flow将来的包)。最后，在数据包#7中的应答代码331使FTP协议解析器相信它是一个FTP报文流，并完成协议检测。实际应用中，可以计算这些协议解析器被一共调用了175次来识别该FTP连接，匹配尝试次数较多。

上述例子中，明显可以得出有些匹配的尝试是浪费的，例如，将数据包#4与那非FTP协议的103个协议解析器匹配，这注定是无用的。nDPI使用基于代码的FTP协议匹配，对于基于regex的DPI引擎(如L7Filter和Hyperscan)，情况类似。在L7Filter中，引擎不断地将新数据包的内容追加到流的接收内容缓冲区(最多2048个字节)，并将缓冲区与所有协议的模式匹配。L7过滤器可能使用模式"^220[x09-x0d-～]*ftp|331[x09-x0d-～]*PASS"以进行精确的FTP检测，那么，它显然也需要将该缓冲区与多个协议的协议解析器进行多次模式匹配，直到获取包含331应答代码的数据包#7，并将它追加到缓冲区后与该FTP协议的模式进行匹配。对于更高效的regex匹配代码库，虽然它只需要将新接收的数据包送到模式库中，但是每次包含所有协议的整个签名数据库都需要再次与新接收的数据包匹配。

基于上述描述，现有技术中在处理报文流时侧重于匹配算法本身，而不关注匹配算法的调度，故在接收到报文流后，依然需要将报文流中的数据包尝试进行各种模式匹配，即利用各种模式的协议解析器去判断该报文流是否需要自己处理，这样会导致匹配尝试次数较多，进而导致报文流处理效率低。

为了解决现有技术中存在的匹配尝试次数较多的问题，本发明给出了解决方案，即提出了一种计算装置10，由计算装置10来实施本发明提供的报文流的处理方法，该计算装置可以以通用计算设备的形式表现，该通用计算设备可以为通信设备，例如防火墙、网络安全检测器、入侵检测***等。下面参照图3来描述根据本发明的计算装置10。图3显示的计算装置10仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图3所示，计算装置10以通用计算设备的形式表现。计算装置10的组件可以包括但不限于：上述至少一个处理单元11、上述至少一个存储单元12、连接不同***组件(包括存储单元12和处理单元11)的总线13。

总线13表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器、***总线、处理器或者使用多种总线结构中的任意总线结构的局域总线。

存储单元12可以包括易失性存储器形式的可读介质，例如随机存取存储器(RAM)121和/或高速缓存存储器122，还可以进一步包括只读存储器(ROM)123。

存储单元12还可以包括具有一组(至少一个)程序模块124的程序/实用工具125，这样的程序模块124包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

计算装置10也可以与一个或多个外部设备14(例如键盘、指向设备等)通信，还可与一个或者多个使得用户能与计算装置10交互的设备通信，和/或与使得该计算装置10能与一个或多个其它计算设备进行通信的任何设备(例如路由器、调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口15进行。并且，计算装置10还可以通过网络适配器16与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器16通过总线13与用于计算装置10的其它模块通信。应当理解，尽管图中未示出，可以结合计算装置10使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID***、磁带驱动器以及数据备份存储***等。

本发明实施例提供的报文流的处理方法的应用场景是，计算装置10在获取到待检测的报文流时，根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则；确定所述报文流满足的DSM规则所属的协议类型，其中，不同的协议类型对应不同的DSM规则；利用确定出的协议类型对应的协议解析器处理所述报文流。这样一来，利用DSM规则可以快速确定出报文流所属的协议类型，然后由该协议类型对应的协议解析器匹配该报文流，而无需利用所有协议解析器均去匹配该报文流，有效减少了匹配尝试次数，从而也加快了报文流的处理速度。

基于上述应用场景，参考图4-图10来描述根据本发明示例性实施方式提供的报文流的处理方法。需要注意的是，上述应用场景仅是为了便于理解本发明的精神和原理而示出，本发明的实施方式在此方面不受任何限制。相反，本发明的实施方式可以应用于适用的任何场景。

如图4所示，为本发明实施例提供的报文流的处理方法的流程示意图，以将本发明提供的方法应用到计算装置10中为例进行说明，本发明提供的报文流的处理方法，可以包括以下步骤：

S11、获取待检测的报文流。

本步骤中的待检测的报文流可以为新接收到的报文流，也可以为未完成协议检测的报文流。而未完成协议检测的报文流是指根据DSM规则还未确定出报文流所采用的应用层协议，也即还未确定出用于处理该报文流的协议解析器，其中，根据DSM规则未确定出报文流所采用的协议的原因可以是从该报文流中获取到的数据包不够。

较佳地，在获取到报文流之后，在执行步骤S12之前，还可以包括：

确定所述报文流未被标记。

具体地，若确定出该报文流被标记，则表明已有其他协议解析器与该报文流匹配成功，则不再对该报文流执行后续处理流程，从而可以节省处理资源。

S12、根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则。

具体地，为了可以尽早确定出待检测的报文流属于哪类应用层协议，故本发明要基于报文流中获取的数据包的属性信息来确定报文流是否符合预设的延迟签名匹配(Delayed Signature Matching，DSM)规则，通过采用DSM规则从根本上减少了报文流与协议之间的匹配搜索次数。为了减少尝试匹配次数，本发明会对从报文流中获取到的数据包和/或携带有负载的数据包分别进行数量统计，这些统计结果即为数据包的统计信息，以及对数据包内是否携带负载等进行确定，而这些都是数据包的属性信息，然后基于这些属性信息和数据包的统计信息确定报文流满足哪一类协议对应的DSM规则。

本发明中，为目前常用的应用层协议配置相应的DSM规则。例如，为FTP协议、POP3协议、HTTP协议和HTTPS协议分别配置DSM规则。但具体实施时，为了减少计算复杂度和加快处理速度，这些规则可以综合使用。

较佳地，本发明中的协议类型可以但不限于包括以下至少一项：文件传输FTP协议、邮局协议POP3、超文本传输协议HTTP和安全传输的超文本传输协议HTTPS等。

本发明中的第一协议、第二协议和第三协议为FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，第一协议、第二协议和第三协议互不相同。

为了更好地理解本发明，本发明以FTP协议、POP3协议和HTTPS协议为例说明，以下分别详细介绍之：

由于FTP协议的报文流比较多，实际应用中，本发明先判断报文流是否符合FTP协议对应的DSM规则，即本发明中以第一协议为FTP协议为例进行说明，本领域技术人员可以理解的是，第一、第二和第三协议可以是与各实施例中不相同的其他类型的协议。如图5所示，为本发明实施例提供的确定报文流是否满足预设的延迟签名匹配DSM规则的流程示意图，本发明中的数据包的属性信息可以但不限于包括数据包的传输层协议、服务器端口号和携带有负载的数据包的预设索引处的字节等，以及本发明中数据包的统计信息可以但不限于包括携带有负载的数据包的数量等；图5所示的方法可以包括以下步骤：

S21、从报文流中获取数据包。

具体地，报文流中可以具有多个数据包，例如图1中FTP协议的报文流就有至少9个数据包，故需要通过从报文流中获取数据包来执行步骤S12。

S22、判断获得的数据包的传输层协议是否为传输控制协议TCP，若是，则执行步骤S23；否则执行步骤S29。

具体地，数据包是要经过一层层封装得到的，而根据通信***中开放式***互联参考模型(Open System Interconnection，OSI)，OSI模型有7层结构，由上到下分别是：应用层、表示层、会话层、传输层、网络层、数据链路层和物理层，故一般需要按照各层要求进行封装然后才能发送，故在接收到数据包后，可以确定出该数据包中的传输层协议是否为传输控制协议(TransmissionControl Protocol，TCP)，利用代码表示为：“protocol＝＝TCP？”，若确定出传输层协议为TCP协议时，则执行后续过程，否则按照现有的匹配流程处理该报文流。

S23、判断数据包的服务器端口号是否为第一设定端口号，若是则执行步骤S24；否则执行步骤S210，即判断数据包的服务器端口号是否为其他端口号。

具体地，由于FTP协议中常用的服务器端口为20和21等，则在设置FTP协议对应的DSM规则时，可以将第一设定端口号设置为20或21等，然后在本步骤中可以判断该数据包中的服务器端口号是否为21，利用代码表示为：“server_port＝＝21？”，如果是则表明该报文流可能与FTP协议相匹配，为了进一步确定该报文流是否与FTP协议匹配，则还需要执行后续步骤。如果不是，则可以确定出该报文流与FTP报文流不匹配，则可以继续判断该报文流中数据包的服务器端口号是否为其他协议常用的服务器端口号，后续详细介绍之。

S24、确定已从所述报文流中获得的携带有负载的数据包的数量。

具体地，一般情况下可以根据已从报文流中获取到的携带有负载的数据包的数量来确定该报文流所满足的DSM规则，故针对不同的协议类型，可以在该协议类型对应的DSM规则中配置数量阈值。

S25、判断所述数量是否不小于第一数量阈值；若是则执行步骤S26；否则执行步骤S28。

具体地，利用payload_pkt_num表示确定出的携带有负载的数据包的数量，则可以判断payload_pkt_num是否不小于第一数量阈值。具体实施时，FTP协议类型对应的DSM规则中的第一数量阈值可以为4。若确定出payload_pkt_num≥4，则表明已从报文流中接收到图1中第7个数据包“331Password required for demo”，则更进一步表明该报文流属于FTP协议的报文流。

S26、判断携带有负载的数据包的预设索引处的字节是否为第一设定字符；若是则执行步骤S27；否则执行步骤S28。

为了更准确地确定出该报文流为FTP报文流，本发明还可以确定已获取到的数据包中最后获取到的携带有负载的数据包是否满足索引i处的字节为第一设定字节，表达式为：“payload[i]＝＝‘A’？”，例如i为0，A为P时，则可以判断表达式“payload[0]＝＝‘P’？”是否成立，即“PASS命令的第一个字符是否为P”，若成立则执行步骤S27，即确定出该报文流满足FTP协议对应的DSM规则，也即准确地确定出该报文流为FTP协议的报文流。

S27、确定所述报文流满足FTP协议对应的延迟签名匹配DSM规则。

S28、判断已从所述报文流中获得的数据包的总数是否不大于第一设定总数阈值；若是则继续执行步骤S21；否则执行步骤S29。

本发明中的数据包的统计信息还包括已从所述报文流中获得的数据包的总数。

具体地，当步骤S25或步骤S26判断结果为否时，则表明目前从报文流中获取到的数据包可能存在因数量不够而导致无法证明该报文流就是FTP协议的报文流问题，故还需要进一步执行步骤S28，即确定当前从报文流中获取到的数据包是否足够。本发明中的第一设定总数阈值可配置，可以根据实际情况而定。具体实施时，用pkt_num表示已从报文流中获得的数据包的总数，以第一设定总数阈值为10为例进行说明，则可以判断表达式“pkt_num>10？”是否成立，若不成立，则表明当前从报文流中获取的数据包的数量还不够，不足以确定出报文流是否为FTP报文流，还需要再执行步骤S21，继续从该报文流中获取下一数据包，然后再执行步骤S22～S29所示的流程。若表达式“pkt_num>10？”成立，则表明当前已接收到足够数量的数据包，则表明该报文流不是FTP报文流，则从该报文流可能的协议列表中排除FTP，然后采用现有的报文流处理方法来处理该报文流。即执行步骤S29。

S29、采用现有技术提供的报文流处理方法处理报文流。

通过实施步骤S21～S29所示的流程，可以准确地确定出报文流是否符合FTP协议对应的DSM规则，也即可以确定出报文流是否为FTP报文流。

在此基础上，当确定出获得的数据包的服务器端口号不为第一设定端口号(20或21)时，判断是否为其他协议对应的端口号，此处以第二协议为POP3协议为例进行说明，则判断是否为POP3协议常用的端口号。参考图6所示，为本发明实施例提供的另一种确定报文流是否满足预设的延迟签名匹配DSM规则的流程示意图，包括以下步骤：

S31、判断从报文流获得的数据包的服务器端口号是否为第二设定端口号；若是则执行步骤S32；否则执行步骤S38，即判断数据包的服务器端口号是否为其他端口号。

具体地，各个协议类型的DSM规则是综合进行判断的，例如判断出数据包的服务器端口号不是第一设定端口号后，就不用再执行报文流是否符合FTP协议的DSM规则的流程，可以继续判断服务器端口号是否为POP3协议对应的DSM规则中配置的第二设定端口号。由于POP3协议的报文流常用的服务器端口号为110，则可以在POP3协议对应的DSM规则中配置第二设定端口号为110。当确定出数据包的端口号不为21时，则进一步判断表达式“server_port＝＝110？”是否成立，若成立，则表明该报文流可能为POP3协议的报文流，但还需要通过执行后续流程作进一步判断。

S32、确定已从所述报文流中获得的携带有负载的数据包的数量。

具体地，利用payload_pkt_num表示确定出的携带有负载的数据包的数量。

S33、判断所述数量是否不小于第二数量阈值；若是则执行步骤S34；否则执行步骤S36。

本发明中POP3协议对应的DSM规则中第二数量阈值可以设置为2，若确定出表达式“payload_pkt_num≥2？”成立，则表明已接收到能够证明该报文流为POP3报文流的数据包，则进一步证明该报文流属于POP3协议的报文流。

S34、判断携带有负载的数据包的预设索引处的字节是否为第二设定字符；若是则执行步骤S35；否则执行步骤S36。

为了进一步提高报文流属于POP3协议的报文流的准确性，则本发明还可以确定已获取到的数据包中最后获取到的携带有负载的数据包的索引j处的字节是否为第二设定字节，即判断表达式：“payload[j]＝＝‘B’”是否成立。本发明中的预设索引处的字节可以为j＝0处的字节，第二设定字符B可以为U，则可以判断“payload[0]＝＝‘U’？”是否成立，若成立，即表明获取到具有USER命令的数据包，则确定该报文流满足POP3协议对应的DSM规则，更进一步证明该报文流为POP3协议的报文流。

S35、确定所述报文流满足POP3协议对应的延迟签名匹配DSM规则。

S36、判断已从所述报文流中获得的数据包的总数是否不大于第二设定总数阈值；若是则继续执行步骤21，即继续从报文流中获取下一数据包；否则执行步骤S37。

当步骤S33或S34判断结果为否时，则表明目前从报文流中获取到的数据包可能存在由于数据包数量不够而导致无法证明该报文流就是POP3协议的报文流的问题，故还需要进一步执行步骤S36。本发明中的第二设定总数阈值可配置，可以根据实际情况而定。具体实施时，以POP3协议对应的DSM规则中的第二设定总数阈值为10为例进行说明，利用pkt_num表示已从报文流中获得的数据包的总数，则可以判断表达式“pkt_num>10？”是否成立，若不成立，则表明当前从报文流中获取的数据包的数量还不够，不足以确定出报文流是否为POP3报文流，还需要再执行步骤S21，继续从该报文流中获取下一数据包，然后再执行步骤S31～S37的流程。若表达式“pkt_num>10？”成立，则表明当前已接收到足够数量的数据包，则表明该报文流不是POP3报文流，则从该报文流可能的协议列表中排除POP3，然后采用现有的报文流处理方法来处理该报文流。即执行步骤S37。

S37、采用现有技术提供的报文流处理方法处理报文流。

通过实施步骤S31～S37所示的流程，可以准确地确定出报文流是否符合POP3协议对应的DSM规则，也即可以确定出报文流是否为POP3报文流。

在此基础上，当确定出获得的数据包的服务器端口号不为第一设定端口号时，或者确定出获得的数据包的服务器端口号不为第二设定端口号时，则判断是否为其他协议对应的端口号，此处以第三协议为HTTPS协议为例进行说明，则判断是否为HTTPS协议常用的端口号。具体参考图7所示，为本发明实施例提供的再一种确定报文流是否满足预设的延迟签名匹配DSM规则的流程示意图，包括以下步骤：

S41、判断从报文流中获得的数据包的服务器端口号是否为第三设定端口号；若是则执行步骤S42；否则执行步骤S48，即判断数据包的服务器端口号是否为其他端口号。

具体地，各个协议类型的DSM规则是综合进行判断的，例如判断出数据包的服务器端口号不是第一设定端口号后，就不用再执行报文流是否符合FTP协议对应的DSM规则的流程，或者在判断出数据包的服务器端口号不是第二设定端口号后，就不用再执行报文流是否符合POP3协议对应的DSM规则的流程，且可以继续判断服务器端口号是否为HTTPS协议对应的DSM规则中配置的第三设定端口号。由于HTTPS协议的报文流常用的服务器端口号为443，则可以在HTTPS协议对应的DSM规则中配置第三设定端口号为443。当确定出数据包的服务器端口号不为21时，或者确定出服务器端口号不为110时，则进一步判断表达式“server_port＝＝443？”是否成立，若成立，则表明该报文流可能为HTTPS协议的报文流，但为了提高结果的准确性，还需要通过执行后续流程作进一步判断。

S42、确定已从所述报文流中获得具有安全传输层协议的数据包的数量。

本发明中的数据包的统计信息还包括具有安全传输层协议的数据包的数量等。

具体地，利用tls_pkt_num表示确定出的具有安全传输层协议(TransportLayerSecurity，TLS)的数据包的数量。具体实施时，可以通过下述方法确定已从所述报文流中获得具有TLS记录层类型的数据包的数量：针对每一个从报文流中获取到的数据包，确定该数据包的第一个字节是否为以下字节中的一个：20、21、22和23，若是，则确定该数据包为具有安全传输层协议的数据包，进而可以确定出已从报文流中获得具有安全传输层协议的数据包的数量tls_pkt_num。需要说明的是，20标识更改密码规范(change_cipher_spec)；21标识警报(alert)；22标识握手(handshake)；23标识应用程序数据(applicationdata)。

S43、判断所述数量是否不小于第三数量阈值；若是，则执行步骤S44；否则执行步骤S46。

本发明中HTTPS协议对应的DSM规则中第三数量阈值可以设置为1，若确定出表达式“tls_pkt_num≥1？”成立，则表明至少接收到一个TLS数据包，例如，获取到具有Client_Hello消息的数据包，进一步表示该报文流较大可能为HTTPS协议的数据包。

S44、判断已从所述报文流中获得的携带有负载的数据包的数量是否不小于第四数量阈值；若是，则执行步骤S45；否则执行步骤S46。

为了准确判断，进一步确定已从报文流中获得的具有负载的数据包的数量，例如，利用payload_pkt_num表示确定出的携带有负载的数据包的数量。本发明中HTTPS协议对应的DSM规则中第二数量阈值可以设置为3，若确定出表达式“payload_pkt_num≥3？”成立，例如，确定获取到具有Client_Hello消息的数据包、Server_Hello消息和Certificate消息的数据包，则表明该报文流和可能是SSL/TLS连接，从而表明已接收到能够证明该报文流为HTTPS报文流的数据包，即确定报文流满足HTTPS协议对应的延迟签名匹配DSM规则，也即进一步证明该报文流属于HTTPS协议的报文流。

S45、确定所述报文流满足HTTPS协议对应的延迟签名匹配DSM规则。

S46、判断已从所述报文流中获得的数据包的总数是否不大于第三设定总数阈值；若是则继续执行步骤S21，即继续从报文流中获取下一数据包；否则执行步骤S47。

当步骤S43或S44判断结果为否时，则表明目前从报文流中获取到的数据包可能存在由于数据包数量不够而导致无法证明该报文流就是HTTPS协议的报文流的问题，故还需要进一步执行步骤S46。本发明中的第三设定总数阈值可配置，可以根据实际情况而定。具体实施时，以HTTPS协议对应的DSM规则中的第三设定总数阈值为10为例进行说明，利用pkt_num表示已从报文流中获得的数据包的总数，则可以判断表达式“pkt_num>10？”是否成立，若不成立，则表明当前从报文流中获取的数据包的数量还不够，不足以确定出报文流是否为HTTPS报文流，还需要再执行步骤S21，继续从该报文流中获取下一数据包，然后再执行步骤S41～S47的流程。若表达式“pkt_num>10？”成立，则表明当前已接收到足够数量的数据包，则表明该报文流不是HTTPS报文流，则从该报文流可能的协议列表中排除HTTPS，然后采用现有的报文流处理方法来处理该报文流。即执行步骤S47。

S47、采用现有技术提供的报文流处理方法处理报文流。

通过实施步骤S41～S47所示的流程，可以准确地确定出报文流是否符合HTTPS协议对应的DSM规则，也即可以确定出报文流是否为HTTPS报文流。

S13、确定所述报文流满足的DSM规则所属的协议类型。

其中，不同的协议类型对应不同的DSM规则。

具体地，若确定出该报文流满足图5所示的DSM规则，则确定DSM规则所属的协议类型为FTP协议；若确定出该报文流满足图6所示的DSM规则，则确定满足的DSM规则所属的协议类型为POP3协议；若确定出该报文流满足图7所示的DSM规则，则确定满足的DSM规则所属的协议类型为HTTPS协议。

S14、利用确定出的协议类型对应的协议解析器处理所述报文流。

基于步骤S12和S13确定出待检测的报文流所属的协议类型后，可以利用确定出的协议类型对应的协议解析器按照图8所示的流程处理报文流，包括以下步骤：

S51、利用确定出的协议类型对应的协议解析器匹配报文流。

S52、在匹配成功后，标记所述报文流为检测完成。

在确定出报文流所属的协议后，再利用该协议对应的协议解析器去匹配该报文流，在匹配成功后，表明该报文流真正属于该协议，为了避免该报文流候选再被作为未检测的报文流而再次执行本发明提供的报文流处理方法所带来的处理资源的浪费，本发明提出标记匹配成功的报文流。这样一来，在获取到报文流后，可以首先确定该报文流是否被标记，如果被标记则对该报文流不进行处理，这样可以有效节省处理资源。

通过设置DSM规则，不再是现有技术中直接用所有协议解析器均去匹配该报文流，以确定出该报文流合适的协议解析器，而是确定报文流符合的DSM规则的协议类型，然后再利用确定出的协议类型对应的协议解析器去匹配该报文流，从而大大降低了协议解析器进行匹配尝试的次数，提高了报文流的处理效率。

较佳地，当确定出报文流属于HTTPS报文流后，如果步骤S51匹配失败时，则此处不能简单的从该报文流可能的协议列表中排除HTTPS，因为可能是TLS类型的报文流，但需要更多的数据包来进一步检测其应用协议。具体地，可以按照图9所示的流程实施：

S61、判断是否已获取服务器标识；若是则执行步骤S63；否则执行步骤S64。

S62、判断ssl_stage是否大于设定值；若是则执行步骤S63；否则执行步骤S64。

S63、标记所述报文流以使下一时刻利用HTTPS协议对应的协议解析器处理所述报文流。

S64、从该报文流可能的协议列表中排除HTTPS。

S65、采用现有技术提供的报文流处理方法处理报文流。

步骤S61～S65中，通过检测是否已获取到服务器名称，具体可以根据TLS的服务器名称指示(SNI)扩展，或服务器的证书来确定是否已获取到服务器的名称。或者确定是否TLS交互过程中已经过了一些阶段，具体地，利用ssl_stage来表示，通过将这些规则加入到HTTPS协议对应的DSM规则中，来确定该报文流是否为HTTPS中的TLS流。如果步骤S61或步骤S62任一判断结果为是时，则确定该报文流为TLS流，则标记该报文流始终使用所选的HTTP协议中的TLS协议解析器来处理该报文流，否则表明该报文流不属于HTTPS协议的报文流，则从该报文流可能的(疑似)协议列表中排除HTTPS，并采用现有技术提供的报文流处理方法处理报文流。

需要说明的是，步骤S61和S62可以同时执行，也可以先执行步骤S62再执行步骤S62；或者先执行步骤S62，再执行步骤S61。本发明对S61和S62的执行顺序不进行限定。

需要说明的是，为各种应用层协议配置DSM规则时，需要根据各应用层协议的自身特点，将应用层协议的特点体现在DSM规则中，例如FTP协议、POP3协议和HTTPS协议常用的服务器端口号不同，故在各自的DSM规则中设置对应的服务器端口号；再者，在对HTTP协议配置DSM规则时，可以设置携带有负载的数据包的预设索引i处的预设长度个字节是否为预设字节，例如：为HTTP协议配置的DSM规则中，设置payload(i,len)＝＝“ABC”等式检查规则，旨在检查从报文流获取到的携带有负载的数据包的从索引i处开始len个字节是否等于字符串“ABC”，本发明中的i，len和ABC可以根据实际情况进行配置，此处不对其值进行限定。

可选地，本发明中需要定期找出应用了DSM的(即，具有缓冲的数据包)但是阻塞(即“卡住”)了一段时间的报文流，并使用现有的处理方法来处理它们。这是因为一个报文流可能满足某协议的部分DSM规则但不能完全满足，例如payload_pkt_num不够，而另一方面该报文流自身没有足够的数据包来最终满足阈值规则，即pkt_num≥10规则。这时，如果不使用原来处理方法来处理该报文流，那即使某些解析器可以识别该报文流，该也不会被任何解析器处理。因此，本发明设置了阻塞时间阈值，例如将阻塞时间阈值设置为2秒，这对于现有协议应该足够了。通过定期检查是否存在阻塞时间大于阻塞时间阈值的报文流，如果存在则利用现有的处理方法处理该报文流。此外，这种定期检查“卡住”的报文流可以与清理失效(idle)的报文流一起完成，以复用遍历flow树的过程，提高效率。

需要说明的是，定义DSM规则。首先，在开始特征匹配之前，本发明采用等待超过足够的数量的数据包(例如，对于FTP，我们需要payload_pkt_num≥4)。这是因为更多数据包通常意味着更多关于报文流类型的证据，因此所选协议解析器的成功概率更高。这可能不适合需要尽可能早地识别报文流所属协议的场合，如防火墙或中的IDS，但适用于网络安全审计(对时延容忍度更高)。此外，本发明设定的DSM规则中可能有些阈值比较宽松，例如，对于TLS协议，tls_pkt_num≥1，以适应不同的审计场景和数据包传输策略，目的是，使得制定的DSM规则“可移植性”(一次编写，适合所有场合)更高。比如在网络审计场景中，主要仅捕获一个方向(上行)的数据包，而且还发现TLS可以在一个TCP数据包中传输多个记录层(record layer)数据包。基于这两个因素，本发明设定的DSM规则会需要比相应解析器实际需要的数据包更多。

本发明提供的报文流处理方法，获取待检测的报文流；根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则；确定所述报文流满足的DSM规则所属的协议类型，其中，不同的协议类型对应不同的DSM规则；利用确定出的协议类型对应的协议解析器处理所述报文流。通过采用上述方法，不再是接收到报文流后，立即大量的调用协议解析器对报文流中的数据包进行尝试匹配，而是确定报文流是否满足预设的DSM规则，在确定出满足DSM规则后，利用满足的DSM规则对应的协议类型的协议解析器来处理报文流，大大降低了匹配尝试的次数，且提高了报文流的匹配效率。

基于同一发明构思，本发明实施例中还提供了一种报文流的处理装置，由于上述装置解决问题的原理与报文流的处理方法相似，因此上述装置的实施可以参见方法的实施，重复之处不再赘述。

如图10所示，为本发明实施例提供的报文流的处理装置的结构示意图，包括：

获取单元71，用于获取待检测的报文流；

第一确定单元72，用于根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则；

第二确定单元73，用于确定所述报文流满足的DSM规则所属的协议类型，其中，不同的协议类型对应不同的DSM规则；

处理单元74，用于利用确定出的协议类型对应的协议解析器处理所述报文流。

所述第一确定单元72，具体用于在确定出获得的数据包的传输层协议为传输控制协议TCP后，判断所述数据包的服务器端口号是否为第一设定端口号；在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；在确定出所述数量不小于第一数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第一设定字符；在判断结果为是时，确定所述报文流满足第一协议对应的延迟签名匹配DSM规则，所述第一协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种。

所述第一确定单元72，还用于在确定出所述数量小于所述第一数量阈值时，或者在判断出携带有负载的数据包的预设索引处的字节不为第一设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第一设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

较佳地，所述第一确定单元72，还用于在判断出所述数据包的服务器端口号不为第一设定端口号时，判断所述数据包的服务器端口号是否为第二设定端口号；在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；在确定出所述数量不小于第二数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第二设定字符；在判断结果为是时，确定所述报文流满足第二协议对应的延迟签名匹配DSM规则，所述第二协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，且所述第二协议不同于所述第一协议。

可选地，所述第一确定单元72，还用于在确定出所述数量小于所述第二数量阈值时，或者在确定出携带有负载的数据包的预设索引处的字节不为第二设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第二设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

所述第一确定单元72，还用于在判断出所述数据包的服务器端口号不为第一设定端口号时，或者在判断出所述数据包的服务器端口号不为第二设定端口号时，判断所述数据包的服务器端口号是否为第三设定端口号；在判断结果为是时，确定已从所述报文流中获得具有安全传输层协议的数据包的数量；在确定出所述数量不小于第三数量阈值时，判断已从所述报文流中获得的携带有负载的数据包的数量是否不小于第四数量阈值；在判断结果为是时，确定所述报文流满足第三协议对应的延迟签名匹配DSM规则，所述第三协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，所述第三协议不同于所述第一协议和所述第二协议。

可选地，所述第一确定单元72，还用于在确定出所述数量小于第三数量阈值，或确定出所述数量小于第四数量阈值时，判断已从所述报文流中获得的数据包的总数是否不大于第三设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

优选地，所述处理单元74，具体用于利用确定出的协议类型对应的协议解析器匹配所述报文流；在匹配成功后，标记所述报文流为检测完成。

较佳地，所述处理单元74，具体用于若所述协议类型为HTTPS协议，则在匹配不成功后，判断是否已获取服务器标识，或者判断ssl_stage是否大于设定值；在任一判断结果为是时，标记所述报文流以使下一时刻利用HTTPS协议对应的协议解析器处理所述报文流。

较佳地，所述装置，还包括：

第三确定单元75，用于在所述第一确定单元72根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流满足的延迟签名匹配DSM规则所属的协议类型之前，确定所述报文流未被标记。

为了描述的方便，以上各部分按照功能划分为各模块(或单元)分别描述。当然，在实施本发明时可以把各模块(或单元)的功能在同一个或多个软件或硬件中实现。

基于同一发明构思，本发明实施例提供一种通信设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序；所述处理器执行所述程序时实现如本发明实施例一提供的任一项所述的报文流的处理方法。

在一些可能的实施方式中，本发明提供的报文流的处理方法的各个方面还可以实现为一种程序产品的形式，其包括程序代码，当所述程序产品在计算机设备上运行时，所述程序代码用于使所述计算机设备执行本说明书上述描述的根据本发明各种示例性实施方式的报文流的处理方法中的步骤，例如，所述计算机设备可以执行如图4所示的步骤S11～S14中报文流的处理流程。

所述程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的***、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

本发明的实施方式的用于报文流的处理方法的程序产品可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在计算设备上运行。然而，本发明的程序产品不限于此，在本文件中，可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行***、装置或者器件使用或者与其结合使用。

可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括——但不限于——电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质，该可读介质可以发送、传播或者传输用于由指令执行***、装置或者器件使用或者与其结合使用的程序。

可读介质上包含的程序代码可以用任何适当的介质传输，包括——但不限于——无线、有线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言的任意组合来编写用于执行本发明操作的程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、作为一个独立的软件包执行、部分在用户计算设备上部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算设备，或者，可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。

应当注意，尽管在上文详细描述中提及了装置的若干单元或子单元，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元的特征和功能可以在一个单元中具体化。反之，上文描述的一个单元的特征和功能可以进一步划分为由多个单元来具体化。

此外，尽管在附图中以特定顺序描述了本发明方法的操作，但是，这并非要求或者暗示必须按照该特定顺序来执行这些操作，或是必须执行全部所示的操作才能实现期望的结果。附加地或备选地，可以省略某些步骤，将多个步骤合并为一个步骤执行，和/或将一个步骤分解为多个步骤执行。

本申请的实施例所提供的报文流的处理装置可通过计算机程序实现。本领域技术人员应该能够理解，上述的模块划分方式仅是众多模块划分方式中的一种，如果划分为其他模块或不划分模块，只要报文流的处理装置具有上述功能，都应该在本申请的保护范围之内。

本领域内的技术人员应明白，本发明的实施例可提供为方法、***、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本发明的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本发明范围的所有变更和修改。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种报文流的处理方法，其特征在于，包括：

获取待检测的报文流；

根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则，其中，所述数据包的属性信息包括数据包的传输层协议、服务器端口号和携带有负载的数据包的预设索引处的字节，所述数据包的统计信息包括携带有负载的数据包的数量；以及根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则，具体包括：在确定出获得的数据包的传输层协议为传输控制协议TCP后，判断所述数据包的服务器端口号是否为第一设定端口号；在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；在确定出所述数量不小于第一数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第一设定字符；在判断结果为是时，确定所述报文流满足第一协议对应的延迟签名匹配DSM规则，所述第一协议为FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种；

利用确定出的协议类型对应的协议解析器处理所述报文流。

2.如权利要求1所述的方法，其特征在于，所述协议类型至少包括以下一项：文件传输FTP协议、邮局协议POP3、超文本传输协议HTTP和安全传输的超文本传输协议HTTPS。

3.如权利要求1所述的方法，其特征在于，所述数据包的统计信息还包括已从所述报文流中获得的数据包的总数；以及

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

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

在确定出所述数量小于所述第二数量阈值时，或者在确定出携带有负载的数据包的预设索引处的字节不为第二设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第二设定总数阈值；

6.如权利要求1或4所述的方法，其特征在于，所述数据包的统计信息还包括具有安全传输层协议的数据包的数量；以及所述方法，还包括

在判断结果为是时，确定所述报文流满足第三协议对应的延迟签名匹配DSM规则，所述第三协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，所述第三协议不同于所述第一协议和第二协议。

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

在确定出所述数量小于第三数量阈值，或确定出所述数量小于第四数量阈值时，判断已从所述报文流中获得的数据包的总数是否不大于第三设定总数阈值；

8.如权利要求1所述的方法，其特征在于，利用确定出的协议类型对应的协议解析器处理所述报文流，具体包括：

利用确定出的协议类型对应的协议解析器匹配所述报文流；

在匹配成功后，标记所述报文流为检测完成。

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

若所述协议类型为HTTPS协议，则在匹配不成功后，判断是否已获取服务器标识，或者判断ssl_stage是否大于设定值；

10.如权利要求1所述的方法，其特征在于，在根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流满足的延迟签名匹配DSM规则所属的协议类型之前，还包括

确定所述报文流未被标记。

11.一种报文流的处理装置，其特征在于，包括：

获取单元，用于获取待检测的报文流；

第一确定单元，用于根据从所述报文流中获得的数据包的属性信息和数据包的统计信息，确定所述报文流是否满足预设的延迟签名匹配DSM规则，其中，所述数据包的属性信息包括数据包的传输层协议、服务器端口号和携带有负载的数据包的预设索引处的字节，所述数据包的统计信息包括携带有负载的数据包的数量；以及所述第一确定单元，具体用于在确定出获得的数据包的传输层协议为传输控制协议TCP后，判断所述数据包的服务器端口号是否为第一设定端口号；在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；在确定出所述数量不小于第一数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第一设定字符；在判断结果为是时，确定所述报文流满足第一协议对应的延迟签名匹配DSM规则，所述第一协议为FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种；

12.如权利要求11所述的装置，其特征在于，所述协议类型至少包括以下一项：文件传输FTP协议、邮局协议POP3、超文本传输协议HTTP和安全传输的超文本传输协议HTTPS。

13.如权利要求11所述的装置，其特征在于，所述数据包的统计信息还包括已从所述报文流中获得的数据包的总数；以及

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

所述第一确定单元，还用于在判断出所述数据包的服务器端口号不为第一设定端口号时，判断所述数据包的服务器端口号是否为第二设定端口号；在判断结果为是时，确定已从所述报文流中获得的携带有负载的数据包的数量；在确定出所述数量不小于第二数量阈值时，判断携带有负载的数据包的预设索引处的字节是否为第二设定字符；在判断结果为是时，确定所述报文流满足第二协议对应的延迟签名匹配DSM规则，所述第二协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，且所述第二协议不同于所述第一协议。

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

所述第一确定单元，还用于在确定出所述数量小于所述第二数量阈值时，或者在确定出携带有负载的数据包的预设索引处的字节不为第二设定字符，则判断已从所述报文流中获得的数据包的总数是否不大于第二设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

16.如权利要求11或14所述的装置，其特征在于，所述数据包的统计信息还包括具有安全传输层协议的数据包的数量；以及

所述第一确定单元，还用于在判断出所述数据包的服务器端口号不为第一设定端口号时，或者在判断出所述数据包的服务器端口号不为第二设定端口号时，判断所述数据包的服务器端口号是否为第三设定端口号；在判断结果为是时，确定已从所述报文流中获得具有安全传输层协议的数据包的数量；在确定出所述数量不小于第三数量阈值时，判断已从所述报文流中获得的携带有负载的数据包的数量是否不小于第四数量阈值；在判断结果为是时，确定所述报文流满足第三协议对应的延迟签名匹配DSM规则，所述第三协议为所述FTP协议、POP3协议、HTTP协议和HTTPS协议中的一种，所述第三协议不同于所述第一协议和第二协议。

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

所述第一确定单元，还用于在确定出所述数量小于第三数量阈值，或确定出所述数量小于第四数量阈值时，判断已从所述报文流中获得的数据包的总数是否不大于第三设定总数阈值；在判断结果为是时，继续从所述报文流中获取数据包，并继续确定所述报文流是否满足预设的DSM规则。

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

所述处理单元，具体用于利用确定出的协议类型对应的协议解析器匹配所述报文流；在匹配成功后，标记所述报文流为检测完成。

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

所述处理单元，具体用于若所述协议类型为HTTPS协议，则在匹配不成功后，判断是否已获取服务器标识，或者判断ssl_stage是否大于设定值；在任一判断结果为是时，标记所述报文流以使下一时刻利用HTTPS协议对应的协议解析器处理所述报文流。

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

21.一种通信设备，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序；其特征在于，所述处理器执行所述程序时实现如权利要求1～10任一项所述的报文流的处理方法。

22.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求1～10任一项所述的报文流的处理方法中的步骤。