随着标题的推进，我们希望得到一些关于可用于模式匹配的最快算法的建议：
长词典：256
短但不是固定长度规则（最多1到3或4字节深度）
小（150）个规则（如果是3个字节）或中等（~1K），如果4
比Snort中使用的当前AC-DFA或者Snort再次使用的AC-DFA-Split更好的性能
基于软件（最新的COTS系统，如E5的E3） 理想情况下，我们希望使用一些SIMD / SSE，因为目前它们是128位宽，在不久的将来，它们将是256而不是CPU的64位
我们通过使用Sigmatch纸上显示的算法对Snort AC进行预过滤来开始这个项目，但遗憾的是结果并不令人印象深刻（使用GCC进行编译时效果提高约12％但ICC没有提高）
之后我们尝试利用SSE 4.2中通过IPP库提供的新模式匹配功能，但根本没有性能提升（猜测直接在机器代码中做得更好，但肯定更复杂）
回到最初的想法。现在我们正在沿着Head Body Segmentation AC的路线工作但是我们知道，除非我们更换建议的AC-DFA头部将很难获得改进的性能，但至少能够支持更多的规则而不需要显着的性能下降
我们知道使用位并行思想会为长模式使用大量内存，但问题范围最多只能减少到3或4个字节，从而使它们成为可行的替代方案
我们特别找到了Nedtries，但想知道你们的想法是什么，或者是否有更好的选择
理想情况下，源代码将在C中并在开源许可下使用。
我不知道是否以一种明智的方式或字节方式执行此操作
回到合适的键盘：D
实质上，大多数算法都没有正确地利用当前的硬件功能和限制。它们非常容易缓存，非常分支，并不是说它们不会利用现在存在于COTS CPU中的功能，这些功能允许您具有一定程度的并行（SIMD，SSE，......）
这是我们正在寻求的准确性，一种算法（或已经存在的算法的实现）正确考虑所有这些，其优点是不试图涵盖所有规则长度，只是短的
例如，我已经看到一些关于NFA的论文声称，由于适当的缓存效率，增强的并行性等，他们的性能可能会与DGA配对，而内存需求要少得多。
答案 0 :(得分：2)
请看一下： http://www.slideshare.net/bouma2 支持1和2字节与Baxter上面写的相似。不过，如果你能提供你期望在数据库中的单字节和双字节字符串的数量，以及你期望处理的流量类型（互联网，公司等），它会有所帮助 - 毕竟许多单字节字符串可能最终匹配每个字节。 Bouma2的想法是允许将发生统计数据纳入预处理阶段，从而降低误报率。
答案 1 :(得分：1)
听起来你已经在使用高性能模式匹配了。除非你有一些聪明的新算法，或者可以指出数据或规则中的某些统计偏差，否则很难加速原始算法。
您可以考虑将对字符视为模式匹配元素。这将使状态机的分支因素变得很大，但你可能不关心RAM。这可能会让你买两倍。
当算法运行时，人们经常在汇编程序中使用仔细的手动编码，包括巧妙地使用SSE指令。可能有助于处理发现的唯一序列的技巧是对元素进行一系列比较并通过anding / oring而不是条件分支形成布尔结果，因为分支是昂贵的。 SSE指令在这里可能会有所帮助，尽管它们的对齐要求可能会迫使您复制它们4到8次。
如果您搜索的字符串很长，您可能会分配规则子集以分离CPU（线程）。对规则进行分区可能很棘手。