CN101296114A - 基于流的并行模式匹配方法和系统 - Google Patents

Abstract

本发明提供一种基于流的并行模式匹配系统和方法，用于对进入流进行分布检测，该系统包括：模式集分割器，用于预先将用于模式匹配的模式集分割成多个模式子集；多个模式匹配引擎，每个用于对进入流执行模式匹配；以及调度器，用于从全部模式匹配引擎中，选择与分割的模式子集数目相同的模式匹配引擎，并且分别给选择的模式匹配引擎分配模式匹配任务，每个模式匹配任务针对一个模式子集进行流的匹配。通过本发明的系统和方法，能够通过分割规则/模式集来进行分布检测，以实现负载均衡的基于流的并行模式匹配。

Description

基于流的并行模式匹配方法和系统

技术领域

本发明涉及网络入侵的分布检测，具体涉及基于流的并行模式匹配方法和系统。

背景技术

DPI(深度分组检查)，更具体地，这里是用于网络入侵检测的模式匹配(Pattern Matching，PM)，作为用于许多新兴和越来越流行的网络监视和分析应用(如NIDS即Network Intrusion Detection System，网络入侵检测系统)的一种关键方法，被认为在通信(例如I/O)和计算两方面都是强度密集的。通常，DPI应用需要对大模式组匹配大网络通信量，并且需要的性能成正比地相关于正在监视的网络接口的线速度(wire-speed)(由于DPI不仅处理分组头部而且处理有效负载)，这都使得在多个G比特网络线速率下，很难实现针对巨大模式集的DPI。

作为上一代网络处理器的替代者，具有非常高计算能力的多核处理器(CMP/SMP/SMT)系统，是很有前景的处理平台，因为多核处理器系统对于以往的硬件解决方案来说，具有更高的可编程性和可扩展处理/计算能力。然而，用于数据负载均衡的传统并行编程模型可能难于被DPI处理采用。例如，用于基于数据的负载均衡的传统并行编程模型，在采用于NIDS中的PM处理时是低效率的。因为网络传输的数据通常以流(即任意“源-目的”通信对之间的分组流)的形式出现；所以，对于NIDS中的PM，流内的分组数据彼此具有强相关性，并且必须按顺序处理以避免漏检或者错检。一个不幸的事实是：网络流的大小可能分布极其不均衡，并且在某些情况下，一些流甚至可能占据整个线缆带宽(例如，由于存在如VPN隧道，一些流甚至可能占据整个线路带宽)。这些使得极其难于充分利用多核心平台的处理能力并且通过传统负载均衡方法实现有效的基于流的动态负载均衡。如图1所示，其图示了传统的基于分组的并行处理模型，图中与原始的顺序处理相对照。

基于子任务划分的负载均衡模型，即流水线模型，是利用多核处理器系统的一种替代方案。其长处之一是按顺序处理，这确保了分组流内的数据相关性。然而，另一方面，注意到，只有在各子任务/流水线级被均衡划分时，才能充分利用多核处理器的计算资源以实现优化获益。但不幸的是，因为子任务通常被预先分割并分配，流水线模型苦于很难拥有较高的适应能力，难以做到根据DPI的处理代码将任务均匀划分；由于在NIDS的代码路径中存在大块难分割的子任务和复杂分支，在此模型下极其难于(特别是动态地)均衡工作负载，导致也不能获得高资源利用率。

所有这些迹象都表明，需要开发一种用于高性能DPI应用的新的编程模型来实现更为高效的DPI处理引擎。这种编程模型不仅需要具备保留分组流内的数据依赖，而且能够在各并行处理器资源之间，更理想地以动态的方式，对任务负载进行均衡。

发明内容

有鉴于此，本发明的目的是提出一种基于流的并行模式匹配系统和方法，其能够通过分割规则/模式集来进行分布检测，以实现负载均衡的基于流的并行模式匹配。

为了实现本发明的目的，本发明提供一种基于流的并行模式匹配系统，用于对进入流进行分布检测，该系统包括：模式集分割器，用于预先将用于模式匹配的模式集分割成多个模式子集；多个模式匹配引擎，每个用于对进入流执行模式匹配；以及调度器，用于从全部模式匹配引擎中，选择与分割的模式子集数目相同的模式匹配引擎，并且分别给选择的模式匹配引擎分配模式匹配任务，每个模式匹配任务针对一个模式子集进行流的匹配。

