使用散列进行高效的深度数据包检测答案

【问题标题】：Using hashing for efficient Deep Packet Inspection使用散列进行高效的深度数据包检测
【发布时间】：2017-05-30 15:11:11
【问题描述】：

为了提高深度数据包检测的性能，我们通过对规则执行哈希算法对规则集进行预处理，从而将规则分成更小的子规则块，从而加快检测速度。

对原始 104 的前 17 位进行散列处理。预处理完成后，每当数据包到达时，我们都会对其前 17 位进行散列处理，并根据结果与更小的一组规则进行检查。

(该算法使用了两次，在对前 17 位进行散列后，它对接下来的 16 位进行散列并存储结果，但是对于这个特定问题，我们可以假设我们只对固定数量的位）

该算法确实很有效，但是，我们似乎无法找到一种方法将其应用于带有无关位的条目 - 我们得到了很多。

我们在许多地方搜索了解决方案，并尝试了例如使用无关位复制规则的建议。但是它不起作用，因为它需要大量的内存（对于众多规则中的 17 条中的每一个无关位，都可以选择它是 1 还是零 - 这将需要指数量的空间）。

我们非常感谢任何建议或见解，即使是部分解决方案也会很棒。

注意：预处理时间或额外空间没有限制，只要它不是指数或任何不切实际的。

【问题讨论】：

【解决方案1】：

2¹⁷ 是 131,072：很大，但并不过分。如果您使用了一些间接性（例如，将您的规则存储在一个数组中没有重复，然后构建一个大小为 2¹⁷ 的 indices 表 em> 到该数组中），那么您应该能够在 1 MB 以下完成此操作。

【讨论】：

同意。但是，17 只是每个规则散列的位数。规则的数量约为 500k，在对每条规则的每 17 位进行散列后，我们对每条规则的下 16 位进行相同的操作，这使其成为不切实际的解决方案。 (~500k*2^17+500k*2^16)
@RoaaGharra 你能否为数据的前 17+16 位构建一个哈希表？这需要几千兆字节？
@RoaaGharra：如果我的描述正确，那么我认为问题不是你有多少不同的规则，而是你有多少不同的套规则。然后，您将规则集存储在可以被索引到的自己的数组中。
@ruakh 没错。问题是，有很多规则带有无关位，并且在复制它们之后，同一规则的每个副本可能是几乎所有哈希键的条目。我们有 2^17 个，因此，我们需要 500K*2^17 的内存需求。
@PeterdeRivaz 我可以，但问题在于该表中每一行的条目数。请看我上面的评论。

【解决方案2】：

如果您使用哈希表作为缓存并在未找到当前值的条目时恢复为较慢的值，那么您不需要完全填充它。您可以根据对先前流量的分析提前构建它，创建尽可能多的条目，或者您可以动态填充它，在未找到条目时处理数据包后创建新条目，并删除旧条目一段时间未使用的条目以回收存储。

【讨论】：