基于預過濾結構的正則表達式硬件專用匹配引擎

李俊儒，張 偉,2，陳昆明，徐 濤

(1.北京信息科技大學 計算機學院，北京 100101；2.北京信息科技大學 北京材料基因工程高精尖創(chuàng)新中心，北京 100101；3.清華大學 微處理器與片上系統(tǒng)技術研究中心，北京 100084)

0 引言

正則表達式具有靈活強大的表達能力，故在網絡流量檢測或者文本信息匹配等方面成為定義復雜特征的首要選擇形式[1]。在硬件平臺上實現(xiàn)正則表達式匹配加速，其體系結構一般分為兩大類[2]，一類是以硬件邏輯為中心的匹配架構，另一類是以存儲為中心的匹配架構。

Scarpazza等[3]使用IBM的Cell寬帶引擎，在16個并行的匹配流中，對于1 500狀態(tài)數以下的小規(guī)模確定有窮自動機(DFA)，性能達40 Gbit/s。Vasiliadis等[4]提出了第一個基于圖形處理器(GPU)的檢測模型Gnort，并在Snort規(guī)則集上進行1 000條純字符串規(guī)則的測試，吞吐量達2.3 Gbit/s。Cascarano等[5]在GPU平臺上提出基于非確定有窮自動機(NFA)的新型匹配引擎，在Snort534規(guī)則集上吞吐量為1.5 Gbit/s，在L7-filter規(guī)則集上吞吐量峰值為1.0 Gbit/s。張偉等[6]提出多正則表達式匹配硬件結構，設計了硬件四級流水線，并達到1.6～2 Gbit/s的匹配性能。麥濤濤等[7]在中低性能的FPGA(現(xiàn)場可編程門陣列)平臺上實現(xiàn)了一種基于預定義類緊湊型自動機(Pre-Class CFA)的匹配系統(tǒng)，吞吐量為1.3 Gbit/s。高陽陽等[8]采用專用集成電路(ASIC)與FPGA的混合計算框架，同時使用軟硬件協(xié)同的工作模式，匹配速度達280 Gbit/s。李玉璋等[9]在軟硬件協(xié)同工作方式下，在FPGA上實現(xiàn)了50個通用并行匹配核，吞吐量達19.62 Gbps。Becher A等[10]在基于FPGA的Zynq SoC上實現(xiàn)了一個既具有匹配狀態(tài)又具有不確定狀態(tài)的DFA，可實現(xiàn)21.28 Gbit/s的正則表達式計算。

經過對硬件平臺上實現(xiàn)正則表達式匹配加速方案的研究，發(fā)現(xiàn)正則表達式的硬件實現(xiàn)存在如下問題：第一，采用GPU、通用處理器等非專用硬件實現(xiàn)匹配，其系統(tǒng)性能無法和使用FPGA、ASIC這種專用硬件性能相比；第二，在專用硬件上采用電路邏輯描述正則表達式的方式，每次更新規(guī)則需要重新編寫寄存器傳輸級別(RTL)代碼，生成硬件電路，時間成本高，靈活度低，不適合頻繁更新規(guī)則的應用場景。

為了解決上述問題，本文使用FPGA設計專用電路，并使用以存儲為中心的匹配架構，更新規(guī)則庫時只需要通過軟件編譯器重新編譯規(guī)則，并通過PCIE將編譯后的數據寫入FPGA，規(guī)則編譯時間短，理論上可實現(xiàn)各種規(guī)則的匹配，靈活度更高。

經過對提升正則表達式匹配性能方案的研究可知，預過濾是一種常用的提升匹配性能的方式。預過濾是根據規(guī)則中的特有模式串，迅速定位文本中數據的有效位置。如Snort和Suricata均使用AC算法對字符串進行精確檢測[11-13]；SpliteScreen使用FFBF的方式進行過濾，并使用FFBF-VERIFY驗證FFBF結果[14]；Hyperscan使用FDR高效多字符串匹配器，最后驗證結果[11]。

但正則表達式的預過濾需存儲規(guī)則中相關過濾信息，要占用額外存儲空間；過濾后仍需對過濾結果進行驗證，增加了整個預過濾時間。

為了解決上述問題，本文在FPGA平臺上對預過濾結構進行存儲優(yōu)化，并將字符串匹配與自動機匹配結合，組成新型正則表達式匹配引擎，提升正則表達式匹配性能。

1 預過濾設計分析

