CN102932203A - 异构平台间的深度报文检测方法及装置 - Google Patents

Abstract

本发明提供了一种基于异构平台的深度报文检测方法，包括：当在FPGA架构下的第一平台上判断出所接收报文的对应会话表项中包含需要进行深度报文检测的指示信息时，在第一平台上对该报文进行协议分析来确定承载协议；基于预先定义的承载协议-多模匹配映射表，确定是否需要进行多模匹配；在需要时，在第一平台上，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配；以及在多模匹配命中后，将该报文和多模匹配结果发送到第二平台，并在第二平台中基于多模匹配结果，对该报文进行深度报文检测。利用该方法，可以减少上传到第二平台中进行处理的报文流量以及第二平台中的计算负担。

Description

异构平台间的深度报文检测方法及装置

技术领域

本发明涉及数据处理领域，更为具体地，涉及一种异构平台间的深度报文检测方法和装置。

背景技术

传统的网络安全设备通常涉及L3/L4（网络层和传输层）级别的安全防护，并且可以采用异构平台实现，所述异构平台通常包括FPGA架构下的第一平台以及X86架构下的第二平台。

FPGA(Field-programmable gate array)，即现场可编程门阵列，是可重新编程的硅芯片。广泛采用FPGA芯片是源于FPGA综合了ASIC和传统处理器的最大优势。FPGA能够提供硬件定时的速度和稳定性，且无需比如自定制ASIC设计的巨额前期费用的大规模投入。可重新编程的硅芯片的灵活性与在基于处理器的系统上运行的软件在某些逻辑实现上相当。与处理器不同的是，FPGA属于真正的并行实行，因此不同的处理操作无需竞争相同的资源。每个独立的处理任务都配有专用的芯片部分，能在不受其它逻辑块的影响下自主运作。因此，添加更多处理任务时，其它应用性能也不会受到影响。

但是FPGA技术并不能真正代替传统处理器，毕竟FPGA使用的预建逻辑块和可重新编程布线资源都是有限的，这也就制约FPGA不可能实现过于复杂的逻辑运算。作为传统通用处理器的代表，X86平台显然在这方面具有优势，通过运行其上的软件，可以很好地实现复杂业务逻辑。由此，结合FPGA和X86的优点，利用异构平台来实现网络安全设备。

通常，异构平台对于传统网络安全设备的需求是有优势的，这种优势在架构上的主要体现是：

首先，记录状态检测的核心Session数据结构可硬件化，并可以提供所有操作的原子操作，基于Session在架构层面很容易将系统划分为快速通路和慢速通路，所有已经记录在Session中得报文会话可以通过硬件直接转发。

其次，对报文分类的方式主要是通过包分类算法实现，在这里需要的包分类主要是依据L3和L4报文头中三层或四层地址信息，逻辑相对简单，可以通过硬件的专有查表芯片实现，这使大多数的新建连接操作也是可以通过硬件来完成。

上述两点使得在网络报文的处理上能够很好的符合二八原则，也就是大多数的报文都可以通过硬件直接转发，而少数逻辑相对复杂、处理流程较长的可以通过慢速处理实现。

此外，不同平台之间的耦合度相对较小，平台之间的交互主要为配置信息以及慢速数据报文等，这使得异构平台之间的消息交换代价相对较小。

图1示出了传统需求下的异构平台架构的示意图，在图1中，主要示出了两个数据通路在不同平台下的流位置和调用关系。

然而，随着整个社会信息化程度的不断加深，尤其是越来越多的业务加速转移到云端，针对报文进行的数据处理面临的安全风险也越来越复杂。在这种情况下，L3/L4（网络层和传输层）级别的传统安全防护已经无法满足复杂多样的需求。由此，在下一代网络安全产品中，要求对报文的处理越来越深入和复杂，它不仅仅要求对传统报文头部进行处理，而且要求对报文的负载（L7应用层）进行处理，包括对报文的负载进行深度检测。为了对报文的负载进行深度检测，需要引入深度报文检测（DPI，Deep Packet Inspector）技术。

DPI是目前识别和鉴定协议及应用（IP流）的最重要的技术。所谓“深度报文检测”，“深度”是和标准数据包分析层次相比较而言的，“标准数据包检测”仅仅分析IP包的4层以下的基础信息，包括源IP地址、目的IP地址、源端口、目的端口以及连接状态，这些信息保存在数据包的4层以下的包头内。而DPI除了对4层以下的基础信息进行分析外，还增加了应用层分析，识别各种应用及其内容。这是通过对一系列数据报文的报头以及负载中的签名特征（Signature）进行分析，如图2所示。图2示出了基于负载中的多模特征进行应用层分析的示意图，所述多模特征是对应用进行分析后得出的与应用相关的特征。

由于DPI（深度报文检测）的引入，给原有的网络安全设备的架构带来了新的挑战。图3示出了新需求下异构平台架构的示意图，在图3中，示出了两个数据通路在当前需求下所遭遇的主要矛盾。