本发明的系统还可包括：方式选择器，用于为要检测的特定进入流选择分布检测方式，并且提供给调度器，该分布检测方式由模式集被分割后的模式子集的数目标识。

本发明还提供一种基于流的并行模式匹配方法，用于对进入流进行分布检测，该方法包括：预先将用于模式匹配的模式集分割成多个模式子集；从对进入流执行模式匹配的全部模式匹配引擎中，选择与分割的模式子集数目相同的模式匹配引擎，并且分别给选择的模式匹配引擎分配模式匹配任务，每个模式匹配任务针对一个模式子集进行流的匹配。

本发明的方法还可包括：为要检测的特定进入流选择分布检测方式，该分布检测方式由模式集被分割后的模式子集的数目标识。

本发明还提供一种程序，用于使计算机执行基于流的并行模式匹配方法，用于对进入流进行分布检测，该方法包括：预先将用于模式匹配的模式集分割成多个模式子集；从对进入流执行模式匹配的全部模式匹配引擎中，选择与分割的模式子集数目相同的模式匹配引擎，并且分别给选择的模式匹配引擎分配模式匹配任务，每个模式匹配任务针对一个模式子集进行流的匹配。

本发明还提供一种计算机可读记录介质，其上记录程序，用于使计算机执行基于流的并行模式匹配方法，用于对进入流进行分布检测，该方法包括：预先将用于模式匹配的模式集分割成多个模式子集；从对进入流执行模式匹配的全部模式匹配引擎中，选择与分割的模式子集数目相同的模式匹配引擎，并且分别给选择的模式匹配引擎分配模式匹配任务，每个模式匹配任务针对一个模式子集进行流的匹配。

本发明能够提供如下优点：

1)能够很好地处理大的分组流，使得对于甚至单个巨大流，也能全部利用所有CPU资源，同时维持相应的数据依赖；

2)从每个流的角度来看，本发明能缩短处理延迟；

3)更小的“每单元”存储需要，因为规则集在尺寸上被分割得更小。这对具有很小的高速缓存或本地存储的系统来说是基本的，如IBM CELL处理器或正在研制的Q7/PRISM处理器。

附图说明

图1图示了传统的基于分组的并行处理模型。

图2图示了本发明的规则集分割方法，以进一步将工作负载划分成小的“片”。

图3图示了MWM算法的规则集大小和时间复杂度(按每字节的存储器引用)之间的关系的评估。

图4(a)图示了本发明的动态分布检测(D³)系统的配置示意图；而图4(b)图示了本发明的动态分布检测的处理流。

图5图示了模式集分割器的一种实现的处理流。

图6图示了方式选择器的一种实现。

图7图示了用于4核心/CPU情况的四个运行方式的实例。

图8显示了方式1、m和D(不均衡的流大小)的性能/可扩展性比较。

图9显示了方式1、m和D(均衡的流大小)的性能/可扩展性比较。

图10(a)显示了

负载均衡(通过流)；而图10(b)显示了基于本发明的方案的负载均衡。

具体实施方式

本发明提出一种新颖的负载均衡的分布式DPI引擎(即基于流的模式匹配引擎)，并进一步提出动态负载均衡的分布式DPI引擎。

在发明人进行的研究中注意到：

对于DPI的任务负载，基于流的模式匹配的关键特性之一是：实际上CPU指令处理两种数据：将要被检查的分组流，以及将要针对其进行检测的规则/模式集合。这里的关键在于，当被分割开分别进行处理时，后者(即规则/模式)不具有互相之间的数据依赖，而前者不然。也就是说，如果将一个分组流分割成若干份分别进行处理，这些处理的结果之间是有依赖性的，因此必须按先后顺序来进行；但如果将模式集合分割开来，分别去检测/匹配分组流，这些处理是相互无关且可以并行进行的。这种将模式集分割成多个子集分别去检测分组流的方法被称为分布检测(Distributed Detection(D²))。通过D²在多个计算单元(即CPU)之间均衡任务负载，可以利用某些闲散的CPU资源以缩短处理时间。

而另一方面，应用D²也可能引入额外的开销：虽然可以在多个计算单元之间均衡工作负载，但同时也有可能需要额外的存储器访问或CPU指令；而且在不适当的时机使用D²可能反而损害性能。