提取正則表達式中的模式串是預過濾的前提。Intel的Hyperscan就提供了一種圖分解方式，來提取不同表達中的模式串[9]，并針對模式串對文本進行過濾，快速定位文本有效位置。圖分解算法將正則表達式分解成了一系列不相交的字符串和有限自動機(FA)子集，在分解時對正則表達式的NFA狀態(tài)圖進行嚴格的結構分析，并識別出其中的字符串成分，Hyperscan的圖分解算法能夠保證提取出的字符串是正則表達式匹配的前提條件[9]。

對于任意一個正則表達式，都可表示為“字符串1+狀態(tài)機1+字符串2+狀態(tài)機2+……+字符串n+狀態(tài)機n”的基本格式，即：

Regex→STR1+FA1+…+STRn+FAn

(1)

本文將(STR1&…& STRn)==NULL形式的正則表達式，稱為“不帶有字符串”的正則表達式(null_regex，NR)；將能提取出字符串的正則表達式(string_regex，SR)分為兩種，一種是STR1!=NULL，稱為帶有“前綴字符串”的正則表達式(prefix_regex，PR)，另一種是STR1==NULL，稱為帶有“中綴字符串”的正則表達式(infix_regex，IR)。

SR中，采用組(G)來描述不同位置的字符串集合：Gn表示式(1)中STRn位置處字符串集合。各組間存在優(yōu)先級：G1>G2>…>Gn，即對數據進行預過濾時必須滿足Gn中模式串檢測，才能進行Gn+1中模式串檢測，且Gn模式串命中位置應處于Gn+1模式串命中位置之前。

按照上述定義，對Snort-PCREs中563條規(guī)則以及Hyperscan提供的2 483個合成有限復雜度規(guī)則進行測試，字符串組數分布如圖1所示，前中綴字符串分布如圖2所示，在以上測試集中字符串提取率為100%，故正則表達式中字符串的多組分類預過濾是必要的。

圖1 字符串組數分布

圖2 前中綴字符串分布

在PR中，可通過字符串匹配算法迅速定位字符串位置，再啟動資源消耗更大的正則表達式匹配結構；而在IR中，無法定位有效文本位置，最簡單的方式是從文本起始位置開始進行匹配，這種方式在正則表達式匹配結構中的處理時間消耗并未減少，但在一定程度上減少了正則表達式匹配結構啟動次數。

為優(yōu)化IR中匹配模塊工作效率，有研究將中綴之后的文本順序送入正向工作的子狀態(tài)機，中綴之前的文本倒序送入逆向工作的子狀態(tài)機；還有一些過濾方式關注規(guī)則的后綴字符串，通過定位后綴字符串，將文本倒序送入逆向狀態(tài)機中進行匹配。

本文將PR和IR的處理流程統(tǒng)一化，只存儲一套狀態(tài)機轉移信息，但是由于IR只能從文本起始位置開始匹配，這將會損失匹配性能。為提升IR匹配效率，本文引入首個自動機(式(1)中FA1)深度的概念，大幅度提升了IR的匹配性能。

一般來說，預過濾結構要保證結果的準確性，需要存儲字符串精確信息。本文為減少存儲開銷，基于布隆分類器(Bloom filter,BF)實現(xiàn)預過濾結構，只存儲BF中定長向量表，但這種做法會損失預過濾結果的準確性。為了解決這個問題，本文在匹配流程中設計了預過濾容錯機制，保證了整體功能的正確性。

2 預過濾結構設計

2.1 Bloom filter結構原理

BF是一個基于哈希(Hash)函數的字符串匹配算法，采用一個位串表示并支持集合內元素的Hash查找，自1970年BF首次被提出，就被廣泛應用于大數據集的表達和查找[15-16]。

BF的工作原理是定義一個m位的向量M，通過k個Hash函數對模式串集合P內的每個元素進行運算，得到k個值域為[0,m-1]的哈希值，將k個哈希值與M中的對應位置設置為1，若該位置已置1，則不做處理，這樣就完成了對模式串集合P的初始化。查詢時需要將字符串和k個哈希函數進行運算，若k個結果所對應M中的位置均為1，則表明在一定誤判率的情況下，該字符串是屬于模式串集合P的。

BF的優(yōu)點是不需要進行字符串原數據的存儲，只需要存儲Hash值，故存儲空間占用少，且不會出現(xiàn)漏判現(xiàn)象。但使用Hash函數運算將數據進行壓縮存儲，會出現(xiàn)字符串的誤報，對于集合P中的n條字符串，誤報率為