在传统的报文检测中，仅仅分析IP包的4层以下的内容，包括源地址、目的地址、源端口、目的端口以及协议类型。而DPI除了关注上述层次外，还增加了应用层分析。对于不同应用而言，通常都要依赖不同的承载协议。不同协议承载不同应用时，通过不同的特征来进行识别。这些特征的形式千变万化，一般来说可以通过静态特征字匹配、动态特征匹配以及状态特征匹配三种技术来识别判断。还有一些特殊的应用甚至需要分析协议本身的行为模式，具体可能是协议的微观行为模型，也可能是协议宏观的统计模型。上述这些分析机制的复杂性，使得DPI逻辑不适于硬件实现，只能要求更多的深度检测工作交给CPU。

此外，与传统连接首包的检测机制不同，DPI要求将连接中的更多负载流量提交到CPU进行分析，这使得异构平台间的流量违反了二八模型，造成大多数的报文走慢速通路，从而增加了CPU的IO开销和计算负担，由此使得异构平台的优势难以发挥。

由于DPI的引入而导致的上述方式转变，造成报文处理的路径变长，从而导致网络安全设备的吞吐量和延时等关键指标大幅度下降。

此外，硬件和CPU之间的总线成为瓶颈。虽然CPU总线技术（这是PCIE，已经发展到PCIE3.0）发展很快，但是难以满足当前异构平台完成上述需求的要求。由此产生的直接问题是一旦出现性能瓶颈，频繁的丢包乱序将极大的增加最终的应用识别的漏判和误判。

从上面可以看出，DPI的引入改变了原有的报文转发路径，使得绝大多数的报文都需要CPU处理，增加了CPU的处理负担，以及凸显CPU总线的瓶颈。

在遭遇上述问题时，异构平台在架构最通常的解决手段是Cache机制的引入，主要思想就是将慢速通路中DPI的匹配识别结果作为Cache下发到硬件中进行加速，但是DPI问题的复杂性导致通常的Cache机制是不适于当前问题的。主要原因是DPI识别的结果一般是通过协议中得目的IP和服务号来标识，但是相同的IP和服务号有可能携带有其他的应用特征，所以不能反向推证。

因此，需要一种新的基于异构平台的深度报文检测方法及装置。

发明内容

鉴于上述，本发明的目的在于提供一种异构平台间的深度报文检测方法及装置，该方法及装置能够减少深度报文检测时X86架构下的第二平台的计算负担和计算复杂度，并且减少异构平台间的数据流量。

根据本发明的一个方面，提供了一种基于异构平台的深度报文检测方法，所述异构平台包括FPGA架构下的第一平台以及X86架构下的第二平台，所述方法包括：当在第一平台上判断出第一平台所接收报文的会话表项包含需要进行深度报文检测的指示信息时，在第一平台上，对所接收报文进行协议分析，以确定该报文的承载协议；基于所确定出的承载协议以及预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配，所述承载协议-多模匹配映射表表示承载协议与是否需要对该承载协议进行多模匹配之间的映射关系；在确定需要对该报文进行多模匹配时，在第一平台上，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配，所述多模特征集合中的每个多模特征是通过对应用的应用签名特征进行分析后归纳出的并且对应于多个应用；以及在多模匹配命中后，将该报文和多模匹配结果发送到第二平台，并且在第二平台中，基于多模匹配结果，对该报文进行深度报文检测。

在上述方面的一个或多个示例中，在确定不需要对该报文进行多模匹配时，在第一平台上，基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议，所述预先定义的承载协议库中的每个承载协议是需要继续进行深度报文分析的承载协议；以及在识别出所述承载协议属于需要继续进行深度报文分析的承载协议时，将该报文发送到第二平台中进行深度报文检测，或者在识别出所述承载协议不属于需要继续进行深度报文分析的承载协议时，在所述第一平台中对该报文进行转发预处理。

在上述方面的一个或多个示例中，所述承载协议和多模特征采用形式化语言描述，并且预先定义的承载协议-多模匹配映射表、承载协议库和多模特征集合在所述第一平台中被实现为状态机或状态机集合。

在上述方面的一个或多个示例中，基于预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配包括：将所接收的报文遍历基于预定定义的承载协议-多模匹配映射表实现的状态机或状态机集合来进行多模匹配确定，以及基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议包括：将该报文遍历基于预定定义的承载协议库实现的状态机或状态机集合来进行承载协议识别。

在上述方面的一个或多个示例中，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配包括：将该报文遍历基于预先定义的与应用相关的多模特征集合实现的状态机或状态机集合来进行多模匹配。

在上述方面的一个或多个示例中，所述预先定义的承载协议-多模匹配映射表、预先定义的承载协议库和多模特征集合根据用户需求进行更新。

在上述方面的一个或多个示例中，与应用相关的多模特征集合包括与应用相关的静态特征、动态特征和/或状态特征。