基于发明人的这些观察，通过以若干优化的方式将模式/规则集划分，并且根据分组流和整个系统两者的信息，动态选择运行方式(mode)，提出一种新颖的负载均衡方案，称为动态分布检测(Dynamic Distributed Detection(D³))。采用了D³以后，巨量任务负载可被细分，并且能够在各个处理器之间理想地均衡负载/任务，同时维持相应的数据依赖性/相关性，并避免由于开销造成的负面影响。

以下结合附图和具体示例实现对本发明进行详细说明。

1.原始思想：分布检测(D²)

如图1所示，基于分组流分割任务负载是不充分的，这是因为流的大小并不是均匀分布的；流的大小可能差别很大，因而传统负载均衡方法可能不能充分利用并行资源。关键在于，需要探索一种不使用基于流的任务分配方式，而通过其他方式以进一步分割任务负载，特别是大分组流的任务负载。在本发明中，提出了一种基于规则集分割的新颖的方法，称之为分布检测(D²)。

如图1所示，以实心标记的流其流量很高，并且几乎消耗了整个DPI系统的资源。然而，由于流内分组数据的强依赖性必需按顺序处理，通过传统的负载均衡方法难以将以实心标记的流的任务负载分配至多个DPI引擎进行并行处理。

本发明的思想是把焦点从网络分组流转移到规则模式集合(这通常被传统的方法忽略)。要注意，所需的仅仅是保证分组流的所有内容与规则集中的所有模式相比较。图2图示了本发明的规则集分割方法，以进一步将工作负载划分成小的“片”。如图2中所述，除了分割分组流，分割模式集是分割PM的工作负载的另一种有效的方法。

更具体地，在D²方案中，基于某些优化原则(将在下面说明)在多个引擎中分配规则/模式；流量较大的/高载的分组流被复制到多个PM引擎，以分别与各个模式子集进行比较。

例如，如图2中所示，原始的大规则/模式集被分割为三个子集，同时分别被分配给三个不同的PM引擎(也称为子PM引擎)；然后，可以以分布方式同时利用全部三个子PM引擎，检测流量较大的分组流，即以实心标记的流。这样，工作负载得到细分，并且CPU利用率明显提高。由于模式集对于每个子PM引擎减小，因此子PM引擎各自的匹配时间减少。这相当于通过复制流或者共享存储器在三个子引擎之间共享了任务负载，共享存储器的方式对于具有多个CPU并且共享存储器的硬件平台特别有用。即使采用复制流的方式，因为存储对现代的计算机系统没有太大的问题，而且存储成本趋于越来越廉价，所以将存储效率与这里的分布检测性能进行折中也是合理的。因此，能理想地处理较大的流并且很好地利用并行资源。

2.动态D²(D³)思想

另一方面，从发明人的研究发现，很多基于状态机的模式匹配算法，如著名的Aho-Corasick(AC)算法(参见A.V.Aho and M.J.Corasick，“Efficientstring matching：An aid to bibliographic search，”Commun.ACM，vol.18，pp.333-340，1975)，具有几乎与规则集的大小无关的时间复杂度(也就是说，将规则集分割变小对于性能将没有收益)；其他基于哈希的算法，如著名的Wu-Manber(WM)算法(参见S Wu，U Manber.A fast algorithm for multi-patternsearching[R].Technical Report TR-94-17，University of Arizona，1994)、以及修正的Wu-Manber(MWM)算法(参见Martin Roesch.Snort-lightweight intrusiondetection for networks[C].In：Proceedings of the 13th System AdministrationConference，USENIX，1999)，虽然具有规则集大小敏感的复杂度，但是来自缩小规则集大小的性能增益相对较小。

图3图示了MWM算法的规则集大小和时间复杂度(按每字节的存储器引用)之间的关系的评估。如图3所示，横轴表示规则数目，纵轴表示时间复杂度(按每字节的存储器引用)。从图示的关系曲线可见，对于具有大约1000个模式的规则集，减少一半规则可能仅导致10％的性能增益，这表明，将1000的规则集分割成两个500的子集，并且使用两个CPU分别处理，将引入2*90％-100％＝80％的额外CPU指令或存储器延迟(stall)，也就是说，当使用D²方案时将引入不可忽略的开销。因此，应谨慎地使用D²方案以避免消极效果。请注意：MWM算法是用于多模式匹配的著名算法之一，被认为是具有很好的平均性能的一种算法。此外，snort，最著名的基于开源软件的NIDS之一，采用MWM作为其最近版本(v2.4)的缺省算法用于模式匹配。因此，图3中采用MWM作为演示本发明思想的实例是不缺乏一般性/代表性的。