P=(1-e(-kn/m))k

(2)

2.2 k路并行多組向量表

由于正則表達式中提取出的多組模式串只存在邏輯上的先后關系，故本文提出使用多組向量表來存儲Hash結果。多組向量表結構如圖3所示。

圖3 多組向量表結構

每組空間為mbit，模式串組數為g，那么空間占用(MEM)為m×gbit，每組發(fā)生誤判的概率為pg=(1-e-kng/m)k。每組隨機存取存儲器(RAM)讀寫分兩種方式：

1)深度為mbit、寬度為1 bit的RAM，讀寫時只能按照k個對應的地址逐個讀寫。

2)深度為1 bit、寬度為mbit的RAM，查詢時可一次讀取數據進行對比，但寫入時需要讀取RAM內原始數據，用Hash值與RAM內原數據進行按位或后寫入RAM內。

但以上兩種方式均不能做到并行讀寫。為提升初始化與查詢的效率，本文提出k路并行的多組向量表存儲結構，按Hash函數分組，每組對應獨立的存儲空間，實現(xiàn)k個Hash值并行讀寫，結構如圖4所示。

圖4 k路并行多組向量表

將每組空間k等分，等分后每組空間為m′=m/kbit，單個Hash_RAM空間為m′×gbit，每組的誤報率為pg′=(1-e(-ng/m′))k，由于m′=m/k，故pg=pg′，即采用k路并行的多組向量表存儲Hash值誤報率不變。

以<字符串，組號>()的二元組形式對BF進行初始化，根據G選擇Hash_RAM中的地址偏移量，按照每個字符串的k個計算結果，并行對向量表進行操作。這種結構節(jié)省了對Hash值的處理時間，減少了尋址次數。經測試，k路并行多組向量表的初始化以及查詢的性能較多組向量表的方式1)提升了k倍，較方式2)提升了3倍。

2.3 面向不定長模式串的共享內存過濾器組

傳統(tǒng)設計中每個BF只能對單一長度的模式串進行識別，在進行多長度模式串匹配時，一般將不同長度BF組合成過濾器組來實現(xiàn)多種長度的模式串過濾。組內每個過濾器單獨對應一個向量空間，故只能對相應長度的模式串進行過濾。由于正則表達式中模式串提取數量、長度等均不固定，而硬件電路固定后，每組存儲資源是固定的，無法進行動態(tài)分配，當長度單一但數量較多的模式串組出現(xiàn)時，將導致硬件資源利用率下降，且過濾器性能變差。

為了解決上述問題，使得硬件結構能面對不同長度的模式串，本文提出使用共享內存的方式，對不同長度模式串的Hash結果進行存儲。

在共享內存的過濾器組中，不同長度BF的計算結果不再單獨存儲，每個過濾器組對應一個向量表，組內所有長度過濾器均可以對該向量表進行操作，結構如圖5所示。

圖5 共享內存的k路并行向量表

過濾器組使用時，以<字符串，組號，長度>()的三元組形式，操作共享向量表，使得向量表對模式串長度不再敏感。

優(yōu)化后，查詢時可以做到組內不同長度BF并行計算，理論上誤報率為p=(1-e(-n/m))k。

預過濾時，過濾器組每次移動1字節(jié)進行檢測窗口滑動，如圖6所示。通過組內結果位圖，可以準確得到命中字符串長度l，記錄滑動窗口位置，得到字符串的命中位置(position_start,Ps)。命中字符串的結束位置(position_end,Pe)可由計算得到：

圖6 n路過濾器組

Pe=Ps+l-1

(3)

本文設計充分利用FPGA并行的優(yōu)勢，可以實現(xiàn)n路過濾器組并行檢測。

2.4 預過濾結構流水線優(yōu)化設計

BF進行初始化時，共分為3個階段：1)模式串信息獲取階段；2)Hash計算階段；3)寫入階段。3個階段共需3個時鐘周期，即每個模式串寫入均需3個周期，若等一個模式串寫入完成后再執(zhí)行下個模式串的寫入，初始化階段將耗費3n個時鐘周期，其中n為模式串個數。

為提升初始化效率，設計初始化流水線[8]。優(yōu)化后n個模式串的初始化總耗時為n+2個時鐘周期，在模式串個數較多的場景下，初始化性能為非流水線方式的3倍。

