在单台服务器上实现100Gbps入侵防御

Papers-We-Love将在本周三(18日)举办一个小型活动，我将在会上主持一个小组讨论，其中包括今天报纸选择的作者之一：贾斯汀·雪莉(Justine Sherry)。如果可以的话，请一定要加入我们。

我们总是想要更多！这源于杰文悖论和系统的互联性的结合--在一个领域做得更多，往往也会导致对其他领域做更多事情的需求。归根结底，我们可以通过三种基本方式来提高运力：

提高我们在一组单元之间协调工作的效率(参见通用可伸缩性法则)。

选项1和2当然是“横向扩展”选项，而选项3是“向上扩展”。随着更多的节点和更多的协调，设计和操作都变得更加复杂。因此，虽然在云时代，向外扩展受到了大部分关注，但定期提醒自己，我们在一个盒子甚至一个线程上真正能做些什么是很好的。

今天的论文选择是在一台服务器上推动最先进技术的一个很好的例子。我们用加速器包围CPU已经有很长时间了，但Pigasus设计的核心是一个非常有趣的控制反转-CPU不是协调和呼唤加速器，而是由FGPA负责，CPU扮演支持角色。

Pigasus是一种入侵检测/防御系统(IDS/IPS)。IDS/IPS监控网络流量，并将传入的数据包(或者更严格地说，协议数据单元，PDU)与一组规则进行匹配。可能有数以万计的这样的规则，它们被称为签名。签名又由一个或多个模式组成，这些模式与报头或数据包内容匹配，包括精确的字符串匹配和正则表达式。模式可以跨越多个分组。因此，在匹配之前，面对数据包碎片、丢失和无序传输，IDS/IPS必须重建TCP字节流-这一过程称为重组。

当在预防模式(IPS)下使用时，所有这些都必须发生在传入流量上，以阻止任何带有可疑签名的流量。这使得整个系统对延迟非常敏感。

IDS/IPS文献中反复出现的一个主题是它们需要处理的工作负载与现有硬件/软件实现的能力之间的差距。今天，我们面临着构建支持100Gbps数量级线速、数十万并发流并能够根据数万条规则匹配数据包的IDS/IPS的需求。

这篇文章的乐趣之一是，你不仅可以看到最终的设计，还可以洞察导致它的力量和权衡。你真的可以在一台服务器上完成所有这些任务吗？

在IDS/IPS处理中集成FPGA的传统方法是让CPU负责，并将特定任务(如正则表达式解析)卸载到FPGA。比较的基准是Snort 3.0，根据Snort网站的说法，它是“世界上最强大的IPS”。特别是，Pigasus被设计为与Snort规则集兼容，并使用Snort注册规则集(大约10K签名)进行评估。Snort中CPU时间的最大部分花在多字符串模式匹配器(MSPM)模块上，该模块用于标题和部分字符串匹配。

利用Amdahl定律，我们可以看到，即使将MSPM卸载到一个假想的、无限快的加速器上，吞吐量也只会增加85%，达到600 Mbps/核，仍然需要166个核才能达到100Gpbs。

事实上，无论您尝试将Snort模块卸载到假设的无限快加速器上，都无法接近Pigasus的性能目标。这修正了Pigasus的第一个设计决策：FPGA需要作为主要的计算平台负责，而CPU将是次要的。(之所以选择现场可编程门阵列，是因为它们既节能又可在SmartNIC上使用)。

在确定了FPGA优先设计之后，这意味着需要在FPGA上执行匹配和重组的状态数据包处理。而这反过来又意味着主要的设计约束是可用的FPGA存储器的大小，尤其是块RAM(BRAM)。Pigasus的目标FPGA有16MB的BRAM。

这里需要关注的是完全匹配器执行的正则表达式匹配。正则表达式匹配得到了很好的研究，但是最先进的硬件算法没有达到Pigasus所需的性能和内存目标。在FPGA上执行RE匹配会消耗大量内存，并且只会带来微乎其微的整体性能提升，因为大多数数据包都不会触及完全匹配器。这给我们带来了另一个重要的设计决策：正则表达式匹配将从FPGA转移到CPU。

综合我们到目前为止学到的所有知识，Pigasus的整体架构如下所示：