基于上述考虑，本发明进一步提出了动态D²(D³)方案，其中：若干规则集分割方案将被预先运行，以使多种检测方式(将在下面定义)可以在运行时被动态选择；对于每一个进入的将被检测的分组流，系统将根据它的大小以及系统的运行时信息，例如当前CPU利用率等等，为其动态选择合适的运行方式(即分布检测方式)。

一般来说，假设当前CPU利用率足够低，则越大的流会趋于被分配越高的运行方式(序号越高)，使更多的CPU参与对该分组流的分布检测。

3.D³的系统架构

图4(a)图示了本发明的动态分布检测(D³)系统的配置示意图，用于实现负载均衡的基于流的并行模式匹配。如图4(a)中所示，本发明提出的用于动态分布检测的DPI系统主要包括：流缓冲器1、调度器2、方式选择器3、若干模式匹配引擎(PM)8和PM FIFO(先进先出)队列9、以及模式集分割器4。D³的处理流如图4(b)中所示。

原始规则/模式集5：规则，或者模式，是检测病毒、黑客入侵或者其他网络异常行为的依据。通常来说，一个匹配规则/模式包含一些符合网络异常特征的“字符串”，或者一些字符串的逻辑组合；在网络数据流中发现这样的“字符串”模式，就说明出现了异常。规则/模式集是所有模式的集合。通常模式集由国家的信息安全中心发布，也可能由一些从事病毒防治的软件公司/组织发布，也可以由监测系统的使用者，根据具体情况来制定。

模式集分割器4：对于每个支持的方式，例如方式X，模式集分割器根据优化算法(将在下面说明)，将原始规则/模式集5划分成x个子集；换句话说，对于方式I，将会仅有一个子集，对于方式II会有两个子集，...，对于方式N会有N个子集，等等。分割的结果，即所有可能的方式，存储在方式数据库6中。

方式选择器3：首先，术语“运行方式(mode)”被定义为“对于特定流，为以分布方式执行检测，将规则集分割成的划分数目”，即进行分布检测的方式，简称为“方式”。例如，当我们说当前的流将使用方式x来检测，也就是说，分割成x个规则集(即具有x个子集的规则集)将被用于分布检测，并且x个CPU将同时被分配对流执行检测。方式1指的是对规则集不进行分割，针对整个规则集进行检测(模式匹配)。

方式选择器3对于每个流响应以判决：根据流大小和PM的状态(例如，它们的FIFO的长度)，将在哪种方式运行，以针对模式集或子集匹配流，从而执行分布检测。这将在下面进行详细说明。

调度器2：其检查已经完成重建并就绪的分组流；一旦分组流准备就绪，调度器2就发送请求至方式选择器3，“询问”应该为该流采取哪种方式；例如，选取方式n，则调度器将从全部当中选出n个PM(例如，基于它们的FIFO队列长度)，并且为它们分配任务，每个任务都处理针对一个模式子集的流的匹配；分配信息将被放至相应PM的FIFO队列中。

流缓冲器1：它是进入分组流被重建和缓冲的地方。流数据存储在此，直至它们被处理完毕。

PM 8及其FIFO队列9：PM 8是部署匹配操作的关键组件。每个PM 8每次在某种方式下针对规则子集之一匹配所分配的流(例如，某个PM 8在方式2下针对对应的3个模式子集中的第1个子集来匹配当前的分组流，另一个PM 8则针对第2个子集来匹配当前的分组流...)；各匹配任务通过调度器2产生，并且存储在对应于PM 8的FIFO队列9中；注意，FIFO队列9仅存储任务描述符(例如，指向流的指针、指向模式子集的指针、以及运行采用的方式)。进行模式匹配后，将流发送到后处理器7，进行后续处理。

现在，结合图4(a)和图4(b)说明本发明的D³系统的处理流的一个例子。