根据本发明的另一方面，提供了一种基于异构平台的深度报文检测装置，所述异构平台包括FPGA架构下的第一平台以及X86架构下的第二平台，所述深度报文检测装置包括：承载协议确定单元，位于第一平台中，用于当在第一平台上判断出第一平台所接收报文的会话表项包含需要进行深度报文检测的指示信息时，对所接收报文进行协议分析，以确定该报文的承载协议；多模匹配确定单元，位于所述第一平台中，用于基于所确定出的承载协议以及预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配，所述承载协议-多模匹配映射表表示承载协议与是否需要对该承载协议进行多模匹配之间的映射关系；多模匹配单元，位于所述第一平台中，用于在确定需要对该报文进行多模匹配时，在第一平台上，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配，所述多模特征集合中的每个多模特征是通过对应用的应用签名特征进行分析后归纳出的并且对应于多个应用；发送单元，位于所述第一平台中，用于在多模匹配命中后，将该报文和多模匹配结果发送到第二平台；以及深度报文检测单元，位于第二平台中，用于基于多模匹配结果，对该报文进行深度报文检测。

在上述方面的一个或多个示例中，所述深度报文检测装置还可以包括：承载协议识别单元，位于所述第一平台中，用于在确定不需要对该报文进行多模匹配时，基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议，所述预先定义的承载协议库中的每个承载协议是需要继续进行深度报文分析的承载协议，以及在识别出所述承载协议属于需要继续进行深度报文分析的承载协议时，所述发送单元将该报文发送到第二平台中进行深度报文检测，或者在识别出所述承载协议不属于需要继续进行深度报文分析的承载协议时，在所述第一平台中对该报文进行转发预处理。

利用上述基于异构平台的深度报文检测方法及装置，可以通过对FPGA架构下的第一平台所接收的报文进行多模匹配（以及承载协议识别），对原本要上传到X86架构下的第二平台进行处理的报文进行分流处理，并且得到基于多模匹配进行的中间分析结果，然后在X86架构下的第二平台中基于多模匹配得到的中间分析结果继续进行深度报文检测，从而减少上传到X86架构下的第二平台中进行处理的报文流量以及第二平台中的计算负担。

为了实现上述以及相关目的，本发明的一个或多个方面包括后面将详细说明并在权利要求中特别指出的特征。下面的说明以及附图详细说明了本发明的某些示例性方面。然而，这些方面指示的仅仅是可使用本发明的原理的各种方式中的一些方式。此外，本发明旨在包括所有这些方面以及它们的等同物。

附图说明

根据下述参照附图进行的详细描述，本发明的上述和其他目的、特征和优点将变得更加显而易见。在附图中：

图1示出了传统需求下的X86/FPGA架构平台的示意图；

图2示出了基于负载中的多模特征进行应用层分析的示意图；

图3示出了新需求下异构平台架构的示意图；

图4示出了一个微博应用的数据包结构；

图5示出了通常网络协议和应用构建成的规则树；

图6示出了根据本发明的基于异构平台的深度报文检测方法的流程图；

图7示出了根据本发明的承载协议-多模匹配映射表的一个示例；

图8示出了根据本发明的一个示例的承载协议库中的数据结构的示意图；

图9示出了基于异构平台的报文处理方法的一个示例的流程图；和

图10示出了根据本发明的基于异构平台的深度报文检测装置的方框示意图。

在所有附图中相同的标号指示相似或相应的特征或功能。

具体实施方式

下面描述本公开的各个方面。应该明白的是，本文的教导可以以多种多样形式具体体现，并且在本文中公开的任何具体结构、功能或两者仅仅是代表性的。基于本文的教导，本领域技术人员应该明白的是，本文所公开的一个方面可以独立于任何其它方面实现，并且这些方面中的两个或多个方面可以按照各种方式组合。例如，可以使用本文所阐述的任何数目的方面，实现装置或实践方法。另外，可以使用其它结构、功能、或除了本文所阐述的一个或多个方面之外或不是本文所阐述的一个或多个方面的结构和功能，实现这种装置或实践这种方法。此外，本文所描述的任何方面可以包括权利要求的至少一个元素。

在对本发明的实施例进行详细描述之前，首先对本发明的发明构思进行简要说明。

在涉及应用层的网络安全设备中，由于在进行深度报文检测时需要处理大量的网络协议和应用，因此在进行深度报文检测时必须采用系统化的鉴别手段。在广义上，签名是用来分析鉴别应用及协议的特征唯一性的手段。当一个新的应用及协议被发明，同样会有相应的签名，这个签名会被识别和添加到签名数据库中。同样，签名也会不断变化，比如BitTorrent/eMule/Skype每升级到一个新的版本，可能就会有新的签名。因此，对签名的研究是需要持续不断的。如果应用在升级，而签名特征库不被更新，则应用及协议的识别会大打折扣。