BF進行模式串查詢時，共分為4個階段：1)數據處理階段；2)Hash計算階段；3)查詢階段；4)結果計算階段。4個階段通過RTL代碼邏輯優(yōu)化，可實現(xiàn)5個時鐘周期完成一次查詢。設計中BF一次并發(fā)處理的數據規(guī)模為32字節(jié)，在200 MHz時鐘頻率下，過濾器吞吐量可達10.24 Gbit/s。

使用流水線結構進行優(yōu)化，無需等待數據過濾結果，直接進行下一次數據的過濾，命中后，停止流水線?；诹魉€的查詢設計，在200 MHz時鐘頻率下，吞吐量可達51.2 Gbit/s，查詢性能為非流水線設計方式的5倍。

3 匹配引擎工作流程

3.1 帶有“前綴字符串”的正則表達式

面對帶有“前綴字符串”的正則表達式，本文設計的匹配引擎算法流程如下所示。

1)BF向量表清零。

2)初始化BF。

3)進行G1內模式串檢測。若命中，執(zhí)行步驟4)；若過濾至文本結束仍未命中，返回匹配失敗信息，匹配流程結束。

4)記錄命中位置Ps，并計算結束位置Pe。

5)判斷多組模式串是否均已過濾完成。若仍有未匹配的模式串組，且文本未過濾至結束位置，執(zhí)行流程6)；若文本全部過濾，直接返回匹配失敗，匹配流程結束；若所有模式串組均已匹配完成，進入步驟9)。

6)為避免Pe(i)

data=inputdata&mask

(4)

mask={(Pe+1){0}(n-Pe-1){1}}

(5)

7)若再次命中，計算Pe并更新，Ps保持不變。

8)重復步驟5)～7)。

9)根據Ps，計算進入正則表達式匹配引擎的文本位置(position_dfa,Pd)。

Pd=Ps

(6)

10)從Pd開始，以輸入字符char和狀態(tài)轉移表作為驅動條件啟動匹配引擎。

11)正則表達式匹配引擎輸出匹配成功，或出現(xiàn)失配需重啟過濾器。

12)重新啟動過濾器，根據失配位置(position_mis,Pmis)，處理數據算法如下：

data=inputdata&mask

(7)

mask={(Pmis+1){0}(n-Pmis-1){1}}

(8)

13)重復流程，直至匹配成功，或是匹配失敗，并結束匹配流程。

例如正則表達式“Host:w+httpw+”，其類型為prefix_regex，匹配文本為“abcHost:efg123httpabc”。該規(guī)則提取出的模式串組為G1={“Host:”}，G2={“http”}，length(Host:)為5，length(http)為4。BF使用32路并行的過濾器組進行過濾，以G1為模式串過濾，得到并行結構的結果位圖result_bitmap 為0001000…000(32 bit)，對應了并行時數據過濾的32個起始位置，此時Ps=3，表示在第4個字符處命中，根據過濾器組返回的組內位圖match_bitmap為00001，命中字符串長度為5，并得到Pe=Ps+L-1=7，其中L為長度length。在Pe之后開始以G2為模式串過濾，為避免Pe(1)

數據將從字符“e”開始以G2為模式串進行過濾。由于該正則表達式一共提取出兩組模式串，在G2命中后，BF的預過濾工作完成，令Pd=Ps，對于上述數據，數據將從字符“H”處開始進行正則表達式匹配。匹配引擎在接收到字符串“http”之后的字符“a”后，狀態(tài)機跳轉至可接受狀態(tài)，返回匹配成功信息，匹配結束。

3.2 帶有“中綴字符串”的正則表達式

對于帶有“中綴字符串”的正則表達式，匹配流程與prefix_regex區(qū)別在于以下幾點：

1)因規(guī)則在G1內模式串之前仍有FA，為了保證字節(jié)碼匹配引擎功能正常，應將整個文本送入匹配引擎中進行匹配。

Pd=0

(9)

2)匹配引擎出現(xiàn)失配再次進入匹配引擎時，應在上次匹配引擎失配位置處開始匹配。

Pd=Pmis+1

(10)

如規(guī)則“w+Host:w+httpw+”，屬于infix_regex，文本為“abcHost:ef&g123Host:abchttpabc”，過濾完成后，數據將從起始位置開始正則表達式匹配，即Pd=0。在匹配引擎中遇到字符“&”，失配并記錄位置Pmis=10；再次啟動BF，過濾完成后，令Pd=Pmis+1=11，文本從字符“g”處再次匹配。