该处理流在步骤S46开始预处理，由模式集分割器4对原始规则集5进行模式集分割(步骤S47)，产生多个分割的模式子集。实际的检测在步骤S41开始。在步骤S42，进入的网络通信分组在流缓冲器1进行缓冲，形成流。然后，在步骤S43，调度器2请求方式选择器3确定对于该流选择哪种方式进行分布检测；方式选择器3根据系统状态和分组流大小选择针对当前流的运行方式。在步骤S44，调度器2根据系统状态和PM 8的FIFO队列9的长度，选出(例如FIFO队列长度比较短的PM)与分割的模式子集数目相同的PM，将准备好的流复制给选出的PM(如上所述，也可通过具有多个CPU并且共享存储器的硬件平台的存储器共享，实现所述流到各PM的分配/共享)，并且将分割的模式子集一一对应分配给选出的PM。在步骤S45，选出的各PM针对各自所分配的模式子集中的各模式，对所述流进行模式匹配，从而实现并行模式匹配。

如上所述，对于一特定分组流，调度器2与方式选择器3协作确定一特定分布检测方式(即一定数目的模式子集)。对于不同的分组流，可能选择不同的分布检测方式。因此，可以实现相对分组流的动态分布检测，而不必对所有分组流固定采用某一种分布检测方式。

4.模式集分割器(Pattern Set Partitioner，PSP)/分配器的可实用的实现

下面说明PSP的一种可能的实现，其中假设使用MWM算法，但并不局限于此(注意，这种实现是将在后面讨论的实验中使用的一种)。

根据MWM算法，假设模式的数目为N；无字符移动(Bad-Character-Shift(BCS))表项为0的概率为P_BCS＝0，其中BCS＝0表示存在可能匹配的字符而需要查表；所有BCS表项的平均值为EL_BCS，而每个16比特哈希表查找和每个BCS表查找所需时间分别为Δ₁和Δ₂。则在用于每个进入字节的检测上消耗的期望/平均时间C_cost由下式给出：

$C_{\cos t}=P_{\mathrm{BCS}=0}\·\frac{N}{2^{16}}\·{\mathrm{\Δ}}_1+\frac{1}{\mathrm{MAX}(1,{\mathrm{EL}}_{\mathrm{BCS}})}{\mathrm{\Δ}}_2---\left(1\right)$

在发明人提出的原型中，基于上述的消耗(cost)函数，实现了检测消耗增量模式分配方案。对于所有可能的运行方式，都需要执行模式分配，例如，从方式1到方式N。

例如对于方式n(即分割的模式子集数目为n)，

1)将分别为n个模式子集维护n个消耗计数器。每个计数器代表针对相应的模式子集的期望的每字节检测时间。

2)所有的模式通过以下方式相继地分配到n个子集：

a)首先，对于特定的模式，n个测试分配将被部署在所有子集上，以分别得到更新的P_BCS＝0以及EL_BCS值；

b)然后，根据上述的消耗函数(1)，将得到更新的P_BCS＝0、EL_BCS值以及n个测试消耗值。

c)接下来，将分配该模式至引起最低消耗增量的子集。

如图5中所示，其图示了模式集分割器4基于上述式(1)的处理流。

在步骤S51进行初始化，使方式变量nMode从2开始。在步骤S52判断方式nMode是否大于最大方式Max_Mode。如果大于，表示已经处理了所有方式，就在步骤S53结束PSP的处理。否则，进入循环逐一处理每个方式nMode。即，在循环中，在步骤S54对当前方式进行初始化，使nMode个消耗计数器和所有nMode个模式子集归零。在步骤S55判断模式Pattern的序号n是否大于N。如果大于，表示对于该方式完成所有模式的分配，就转向步骤S52，进行下一个方式的处理。否则，进行到步骤S56，当前模式Pattern_n的nMode个测试分配将根据消耗函数被部署在所有nMode个子集上，以分别获得测试消耗计数。然后在步骤S57，比较k(从1到nMode)个模式子集的测试消耗计数增量(CC′_k-CC_k)，将增量最小的模式子集序号设定为m；然后将当前模式Pattern_n分配给序号为m的模式子集S_m；之后更新消耗计数器CC_m。进行步骤S57后返回步骤S55，继续下一个模式的分配。

总之，以贪婪方式逐一分配各模式，目的是最小化k个模式子集的消耗值，从而实现模式集分割。

除了上面提出的PSP方案，其他的PSP方案可包括：

1)按模式数目的模式集分割：根据模式数目，简单尝试分割模式集，旨在使每个模式子集尽可能具有相同数目的模式。例如，假设给定具有N个模式的模式集，对于方式n，使用该方案只需分配N/n个模式给每个子集。该方案易于实现，但可能得不到最优的性能。

