2. Suricata架构与运行机制
Suricata 与早期单线程 IDS 最大的区别，在于它把一次流量检测拆成了一条可并行、可流水化的处理链。理解这条链，是后续调优线程数、定位丢包、判断规则为何不命中的基础。本节不讨论具体规则语法，而是沿着一个数据包从网卡进入、到告警写出的完整路径，说明各模块的职责边界与协同方式。
一、整体架构：线程 + 队列构成的流水线
Suricata 采用多线程架构，核心思想是“按阶段分工、按队列传递”。一个数据包依次经过捕获、解码、流管理、协议解析、检测、输出几个阶段，每个阶段由一类线程承担，阶段之间通过队列（队列可理解为带缓冲的传递通道）衔接。这样做的直接好处是：捕获线程可以持续从网卡取包，检测线程可以并行处理多个包，二者互不阻塞。
需要区分两类线程模型。运行模式（runmode）决定线程如何组织，常见的有 autofp（自动流负载均衡）和 workers（工作线程模式）。在 workers 模式下，每个工作线程独立完成“捕获→解码→流→解析→检测→输出”的全流程，线程间几乎不共享包数据，缓存局部性好、锁竞争少，适合多队列网卡；在 autofp 模式下，捕获线程只负责收包并按流哈希分发到不同检测线程，适合单队列网卡或需要集中捕获的场景。选择哪种模式，直接影响后续 CPU 亲和性与队列调优策略。
二、数据包捕获：从网卡到内存
捕获模块负责把数据包从内核取到用户态。Suricata 支持多种捕获方式，工程上最常用的是 AF_PACKET 和 PF_RING。AF_PACKET 利用 Linux 原生能力，通过 TPACKET_V3 的环形缓冲区（ring buffer）批量收包，配合多 RX 队列，可以让多个捕获线程各自绑定一个队列，天然并行。PF_RING 则在驱动层提供更高效的零拷贝路径，适合高吞吐场景。
捕获阶段有两个关键参数：ring-size（环形缓冲区大小）和 cluster-type（多队列分发方式）。如果 ring-size 过小，突发流量下内核缓冲区很快写满，就会产生丢包，此时 stats.log 中的 capture.kernel_drops 会持续增长。判断捕获是否健康，最直接的方法就是观察这个计数器：它长期为 0 或偶发极小值，说明捕获能力足够；持续增长则说明需要增大 ring-size、增加 RX 队列或调整 CPU 亲和性。
三、流管理：让分散的包变成会话
网络检测的本质不是看单个包，而是看一段会话。流管理模块用五元组（源 IP、目的 IP、源端口、目的端口、协议）作为键，把属于同一会话的包归入同一个流结构。流结构里保存了会话状态、方向、已解析协议、应用层数据缓冲等信息，供后续协议解析和检测使用。
流是有生命周期的。Suricata 通过超时机制回收长时间无活动的流，例如 TCP 已建立连接默认超时约 300 秒，UDP 约 30 秒（具体值可在 suricata.yaml 的 flow-timeouts 段调整）。如果超时设置过长，流表会膨胀、内存占用升高；设置过短，则长连接可能被提前回收，导致跨包匹配失效。流表容量由 flow.memcap 控制，当流数量达到上限时，新流会被拒绝或强制淘汰旧流，这一现象在 stats.log 中体现为 flow.memcap 相关计数上升。
四、协议解析：从字节流到应用语义
解码模块只处理到传输层，协议解析模块则进一步识别应用层协议。它根据端口和内容特征判断这是 HTTP、DNS、TLS 还是其他协议，然后按对应格式解析出字段，例如 HTTP 的方法、URI、Host、User-Agent，DNS 的查询名和记录类型。解析结果以“事务”（transaction）为单位组织，一个 HTTP 请求加响应构成一个事务。
协议解析是规则关键字能生效的前提。例如规则里写 http.uri，只有当解析器正确识别出 HTTP 并提取了 URI 字段，这个关键字才有值可匹配。如果流量走了非标准端口，解析器可能识别失败，此时需要显式配置端口映射，例如在 app-layer.protocols.http 中把 8080 加入 HTTP 端口列表。解析失败或协议识别错误，往往表现为规则“看起来该命中却没命中”，排查时应先确认协议是否被正确识别。
五、检测引擎：规则如何被高效执行
检测引擎拿到的是“流上下文 + 已解析协议字段”。它不会把每条规则都逐字节比对一遍，而是先做规则分组：按协议、端口、方向等条件把规则分到不同组，再对每个包只加载可能匹配的规则子集。随后使用多模式匹配算法（如 Aho-Corasick）一次性扫描包内容，快速筛出候选规则，再对候选规则逐条做完整条件判定。
这个“先粗筛、再精判”的两级结构，是 Suricata 能在线速下运行的关键。规则中的 content 参与多模式匹配，而 pcre、flow、threshold 等条件则在精判阶段执行。因此，规则写得越精确（合理使用 fast_pattern、限定协议和方向），粗筛阶段筛掉的无关包就越多，整体性能越好。反之，大量宽泛的 content 会让候选集膨胀，检测线程 CPU 占用升高。
六、输出模块：告警与日志的落盘
检测命中后，事件被送入输出模块。Suricata 的输出是“多消费者”结构：eve.json 记录结构化事件（告警、HTTP、DNS、TLS、流统计等），fast.log 记录简要告警，pcap 可抓取命中包。多个输出可以同时开启，互不影响。
输出阶段最容易出问题的是磁盘 I/O。如果 eve.json 写入速度跟不上事件产生速度，输出队列会积压，严重时导致丢事件。工程上常见的做法是把日志写到独立磁盘、按大小或时间轮转，并在高负载时关闭不必要的输出类型。判断输出是否健康，可以观察 stats.log 中输出队列的长度，以及日志文件是否出现时间戳跳跃或断档。
把这条流水线串起来看：捕获决定“能不能看到包”，流管理决定“能不能看到会话”，协议解析决定“能不能看到语义”，检测引擎决定“能不能匹配规则”，输出决定“能不能留下证据”。任何一环出问题，最终都会表现为检测结果异常。理解各模块的输入输出与协同边界，后续做性能调优和故障定位时，就能快速把问题收敛到具体阶段。