重组器负责对TCP数据包进行排序。它需要在保持100K流量状态的同时以线速完成此操作。

多字符串模式匹配器(MSPM)对所有10,000条规则进行标题匹配，并进行精确的字符串匹配筛选，以确定哪些规则可能匹配。

如果MSPM指示可能的匹配，则包和规则ID被发送到DMA引擎，该场计算出CPU以进行完全匹配。

Full Matcher在CPU上运行，轮询由DMA引擎填充的环形缓冲区。

为了节省宝贵的BRAM用于性能最敏感的任务(重组和MSPM)，数据包缓冲器和DMA引擎使用功能较弱的FPGA上可用的ESRAM和DRAM。

重新组装器和MSPM模块都需要精心设计，以满足其性能和内存目标。

我们重新组装的关键目标是在FPGA的内存限制内，以100Gbps的速度对100K的流执行这种重新排序。

FPGA硬件确实希望使用固定大小的数据结构在高度并行模式下运行。在我们考虑无序分组到达之前，这种方法工作得很好。不过，为了容纳无序的数据包，内存密集型结构(如链表)效果更好。

解决方案是使用固定大小的缓冲区和恒定的时间操作将重组流水线划分为处理有序流的快速路径和处理剩余无序流的慢速路径。快速路径上的恒定时间操作保证了每秒2500万个数据包的处理速率，足以达到500B+数据包数的100Gbps目标。慢速路径不能利用恒定的时间操作，但幸运的是，由于大多数数据包按顺序到达，因此较少使用慢速路径。在插入新流时也会使用它。

使用FlowBlaze基于布谷鸟散列的哈希表设计，快速路径、新的流插入和无序处理都可以在共享流状态上同步。

据我们所知，目前还没有其他硬件或软件项目报告100Gpbs的数万个字符串的多字符串匹配。

Snort 3.0使用英特尔针对MSPM的Hyperscan库。Hyperscan字符串匹配库是可并行的，与基于软件状态机的字符串匹配器相比，它提供了8倍的加速。但简单地转换到FPGA会耗尽内存预算，需要大约25MB的BRAM。

通过精心安排工作，皮加索斯成功地将所有东西都装进了2MB的布拉姆(Bram)中。这意味着它甚至有能力在MSPM阶段做比Snort本身更多的工作，从而减少了需要传递给完全匹配器的数据包数量。

最后，数据包必须与签名中的所有模式匹配才能触发规则。Pigasus的关键洞察力是，一些测试在时间和内存方面可以非常便宜地完成，而另一些测试则需要更多的内存。再加上大多数信息包和大多数索引根本不符合任何规则的认识，一个计划就出现了：建立一个逐渐缩小的过滤管道。在流水线开始时，我们可以并行运行大量内存廉价的过滤器。只有一小部分传入数据包可以通过这些过滤器，因此我们不需要在它们后面并行运行更多内存密集型过滤器来达到所需的线速。

首先应用这个过滤器允许我们使用更少的后续数据结构的副本(更大、更昂贵)，因为大多数字节流索引已经被字符串匹配器过滤掉了。这实现了高(有效)并行性和较低的内存开销。

这种策略非常有效，Snort在任何过滤器匹配的情况下都会将数据包传递给完全匹配器，而Pigasus能够测试所有字符串匹配，并进一步将流向CPU进行完全匹配的数据包比例降低到只有5%。此测试使用类似Bloom Filter的表示法并行执行，有关详细信息，请参阅白皮书中的§5.2。

我们对各种轨迹进行的实验表明，Pigasus平均使用5个内核和1个FPGA就可以支持100Gbps，功耗比仅使用CPU的方法低38倍。

这篇论文的第六节有一个完整的评估，我没有篇幅在这里讨论。标题是Pigasus达到了它的设计目标，使用的内核比Snort少23-200个，耗电量少18-62倍！

皮加索斯的设计是一个奇特的证据，证明了一个看似遥不可及的目标(…)。在一台服务器上运行，这完全在我们掌握的…范围内。鉴于FPGA和SmartNIC的未来硬件路线图，我们相信我们的洞察力和成功经验可以更广泛地指导超越IDS/IPS的网络内加速。