2)按模式大小的模式集分割：注意，模式具有不同的长度，因此可能需要不同的存储大小；模式的不同组合还可能导致不同的存储需要。该方案的目的在于使子集的存储需要尽可能小。为实现该目的，可使用与图5中描述的类似方法，并将消耗函数(1)以下式替代：

$C_{\cos t}=\underset{P_i\∈\mathrm{Subset}}{\mathrm{\Σ}}\mathrm{Sizeof}\left(P_i\right)---\left(2\right)$

其中，对一个模式子集subset中的所有模式P_i的模式大小求和(Sizeof())，得到有关该模式子集subset的存储需要的消耗C_cost。

更具体地，需要对所有可能的运行方式执行模式分配，例如从方式1到方式N。例如，对于方式n，

a.将为n个模式子集分别维护n个消耗计数器。每个计数器代表对于相应的模式子集的存储需要；

b.对于特定的模式，它将被分配给具有最小消耗计数的子集；

c.分配之后，相应的子集的消耗计数器将被更新。

利用该方案，将得到存储均衡的模式集分割。但是这种方案可能也实现不了最优的性能。

3)按模式前缀/后缀的模式集分割：例如，给定的模式集为{ab，ac，bd，be，abc，bcd，ccc，xxx，xyy}，基于前缀的分割将具有类似前缀的模式分配给相同的子集，即，原始模式集可被分割成子集：{ab，ac，abc}、{bd，be，bcd}、{ccc}和{xxx，xyy}。基于前缀的分割也易于实现。

5.方式选择器(MS)的实现

图6图示了方式选择器3的一种实现。如图6可见MS如何工作。如图6所示，对于要检测的特定进入流，MS 3将首先检查系统状态，以了解多少CPU可以被利用来执行分布检测(运行时信息)；之后MS根据流大小等信息和运行时信息，查找由操作员/程序员预设的用户约束表，以确定为当前流运行在哪种方式，然后提供给调度器2。预设的用户约束(即选择运行方式的原则)可以包括(以优先级降低顺序)：1)如果整体处理器利用率U_当前＞U_{限 制}，运行在方式1；2)如果流大小S_流＜S_限制，运行在方式1；3)方式＝F(S_流，U_当前)，即运行方式是当前流大小S_流和当前处理器利用率U_当前的函数。实验结果表明，甚至对MS在运行时选择运行方式很简单的算法/规则(即用户约束)，也可获得很好的性能增益，使得很好地利用空闲的处理器资源同时避免由于开销的消极效果。

图7图示了用于4核心/CPU情况的四个运行方式的实例，从而给出了本发明的D³思想的直观图示。图7中的每个核心/CPU形成一个PM引擎或者子PM引擎。图7所示的四种特定情况导致四种不同的系统组织：

1)当不存在消耗超过整体计算能力的25％的分组流时，不需要规则集分割，并且部署四个完整的PM引擎；

2)当存在消耗超过25％但不大于33％的分组流时，部署两个完整的PM引擎(无规则集分割)来处理微小的流，而部署两个子PM引擎，每个包含半个规则集，来处理紧迫的流，注意，紧迫的流被复制成两份；

3)当存在消耗超过33％但不大于50％的分组流时，只部署一个完整的PM引擎来处理微小的流，而部署三个子PM引擎，每个包含三分之一个规则集，来处理紧迫的流，注意，紧迫的流被复制成三份；

4)当存在消耗甚至超过计算能力的50％的分组流时，部署全部四个子PM引擎一起工作，以处理复制了的工作负载，它们的每一个仅包含规则集的四分之一。

6.实验结果

以下的图8和图9提供了本发明可行性的证据/数据结果，其显示了使用来自DEFCON的网络数据踪迹数据(trace file)针对snort规则集(参见Snort-the de Facto Standard for Intrusion Detection/Prevention，从www.snort.org可获得)、在不同PM的设置(使用MWM算法)下的性能。

使用的平台：SunFire 2000T(Niagara)服务器，具有UltraSPARC T1处理器(8核心，每个核心具有4个硬件线程，即，总计32个逻辑CPU)，8GBDDR2存储器，3MB L2高速缓存。

情形I：原始的网络流量数据，100k分组流，最大流大小为1.077MB