由于大多数P2P文件共享应用都使用端口跳动技术或者盗用一些常用的协议端口进行传输，所以通过端口对它们进行识别显然是远远不够的。因此，所有的数据包（报文）都必须在应用层面（Application Layer）上进行检查，即对比如TCP协议的传输协议的有效载荷（payload）部分进行检查，以判断它们是否符合代表某些应用代码的样本签名特征。在很多情况下，对于某一种应用的识别需要检测它是否匹配多个代码样本的签名特征。

图4示出了一个微博应用的数据包结构（即，报文结构）。在进行深度报文检测时，首先，通过对报文头部信息的分析，可以确定这是一个目的访问端口为80的TCP，并且通过对HTTP应用签名特征进行判断，可以判定为这是一个Web访问的应用。然后，通过对报文的有效载荷部分进行深入考察，发现该报文具有的第二个代码样本签名特征是weibo.com，由此了解该报文的真实身份。有时候，不同的代码样本签名特征分散在一次协议会话的多个数据包之中。为了能够准确地对应用进行识别，就必须使用精密的第7层协议侦测系统对同一连接中往来的报文进行分析，从而实现与应用代码样本匹配。

通常对于应用结果采用点分式结构进行描述，以图4为例，最终的识别结果是：IP.TCP.HTTP.HTTP-GET.Weibo。从这个结果可以看出，一个应用的识别结果，必须是通过一系列协议和应用的分析才能得到。通常，将IP、TCP、HTTP等称作承载协议，而将微博称作最终应用。

从上面的分析过程可以看到，DPI的分析过程实质就是一系列模式匹配综合的结果。此外，每种网络协议和应用的签名特征通常采用一种形式化语言的方法来描述。在网络和应用规模较少的情况，通过形式化语言分析之后的结果，可以采用一个完整的状态机来描述。然后，让网络中的多个报文遍历整个状态机进行一系列模式的匹配，以证明该数据流是否包含协议和应用签名。但是，随着网络协议和应用的大量加入，以及网络流量的摩尔定律式的增长，原有的分析方式存在功能和性能的瓶颈。通过对形式化语言的综合分析，发现大多数的网络协议和应用都存在汇集效应，通常都会汇集在几个点。图5示出了通常网络协议和应用构建成的规则树。

网络的大多数协议和应用都可以通过回溯遍历，挂接在这棵树的枝干或是叶子上。规则树的枝干通常被称作承载协议，比如说典型的应用承载协议HTTP，并且大多数的应用都位于规则树的叶子上。基于上述规则树，可以将整个引擎分成多个子引擎，从而可以缩减引擎的规模来提高效率。

通过对DPI机制进行分析，可以发现虽然将DPI整体逻辑在硬件快速通路中实现几乎是不可能的，但是如果将DPI逻辑分解，将满足流量消减原则和计算分解量化原则的一部分逻辑放到硬件中实现，是可以有效减少软件平台中的计算负载以及异构平台之间的数据流量。

这里，流量消减原则是指将上传到CPU的慢速通路流量有效消减，而又不影响DPI识别的结果。利用该流量消减原则可以非常有效的降低CPU的处理压力。

计算分解量化原则是指如果关键计算是可分解成多个步骤的，每个步骤没有严格的依赖关系，并且每个步骤的计算密度是可度量的，那么可以根据硬件能提供的计算能力和空间，挑选合适的部分逻辑放到硬件去实现，最终将硬件计算的结果带回CPU，由CPU综合多个步骤的结果得出结论。利用该计算分解量化原则可以极大地增加了CPU的计算能力。

通过前面的DPI介绍，可以看到最终各种协议和应用的签名都是通过形式化语言，综合为一个个状态机的集合。当需要对报文进行应用的识别时，使得报文的报头和有效载荷部分遍历整个状态机集合。状态机集合具有下述特点：

1.闭包性：将正则表达式分成多个子集分别得到的状态机集合，与整个正则表达式综合得到的状态机集合是等价的，也就是遍历整个状态机集合得到的结果，与依次遍历各子集状态机集合的结果是一样的。

2.正则表达式越多，正则引擎综合得到的状态机的数量会呈几何级的数量增加，这是由于需要综合的状态越多由之带来的中间状态也越多。

上述的得到的分析结果并不是告诉我们，正则集合分得越细越好，因为如果分得过细也会导致流程处理时频繁的系统调用，不利于CPU的处理优化。只有合理的分割布局，才能保证适当状态机的规模和处理上的高效。

通过分析发现，状态机的上述特点符合上面描述的两个原则。状态机的闭包性能够很好地满足计算的分解量化。通过之前对规则树的分析可以看出，大多数的应用都是通过少数的协议来承载的，我们将这样的协议称之为承载协议。这些承载协议是可以通过一个小的正则表达式集合来描述的，而且基于承载协议很容易将规则分解成几个子集，这样我们就可以将整体的正则规则集，分解为有优先层次关系诸多集合。这样的分割策略，使承载协议识别正好处于关键位置，由此可以考虑将之硬件化。由于承载协议的种类不多，识别结果的传输代价也就是能够承受的。而且，如果承载协议在快速通路就可以识别，势必可以据此依据用户的规则定义，将不需要分析的承载协议报文消减。