按照上述方式對infix_regex進行處理，若數據量較大，Pe位置較為靠后，匹配引擎仍要從位置0開始匹配，對于FA來說，若Pe前大部分為無效數據，則匹配效率并未得到提升。

分析上述規(guī)則，F(xiàn)A1為“w+”，其含義是匹配集合{0-9,a-z,A-Z,_}內字符一次或多次，即在字符串“Host:”之前，文本中至少需要包含一個上述集合中的字符。如規(guī)則“W{5}abc”，F(xiàn)A1為“W{5}”,“W”表達的含義是“[^w]”，匹配字符不在集合{0-9,a-z,A-Z,_}中，“{5}”表示循環(huán)5次，即文本若要符合該規(guī)則，在字符串“abc”前至少需要連續(xù)5個字符滿足“W”要求。

本文在設計infix_regex時中引入FA1深度(FA_depth,Fd)的概念，F(xiàn)d用來輔助infix_regex確定進入匹配引擎時的文本位置，以及輔助BF更快速地判斷文本是否符合規(guī)則要求。

引入Fd后，關于infix_regex的匹配流程，需要做出以下修改：

1)BF首次完成G1內模式串檢測后，若Fd>Ps，應處理數據，并再次進行G1內模式串檢測。

2)BF完成預過濾后

Pd=Ps-Fd

(11)

3)匹配引擎失配后，再次啟動BF，完成G1內模式串檢測后，若Fd>Ps-Pmis，同1)。

對于表達式“w+Host:w+httpw+”，其Fd=1。文本不變，BF在G1模式串檢測時Ps=3，符合要求，繼續(xù)進行G2模式串檢測。BF完成過濾首次進入正則表達式匹配引擎時Pd=Ps-Fd=2。匹配引擎失配后Pmis=10，再次啟動BF進行G1模式串檢測，Ps=15，符合Ps-Pmis>Fd要求，繼續(xù)進行G2模式串檢測。BF完成過濾，再次進入匹配引擎時Pd=Ps-Fd=14。

引入Fd后，基于上述例子中的規(guī)則、文本，可節(jié)省10個時鐘周期。經測試，在大數據量的場景下，性能與prefix_regex相當，性能提升2.5倍。

3.3 預過濾結構誤報處理

BF無法避免出現(xiàn)誤報，一般會使用專用驗證結構，將誤報的元素排除。而這種做法需要額外周期進行驗證，且需提供規(guī)則中各模式串組準確信息，占用額外的存儲資源。本文為減少額外存儲開銷，設計了預過濾容錯機制，下面是針對不同誤報場景下容錯機制的設計：

1)G1模式串檢查得到命中位置Ps1，計算得到Pe1，將位置[0,Pe1]內數據清零，若G2命中位置Ps2

2)若匹配引擎失配后，再次啟動BF對G1中模式串進行檢測，出現(xiàn)Ps

3)若Pmis≤Pe，說明BF出現(xiàn)誤報，不響應此時的失配信號，繼續(xù)在匹配引擎中進行匹配，直至Pmis>Pe，可響應失配信號，跳出匹配引擎，啟動BF。

4)若BF完成過濾后，Pe大于eod，直接返回匹配失敗，結束匹配流程。

以上幾種場景，包括了預過濾中可能出現(xiàn)的誤報問題，對應場景下容錯機制的設計，可以保證系統(tǒng)功能的正確性。

4 實驗結果

實驗所用FPGA板卡參數如表1所示。

表1 FPGA板卡參數

在200 MHz時鐘頻率上實現(xiàn)了基于預過濾結構的正則表達式專用匹配引擎。預過濾結構中，使用5路并行的多組向量表來實現(xiàn)，規(guī)則中模式串最大提取組數設定為4組，每組向量表為32 bit，即向量表存儲空間MEM為640 bit，過濾器的誤報率為0.73%，預過濾在32路并行的流水線設計下吞吐量達到51.2 Gbit/s。