图8显示了方式1、m和D(不均衡的流大小)的性能/可扩展性比较。图8中，“方式1”指对所有的分组流，其运行方式ID总等于1，即所有PM总运行在方式1(即不采用对规则进行分割的分布式检测)，并且采用传统的基于流的负载均衡方案；“方式m”指方式ID总等于PM线程的数目，即对所有分组流都使用固定的方式m检测的方案，其中m等于运行的PM线程的数目；“方式D”指检测方式的选择是动态的，即本发明的D³方案，运行方式在运行时动态确定。此外，这里使用的简单用户约束为：U_限制＝70％，S_{限 制}＝32KB，并且F(S_流，U_当前)＝Min{32，(100％-U_当前)Log₂ S_流}

如图8所示，在情形I中，方式D和方式m显然优于方式1。

情形II：修改过的网络流量数据，所有大于64KB的分组流被裁减至64KB，共100k个分组流

图9显示了方式1、m和D(均衡的流大小)的性能/可扩展性比较。其中，“方式1”、“方式m”和“方式D”的含义与图8中的相同，并且使用相同的用户约束。从图9中可见，与图8中的情形不同，方式1显然优于方式m。由于在这种情形中流的大小是均衡的，因此，使用大的方式将很少带来增益；另一方面，开销是显然的，因此导致性能下降。但是对于方式D，根据流大小可以很好地控制方式，因此可见，在情形II中，方式D的性能几乎与方式1的一样好。

7.有关本发明的增益来自何处的演示

图10(a)显示了

负载均衡(通过流)；而图10(b)显示了基于本发明的方案的负载均衡。

图10(a)和图10(b)展示了在双PM系统中的处理(PM)踪迹，其中水平方向表示时间。假设以实心标记的流代表较大/高载的流；在图10(b)中，第一个较大的流被设定为在方式2上运行，以使每一个PM引擎处理子集内的匹配(注意，开销6+6＞10)，并且第二个较大的流也被设定为在方式2上运行(也要注意，开销5+4＞8)，其他的小流全部在方式1下运行。

由此可见，即使在方式2(图10(b)中)上运行也招致处理开销(6+6＞10和5+4＞8)；但是，由于方式2使系统可能更好地利用所有的PM引擎(例如在图10(b)中所示的情形中比图10(a)中的情形观察到更少的空闲时间)，因此，取得了更好的性能，即更少的处理延迟。

本发明可以通过一种基于流的并行模式匹配系统和方法实现，该系统和方法能够通过分割规则/模式集来进行分布检测，以实现负载均衡的基于流的并行模式匹配。本发明还可以通过一种程序或者其上记录程序的计算机可读记录介质实现，所述程序可使计算机执行上述根据本发明的基于流的并行模式匹配方法。

Claims (20)

1.一种基于流的并行模式匹配系统，用于对进入流进行分布检测，该系统包括：

模式集分割器，用于预先将用于模式匹配的模式集分割成多个模式子集；

多个模式匹配引擎，每个用于对进入流执行模式匹配；以及

调度器，用于从全部模式匹配引擎中，选择与分割的模式子集数目相同的模式匹配引擎，并且分别给选择的模式匹配引擎分配模式匹配任务，每个模式匹配任务针对一个模式子集进行流的匹配。

2.根据权利要求1所述的系统，还包括：

方式选择器，用于为要检测的特定进入流选择分布检测方式，并且提供给调度器，该分布检测方式由模式集被分割后的模式子集的数目标识。

3.根据权利要求2所述的系统，其中：

对于要检测的特定进入流，所述方式选择器检查系统状态，以获得运行时信息，包括可以被利用来执行分布检测的CPU的数目；之后根据流信息和运行时信息，查找预设的方式选择原则，以确定对所述流选择的分布检测方式，然后提供给调度器。

4.根据权利要求1或2所述的系统，其中：

调度器基于各模式匹配引擎的先进先出FIFO队列长度，选择要进行分布检测的模式匹配引擎。

5.根据权利要求4所述的系统，其中：

调度器将分配信息放至相应模式匹配引擎的FIFO队列中，FIFO队列仅存储模式匹配任务描述符，包括指向流的指针、指向模式子集的指针、和/或采用的分布检测方式。

6.根据权利要求1或2所述的系统，其中：