此外，大多数应用特征签名中都含有固定特征，比如上例中的“weibo.com”，如果提取每个应用签名中的这种固定字符串特征，就可以形成多模集合中的多模特征。由于存在多个签名对应相同固定特征的可能性，因此通过对多模的匹配，可以得到包含这种特征的可能的应用的集合，这个集合就非常小了，综合3000多种应用的结果发现，同一特征最后对应的应用不超过8个，也就意味着可以结合上述多模特征匹配的结果，有的放矢地进行应用签名的比对来确定最终的结果。

多模匹配的计算代价相对较小，效率较高。这是因为特征的集合通常就是有限的字符集合，它具有如下特点：首先它也是具有闭包特性的，全集的匹配与分割成几个子集的匹配在逻辑上是等价的；其次它不具有状态机的那种膨胀性。

此外，多模匹配的结果代表的是一种可能性，而且这种可能性正好可以与上述承载协议相结合。如果一个承载协议的所有应用都具有上述特征，那么该承载协议的所有应用都可以通过多模匹配方式来判断可能性。

另外，多模匹配运算符合硬件并发流水的设计思想，相对而言适于硬件实现。而对CPU来说，这部分计算又是高密集的，因此相关运算通过硬件的实现，能有效地降低CPU负荷。

通过上述分析发现，通过在FPGA架构下的硬件平台（第一平台）下对所接收的报文进行承载协议识别和多模匹配，可以满足上述流量消减原则和计算分解量化原则，由此减少上传到X86架构下的软件平台（第二平台）中进行处理的报文流量以及第二平台中的计算负担，从而提高网络安全设备的吞吐量并降低延迟。

图6示出了根据本发明的基于异构平台的深度报文检测方法的流程图，所述异构平台包括FPGA架构下的第一平台以及X86架构下的第二平台。

如图6所示，首先，在步骤S610，在第一平台接收到报文并且确定为针对该报文已经建立会话表项后，判断该报文的会话表项中是否包含需要进行深度报文检测的指示信息。所述指示信息通常采用DPI控制标志位来表示。通常，如果该DPI控制标志位被置位为1，则表示需要进行深度报文检测。如果被置位为0，则表示不需要进行深度报文检测。

如果不包含需要进行深度报文检测的指示信息，则进行到步骤S615，在步骤S615，在第一平台中，将报文传送到服务质量（QoS）模块中进行转发预处理。

如果判断为包含需要进行深度报文检测的指示信息，则在步骤S620，在第一平台上，对所接收报文进行协议分析，以确定该报文的承载协议。所述承载协议比如是IP、TCP、HTTP等。如何对报文进行协议分析来确定该报文的承载协议在本领域是公知的，在此不再描述。

在确定出该报文的承载协议后，在步骤S625，基于预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模式特征匹配。所述承载协议-多模匹配映射表表示承载协议与是否需要对该承载协议进行多模匹配之间的映射关系。图7示出了根据本发明的承载协议-多模匹配映射表的一个示例，其中On表示需要进行多模匹配，Off表示不需要进行多模匹配。这里要说明的是，在不同的应用场合下，所述承载协议-多模匹配映射表还可以根据应用场合进行修改。

在确定出不需要对该报文进行多模匹配后，在步骤S650，在第一平台中，基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议，所述预先定义的承载协议库中的每个承载协议是需要继续进行深度报文分析的承载协议。

在识别出所述承载协议属于需要继续进行深度报文分析的承载协议时，在步骤S655，将该报文上传到第二平台，接着，在步骤S660，在第二平台中对该报文进行深度报文检测。

在识别出所述承载协议不属于需要继续进行深度报文分析的承载协议时，流程进行到步骤S615，在所述第一平台中对该报文进行转发预处理。

在确定出需要对该报文进行多模匹配时，在步骤S630，在第一平台上，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配。这里所述多模特征集合，是将每种承载协议所对应签名集合中各签名的多模特征提取，形成的一个单独的特征集合。经过综合后的多模特征集合中的每个多模特征对应于多个应用的签名。这里，所述多模特征是对应用的应用特征签名进行分析后归纳出的特征，并且每个多模特征对应于多个应用。这里，多模特征所对应的多个应用是有限个应用，通常，不多于8个应用。

所述多模匹配可以采用多种形式进行。例如，可以采用本领域公知的AC算法进行多模匹配。当然，也可以采用本领域公知的其它算法来进行多模匹配。

标准AC算法是由Alfred V.Aho和Margaret J.Corasick于1974年提出的一个经典的多模匹配算法。该算法可以保证对于给定的长度为n的文本，和模式集合P{p1,p2,...pm}，在O(n)的时间复杂度内，找到文本中的所有目标模式，而与模式集合的规模m无关。