基于vivado系統(tǒng)的綜合布線表明單個正則表達式匹配引擎對FPGA片上資源利用率不高。為充分利用FPGA片上資源、更好地提升性能，在200 MHz時鐘頻率上完成了16個基于預過濾匹配引擎的實現(xiàn)，理論性能提升16倍，且多個匹配核對DFA的“狀態(tài)爆炸”問題有一定的緩解作用。16核獨立匹配引擎的顯示查找表(look-up-table,LUT)資源為39%，BRAM(block RAM)資源為35%，這為更多匹配引擎的實現(xiàn)提供了可能。后續(xù)若要提升匹配核數量，瓶頸不在資源上，而是體現(xiàn)在時序上。在現(xiàn)階段的優(yōu)化中，200 MHz時鐘下完成16核結構的實現(xiàn)，可符合加速卡結構時序要求，但增加更多的匹配引擎，帶來的是整體布線上的復雜度增加，信號傳遞上的延遲等，需對關鍵路徑上的時序進行更好的優(yōu)化，這也是未來的優(yōu)化方向之一。

性能從兩個方面進行分析：一個是在軟硬件協(xié)同工作結構下多核匹配性能，體現(xiàn)的是現(xiàn)階段整體匹配性能；另一個是純硬件多核匹配性能，體現(xiàn)的是加速卡的性能極限，在之后軟硬件數據接口優(yōu)化后，性能可提升的最大限度。根據實際需求，測試文本使用多個小數據包進行測試，實驗過程為：

1)對規(guī)則進行編譯，記錄編譯時間Tcom。

2)發(fā)送正則表達式字節(jié)碼到FPGA，記錄字節(jié)碼傳輸時間Tcoe。

3)發(fā)送數據包，記錄數據包傳輸時間tdata。

4)開始進行匹配，記錄匹配時間tmatch。

5)重復3)、4)兩步，直至所有數據包完成匹配。

實驗中，將系統(tǒng)吞吐量C作為考察目標。

(12)

式中：Dsize為單個數據包大小；Tdata為n包數據傳輸總時間，Tmatch為n包數據匹配總時間。

不同系統(tǒng)性能對比如表2所示。從表2可以看出，多核系統(tǒng)性能約為單核系統(tǒng)的4倍，這是上位機性能導致的，實驗所用測試機配置不能支持16核同時調用，4核以下同時調用時，性能幾乎為線性增長。理論上16核性能為單核的16倍，但這個性能也將受限于所用PCIE的總線帶寬。忽略總線帶寬以及測試機性能限制，多核系統(tǒng)的性能理論值為156 Gbit/s。

表2 系統(tǒng)性能對比 (Gbit·s-1)

文獻[10]、文獻[11]均使用基于FPGA的正則表達式匹配算法，本文與文獻中兩種結構的性能對比如表3所示。由表3可知，在單核吞吐量方面，本文結構性能明顯優(yōu)于文獻中兩種結構，但在并行度上有劣勢，且受限于測試機性能，并行度并不能達到理論的16核，只能達到4核性能。

表3 正則表達式匹配硬件結構比較

在硬件邏輯中加入計數器，用來統(tǒng)計硬件匹配開始工作到結束所用周期數，將忽略上位機的處理時間，更加直觀地反應出硬件匹配引擎的性能，純硬件單核以及多核結構的性能對比如表4所示。

表4 純硬件性能統(tǒng)計 (Gbit·s-1)

從一個匹配核到16個匹配核的性能變化如圖7所示。

圖7 多核性能變化

由圖7可知，多個匹配核完全獨立、并行工作，多核結構性能呈線性增長。時鐘頻率在200 MHz下，匹配引擎性能達722.88 Gbit/s。

5 結束語

為了提升正則表達式匹配性能，本文專注于最消耗計算的資源匹配操作，設計了基于預過濾結構的正則表達式硬件專用匹配引擎，在FPGA平臺上對預過濾結構存儲空間進行優(yōu)化，減少占用空間的同時提升并發(fā)度。

實驗表明在單核模式下，本文設計的匹配引擎系統(tǒng)性能為純軟件方案Hyperscan的4.85倍，匹配性能為Hyperscan的22.48倍。與文獻[11]中同類型結構相比，單核性能為其20倍，但本文結構并行度現(xiàn)階段不如文獻[11]中50核結構。與文獻[10]中硬件結構相比，處理單個正則表達式的性能為其9倍左右，但文獻[10]中實現(xiàn)了同時匹配280個正則表達式?，F(xiàn)階段的設計中，在200 MHz的時鐘頻率下實現(xiàn)了16個并行的匹配引擎，后續(xù)可在例化更多匹配引擎以及軟硬件通訊方面做出進一步優(yōu)化。