所述模式集分割器根据检测消耗增量模式分配方案分割模式集，以贪婪方式逐一将各模式分配给检测消耗值增量最小的模式子集。

7.根据权利要求6所述的系统，其中：

在所述检测消耗增量模式分配方案中，使用下式计算在用于每个进入字节的检测上消耗的期望/平均时间C_cost，作为检测消耗值：

$C_{\cos t}=P_{\mathrm{BCS}=0}\·\frac{N}{2^{16}}\·{\mathrm{\Δ}}_1+\frac{1}{\mathrm{MAX}(1,{\mathrm{EL}}_{\mathrm{BCS}})}{\mathrm{\Δ}}_2$

式中，N为模式的数目，P_BCS＝0为无字符移动BCS表项为0的概率，EL_BCS为所有BCS表项的平均值，而Δ₁和Δ₂分别为每个16比特哈希表查找和每个BCS表查找所需时间。

8.根据权利要求1所述的系统，其中：

所述模式集分割器分割的模式子集数目与全部模式匹配引擎数目相同，而所述调度器选择全部模式匹配引擎，使得对每个进入流，模式匹配引擎与分割的模式子集一一对应。

9.根据权利要求2所述的系统，其中：

所述模式集分割器预先分割的模式子集的所有可能的方式，存储在方式数据库中；而对于要检测的特定进入流，所述方式选择器从方式数据库中选择分布检测方式。

10.根据权利要求3所述的系统，其中所述方式选择原则包括：

选择的方式是所述要检测的流的大小和当前处理器利用率的函数。

11.一种基于流的并行模式匹配方法，用于对进入流进行分布检测，该方法包括：

预先将用于模式匹配的模式集分割成多个模式子集；

从对进入流执行模式匹配的全部模式匹配引擎中，选择与分割的模式子集数目相同的模式匹配引擎，并且分别给选择的模式匹配引擎分配模式匹配任务，每个模式匹配任务针对一个模式子集进行流的匹配。

12.根据权利要求11所述的方法，还包括：

为要检测的特定进入流选择分布检测方式，该分布检测方式由模式集被分割后的模式子集的数目标识。

13.根据权利要求12所述的方法，其中选择分布检测方式包括：

对于要检测的特定进入流，检查系统状态，以获得运行时信息，包括可以被利用来执行分布检测的CPU的数目；之后根据流信息和运行时信息，查找预设的方式选择原则，以确定对所述流选择的分布检测方式。

14.根据权利要求11或12所述的方法，其中：

基于各模式匹配引擎的先进先出FIFO队列长度，选择要进行分布检测的模式匹配引擎。

15.根据权利要求14所述的方法，其中：

将分配信息放至相应模式匹配引擎的FIFO队列中，FIFO队列仅存储模式匹配任务描述符，包括指向流的指针、指向模式子集的指针、和/或采用的分布检测方式。

16.根据权利要求11或12所述的方法，其中预先分割模式集包括：

根据检测消耗增量模式分配方案分割模式集，以贪婪方式逐一将各模式分配给检测消耗值增量最小的模式子集。

17.根据权利要求16所述的方法，其中：

在所述检测消耗增量模式分配方案中，使用下式计算在用于每个进入字节的检测上消耗的期望/平均时间C_cost，作为检测消耗值：

$C_{\cos t}=P_{\mathrm{BCS}=0}\·\frac{N}{2^{16}}\·{\mathrm{\Δ}}_1+\frac{1}{\mathrm{MAX}(1,{\mathrm{EL}}_{\mathrm{BCS}})}{\mathrm{\Δ}}_2$

式中，N为模式的数目，P_BCS＝0为无字符移动BCS表项为0的概率，EL_BCS为所有BCS表项的平均值，而Δ₁和Δ₂分别为每个16比特哈希表查找和每个BCS表查找所需时间。

18.根据权利要求11所述的方法，其中：

预先分割的模式子集数目与全部模式匹配引擎数目相同，并且选择全部模式匹配引擎，使得对每个进入流，模式匹配引擎与分割的模式子集一一对应。

19.根据权利要求12所述的方法，其中：

预先分割的模式子集的所有可能的方式，存储在方式数据库中；而对于要检测的特定进入流，从方式数据库中选择分布检测方式。

20.根据权利要求13所述的方法，其中所述方式选择原则包括：

选择的方式是所述要检测的流的大小和当前处理器利用率的函数。

Images