AC-STD算法由三部分构成，goto表，fail表和output表。该算法实现步骤主要包括：首先，构建goto表。接着，构建fail和output表。然后，构建有限状态机。在构建出有限状态机后，利用该有限状态机进行多模匹配。该算法在本领域是公知的，在此不再展开描述。

在多模匹配不成功时，流程进行到步骤S615，在所述第一平台中对该报文进行转发预处理。

在多模匹配成功（即，多模匹配命中）后，在步骤S640，将该报文和多模匹配结果发送到第二平台。然后，在步骤S645，在第二平台中，基于所接收的报文以及多模匹配结果，对该报文进行深度报文检测。换言之，在第二平台中，在多模匹配结果的基础上，对该报文进行深度报文检测。例如，如果在多模匹配时命中的多模特征是微博应用，该多模特征可以对应于比如搜索微博、新浪微博和腾讯微博的多个应用，则将微博应用的匹配结果发送到第二平台，接着，在第二平台上，在确定为是微博应用的基础上，通过与搜狐微博、新浪微博和腾讯微博等应用的应用签名进行比对，确定该微博应用是搜狐微博、新浪微博还是腾讯微博。换言之，在经过上述多模匹配的报文到达第二平台（软件平台）后，在第二平台中不需要重新遍历整个规则树，只需根据多模匹配的结果，找到对应协议节点，根据多模匹配结果，直接找到叶子应用节点规则进行匹配，从而缩减了大量的计算负载。

此外，在本发明中，所述承载协议和多模特征采用形式化语言描述，并且预先定义的承载协议-多模匹配映射表、承载协议库和多模特征集合在所述第一平台中被实现为状态机或状态机集合。

在本发明的一个示例中，基于预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配可以包括：将所接收的报文遍历基于预定定义的承载协议-多模匹配映射表实现的状态机或状态机集合来进行多模匹配确定。此外，基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议可以包括：将该报文遍历基于预定定义的承载协议库实现的状态机或状态机集合来进行承载协议识别。而且，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配可以包括：将该报文遍历基于预先定义的与应用相关的多模特征集合实现的状态机或状态机集合来进行多模匹配。

此外，在本发明的另一示例中，所述预先定义的承载协议-多模匹配映射表、预先定义的承载协议库和多模特征集合可以根据用户需求进行更新。此外，与应用相关的多模特征集合包括与应用相关的静态特征、动态特征和/或状态特征。

此外，在本发明的另一示例中，预先定义的承载协议库还可以被配置为具有图8中所示的数据结构。如图8所示，在该数据结构中，承载协议库中的每个承载协议具有字段协议名称、上传标志位、多模标志位以及多模特征集合ID。所述协议名称字段表示该承载协议的名称，用于唯一标识该承载协议。在本发明的另一示例中，上述协议名称字段也可以替换为协议ID字段，该协议ID字段表示该承载协议在承载协议库中的ID。上传标志位表示该承载协议是否属于需要进行深度报文检测的承载协议。例如，当上传标志位被置位为1时，表示需要进行深度报文检测。当上传标志位被置位为0时，表示不需要进行深度报文检测。多模标志位表示是否需要进行多模匹配。当多模标志位被置位为1时，表示需要进行多模匹配。当多模标志位被置位为0时，表示不需要进行多模匹配。所述多模特征集合ID表示与该承载协议对应的多模特征集合的ID。该多模特征集合ID字段仅仅在多模标志位表示需要进行多模匹配时才被赋值。在这种情况下，在对根据本发明的基于异构平台的深度报文检测装置进行初始化时，根据预先定义的规则，对承载协议库进行初始化，并且为该数据结构中的每个字段进行赋值。然后，在深度报文检测装置基于该初始化后的承载协议库进行操作。

图9示出了基于异构平台的报文处理方法的一个示例的流程图，在该图中，采用具有上述数据结构的承载协议库进行。

如图9所示，报文通过队列调度上传到会话表匹配模块（即，状态检测模块），先进行会话表项的匹配。如果会话表项已经建立（即，连接信息已经建立），则直接走快速通路。如果会话表项没有建立，则需要经由首包路径，将报文上传到软件。在首包路径中，主要进行安全策略的检测和转发路径的确定，并进行应用识别。如果根据首包信息不能决定应用识别的结果，则需要在会话表项中设置该连接的DPI控制位，从而保证后续报文能够继续进入深度报文检测DPI模块。

在后续报文经过会话表项匹配后，从会话表项中读取DPI控制位，如果该DPI控制位被置位为0，则报文将进入QoS模块进行处理。如果DPI控制位被置位为1，则说明该报文需要进行DPI检测，并且进入到FPGA平台中的协议识别模块。

