7.1. Runmodes
Suricata由多個稱為線程，線程模塊和隊列的“構建塊”組成。 線程就像一個在計算機上運行的進程。 Suricata是多線程的，所以多個線程一次處于活動狀態(tài)。
線程模塊是功能的一部分。 一個模塊用于解碼數(shù)據(jù)包，另一個模塊是檢測模塊，另一個模塊是輸出模塊。 一個數(shù)據(jù)包可以被多個線程處理。 數(shù)據(jù)包將通過隊列傳遞到下一個線程。 數(shù)據(jù)包一次只能由一個線程處理，但是引擎一次可以處理多個數(shù)據(jù)包。 （請參閱Max-pending-packets）一個線程可以有一個或多個線程模塊。 如果他們有更多的模塊，他們只能一次活動。 線程，模塊和隊列排列在一起的方式稱為Runmode。
7.1.1不同的Runmodes
您可以從幾個預定義的運行模式中選擇一個運行模式。 命令行選項-list-runmodes顯示所有可用的運行模式。 所有運行模式都有一個名稱：auto，single，autofp。 最重要的任務是檢測; 一個數(shù)據(jù)包將被檢查數(shù)千個簽名。
默認運行模式的示例：
在pfring模式下，每個流程在運行模式中遵循其自己的固定路線。
有關與runmode有關的命令行選項的更多信息，請參閱命令行選項。
7.2 抓包
7.2.1負載均衡
為了獲得最佳表現(xiàn)，Suricata將需要以“worker”模式運行。這實際上意味著有多個線程，每個線程運行一個完整的數(shù)據(jù)包管道，每個線程都從捕獲方法接收數(shù)據(jù)包。這意味著我們依靠捕獲方法來將數(shù)據(jù)包分發(fā)到各個線程上。其中一個關鍵的方面就是Suricata需要以正確的順序在同一個線程中獲取流程的兩個方面。
AF_PACKET和PF_RING捕獲方法都有選擇“集群類型”的選項。這些默認為'cluster_flow'，它指示捕獲方法按流（5元組）進行散列。這個散列是對稱的。
Netmap沒有內(nèi)置的cluster_flow模式?？梢允褂谩發(fā)b”工具單獨添加：https：//github.com/luigirizzo/netmap/tree/master/apps/lb
警告最近的AF_PACKET變化已經(jīng)“broken”：https：//redmine.openinfosecfoundation.org/issues/1777這種對稱性。目前正在進行“解決這個問題”的工作：https：//redmine.openinfosecfoundation.org/issues/1777#note-7，但現(xiàn)在停留在內(nèi)核<= 4.2或更新到4.4.16+，4.6.5+或4.7+。
在幾乎所有現(xiàn)代NIC的多隊列NIC上，都需要考慮RSS設置。
7.2.2. RSS
接收端縮放(RSS)是網(wǎng)卡使用的一種技術，用于將傳入流量分配到網(wǎng)卡上的各個隊列中。 這是為了提高性能，但重要的是要認識到它是為正常流量設計的，而不是針對IDS數(shù)據(jù)包捕獲的情況。 RSS使用哈希算法來將傳入流量分配到各個隊列中。 這個散列通常不是對稱的。 這意味著當接收到一個流的雙方時，每一方都可能以不同的隊列結束。 可悲的是，在部署Suricata時，這是使用跨度端口或水龍頭(Trap)時的常見情況。
這里的問題是，通過使流量的兩端處于不同的隊列中，分組處理的順序變得不可預知。 網(wǎng)卡，驅(qū)動程序，內(nèi)核和Suricata上的時間差異將導致數(shù)據(jù)包進入的順序高于網(wǎng)絡。 這具體是關于兩個交通方向之間的不匹配。 例如，Suricata跟蹤TCP 3次握手。 由于這個時間問題，在客戶端到服務器端已經(jīng)開始發(fā)送數(shù)據(jù)之后，SYN / ACK只能被Suricata接收。 Suricata會將此流量視為無效。
AF_PACKET，PF_RING或NETMAP等支持的捕獲方法都不能解決這個問題。 這將需要緩沖和分組重新排序，這是昂貴的。
要查看配置了多少個隊列：
$ ethtool -l ens2f1
Channel parameters for ens2f1:
Pre-set maximums:
RX: 0
TX: 0
Other: 1
Combined: 64
Current hardware settings:
RX: 0
TX: 0
Other: 1
Combined: 8
有些網(wǎng)卡允許您將其設置為對稱模式。 英特爾X（L）710卡在理論上可以做到這一點，但是驅(qū)動程序還沒有能力做到這一點（工作正在努力解決這個問題）。 另一個解決的方法是設置一個特殊的“隨機密鑰”，使RSS對稱。 見http://www.ndsl.kaist.edu/~kyoungsoo/papers/TR-symRSS.pdf（PDF）。
然而，在大多數(shù)情況下，最佳解決方案是將RSS隊列的數(shù)量減少到1：
例：
Intel X710 with i40e driver:
ethtool -L $DEV combined 1
有些驅(qū)動程序不支持通過ethtool設置隊列的數(shù)量。 在某些情況下，有一個模塊加載時間選項。 閱讀驅(qū)動程序文檔的具體信息。
7.2.3 卸載
網(wǎng)卡，驅(qū)動程序和內(nèi)核本身有各種技術來加速數(shù)據(jù)包的處理。 通常這些都將被禁用。
LRO / GRO導致將各種較小的數(shù)據(jù)包合并為大“超級數(shù)據(jù)包”。 這些將需要被禁用，因為他們打破了dsize關鍵字以及TCP狀態(tài)跟蹤。
可以在AF_PACKET和PF_RING上啟用校驗和卸載，但需要在PCAP，NETMAP等上禁用。
7.2.4 建議
閱讀你的驅(qū)動文檔！ 例如。 對于i40e，RSS隊列的ethtool更改可能會導致內(nèi)核恐慌，如果做錯了。
通用：將RSS隊列設置為1或確保RSS散列是對稱的。 禁用NIC卸載。
AF_PACKET：1個RSS隊列并停留在內(nèi)核<= 4.2或者確保你有> = 4.4.16，> = 4.6.5或> = 4.7。
例外：如果RSS是對稱群集類型，可以使用“cluster_qm”將Suricata綁定到RSS隊列。 禁用除rx / tx csum之外的NIC卸載。
PF_RING：1個RSS隊列并使用群集類型“cluster_flow”。 禁用除rx / tx csum之外的NIC卸載。
NETMAP：1個RSS隊列。 沒有內(nèi)置的基于流量的負載平衡，但'lb'工具可以有幫助。 另一個選擇是使用'autofp'runmode。
例外：如果RSS是對稱的，則負載平衡基于RSS哈希，并且可以使用多個RSS隊列。 禁用所有NIC卸載。