FPGA平台的协议识别模块主要进行承载协议的匹配，每个报文到达这个协议识别模块后，由该协议识别模块确定该报文的承载协议。然后，根据所确定出的承载协议，从预先定义的承载协议库中找出对应的多模标志位，并根据该多模标志位的赋值，确定针对该承载协议是否需要进行多模匹配（图9中的MP匹配）。例如，如果该多模匹配控制位被置位为1，则需要进行多模匹配。如果该多模匹配控制位被置位为0，则不需要进行多模匹配。

在确定出需要进行多模匹配后，将该报文传送到多模匹配模块中进行处理。

如果确定不需要进行多模匹配，则根据所确定出的承载协议，从预先定义的承载协议库中找出对应的上传标志位，并根据该上传标志位的赋值，判断针对该承载协议是否需要进行深度报文检测（即，图9中的上传匹配）。例如，如果该上传标志位被置位为1，则判断为需要进行深度报文检测，并将该报文上传到第二平台进行处理。否则，判断为不需要进行深度报文检测，然后该报文直接送到QoS模块进行处理。

在多模匹配模块对报文进行处理后，如果处理结果是匹配，则将该报文以及多模匹配结果一起上传到第二平台进行深度报文检测处理。例如，可以将多模式匹配的结果记录到报文的相应结构中，然后将该报文送到第二平台继续处理。在第二平台中，基于该多模匹配结果，将该多模匹配结果对应的多个应用的应用特征与该报文进行比对，从而确定该报文对应的具体应用，由此实现深度报文检测。如果没有匹配，则将该报文送到QoS模块进行转发预处理。

经过上述协议识别和多模匹配的报文到达第二平台后，不需要重新遍历整个规则树，只需根据协议识别和多模匹配的结果，找到对应协议节点，根据多模匹配结果，直接找到叶子应用节点规则进行匹配，从而缩减了大量的计算负载。

如上参照图6到图9描述了根据本发明的基于异构平台的深度报文检测方法的流程图。本发明的上述基于异构平台的深度报文方法，可以采用软件实现，也可以采用硬件实现，或采用软件和硬件组合的方式实现。

图10示出了根据本发明的基于异构平台的深度报文检测装置800的方框示意图,所述异构平台包括FPGA架构下的第一平台以及X86架构下的第二平台。如图10所示，深度报文检测装置800包括承载协议识别单元810、多模匹配确定模块820、多模匹配模块830、发送模块840和深度报文检测模块850。其中，承载协议识别单元810、多模匹配确定模块820、多模匹配模块830和发送模块840位于FPGA架构下的第一平台中，以及深度报文检测模块850位于X86架构下的第二平台中。

承载协议确定单元810用于当在第一平台上判断出第一平台所接收报文的会话表项中包含需要进行深度报文检测的指示信息时，对所接收报文进行协议分析，以确定该报文的承载协议。

多模匹配确定单元820用于基于预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配，所述承载协议-多模匹配映射表表示承载协议与是否需要对该承载协议进行多模匹配之间的映射关系。

多模匹配单元830用于在确定需要对该报文进行多模匹配时，在第一平台上，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配，所述多模特征集合中的每个多模特征是通过对应用的应用签名特征进行分析后归纳出的并且对应于一个应用。

发送单元840用于在多模匹配命中后，将该报文和多模匹配结果发送到第二平台。

深度报文检测单元850用于基于所接收的报文以及多模匹配结果，对该报文进行深度报文检测。例如，在第二平台中，基于该多模匹配结果，将该多模匹配结果对应的多个应用的应用特征与该报文进行比对，从而确定该报文对应的具体应用，由此实现深度报文检测。

在本发明的另一示例中，深度报文检测装置800还可以包括承载协议识别单元（未示出），位于所述第一平台中，用于在确定不需要对该报文进行多模匹配时，基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议，所述预先定义的承载协议库中的每个承载协议是需要继续进行深度报文分析的承载协议。在识别出所述承载协议属于需要继续进行深度报文分析的承载协议时，所述发送单元将该报文发送到第二平台中进行深度报文检测。或者，在识别出所述承载协议不属于需要继续进行深度报文分析的承载协议时，在所述第一平台中对该报文进行转发预处理。

利用上述基于异构平台的深度报文检测方法及装置，可以通过对FPGA架构下的第一平台所接收的报文进行多模匹配（以及承载协议识别），对原本要上传到X86架构下的第二平台进行处理的报文进行分流处理，并且得到基于多模匹配进行的中间分析结果，然后在X86架构下的第二平台中基于多模匹配结果，通过与该多模匹配结果对应的多个应用的应用签名特征进行比对，继续进行深度报文检测，从而减少上传到X86架构下的第二平台中进行处理的报文流量以及第二平台中的计算负担。

尽管前面公开的内容示出了本发明的示例性实施例，但是应当注意，在不背离权利要求限定的本发明的范围的前提下，可以进行多种改变和修改。根据这里描述的发明实施例的方法权利要求的功能、步骤和/或动作不需以任何特定顺序执行。此外，尽管本发明的元素可以以个体形式描述或要求，但是也可以设想多个，除非明确限制为单数。

虽然如上参照图描述了根据本发明的各个实施例进行了描述，但是本领域技术人员应当理解，对上述本发明所提出的各个实施例，还可以在不脱离本发明内容的基础上做出各种改进。因此，本发明的保护范围应当由所附的权利要求书的内容确定。

Claims (9)

1.一种基于异构平台的深度报文检测方法，所述异构平台包括FPGA架构下的第一平台以及X86架构下的第二平台，所述方法包括：

当在第一平台上判断出第一平台所接收报文的对应会话表项中包含需要进行深度报文检测的指示信息时，在第一平台上，对所接收的报文进行协议分析，以确定该报文的承载协议；

基于所确定出的承载协议以及预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配，所述承载协议-多模匹配映射表表示承载协议与是否需要对该承载协议进行多模匹配之间的映射关系；

在确定需要对该报文进行多模匹配时，在第一平台上，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配，所述多模特征集合中的每个多模特征是通过对应用的应用签名特征进行分析后归纳出的并且对应多个应用；以及

在多模匹配命中后，将该报文和多模匹配结果发送到第二平台，并且在第二平台中，基于多模匹配结果，对该报文进行深度报文检测。

2.如权利要求1所述的深度报文检测方法，还包括：

在确定不需要对该报文进行多模匹配时，在第一平台上，基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议，所述预先定义的承载协议库中的每个承载协议是需要继续进行深度报文分析的承载协议；以及

在识别出所述承载协议属于需要继续进行深度报文分析的承载协议时，将该报文发送到第二平台中进行深度报文检测，或者

在识别出所述承载协议不属于需要继续进行深度报文分析的承载协议时，在所述第一平台中对该报文进行转发预处理。

3.如权利要求1所述的深度报文检测方法，其中，所述承载协议和多模特征采用形式化语言描述，并且预先定义的承载协议-多模匹配映射表、承载协议库和多模特征集合在所述第一平台中被实现为状态机或状态机集合。

4.如权利要求3所述的深度报文检测方法，其中，基于预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配包括：

将所接收的报文遍历基于预定定义的承载协议-多模匹配映射表实现的状态机或状态机集合来进行多模匹配确定，以及

基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议包括：

将该报文遍历基于预定定义的承载协议库实现的状态机或状态机集合来进行承载协议识别。

5.如权利要求3所述的深度报文检测方法，其中，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配包括：

将该报文遍历基于预先定义的与应用相关的多模特征集合实现的状态机或状态机集合来进行多模匹配。

6.如权利要求1所述的深度报文检测方法，其中，所述预先定义的承载协议-多模匹配映射表、预先定义的承载协议库和多模特征集合根据用户需求进行更新。

7.如权利要求1所述的深度报文检测方法，其中，与应用相关的多模特征集合包括与应用相关的静态特征、动态特征和/或状态特征。

8.一种基于异构平台的深度报文检测装置，所述异构平台包括FPGA架构下的第一平台以及X86架构下的第二平台，所述深度报文检测装置包括：

承载协议确定单元，位于第一平台中，用于当在第一平台上判断出第一平台所接收报文的会话表项中包含需要进行深度报文检测的指示信息时，对所接收报文进行协议分析，以确定该报文的承载协议；

多模匹配确定单元，位于所述第一平台中，用于基于所确定出的承载协议以及预先定义的承载协议-多模匹配映射表，确定是否需要对该报文进行多模匹配，所述承载协议-多模匹配映射表表示承载协议与是否需要对该承载协议进行多模匹配之间的映射关系；

多模匹配单元，位于所述第一平台中，用于在确定需要对该报文进行多模匹配时，在第一平台上，基于预先定义的与应用相关的多模特征集合，对该报文的有效载荷部分进行多模匹配，所述多模特征集合中的每个多模特征是通过对应用的应用签名特征进行分析后归纳出的并且对应多个应用；

发送单元，位于所述第一平台中，用于在多模匹配命中后，将该报文和多模匹配结果发送到第二平台；以及

深度报文检测单元，位于第二平台中，用于基于多模匹配结果，对该报文进行深度报文检测。

9.如权利要求8所述的深度报文检测装置，还包括：

承载协议识别单元，位于所述第一平台中，用于在确定不需要对该报文进行多模匹配时，基于预先定义的承载协议库，识别所述承载协议是否属于需要继续进行深度报文分析的承载协议，所述预先定义的承载协议库中的每个承载协议是需要继续进行深度报文分析的承载协议，以及

在识别出所述承载协议属于需要继续进行深度报文分析的承载协议时，所述发送单元将该报文发送到第二平台中进行深度报文检测，或者

在识别出所述承载协议不属于需要继续进行深度报文分析的承载协议时，在所述第一平台中对该报文进行转发预处理。

Images