ipset高大上性能果断将nf-HiPac逼下课
其实。以前。我对hipac是非常认可。理由之中的一个就是我发现它是“用规则来匹配数据包”的,而不是像iptables那样“用数据包来匹配规则”的。毫无疑问,Cisco和华为等厂商的硬件设备差点儿都是使用这样的方式来匹配ACL的。当我发现Linux上的hipac能够使用软件来实现相似机制时,当然会兴奋一阵子的。另外一个理由则是。我一直都比較认可多个match的并行匹配,这样能够非常好的利用多个CPU核心,如今我觉得我的这第二个理由全然是胡扯!cache missing,DCA,DMA且不多说,光是调度开销就已经抵销掉了并行匹配的优势。假设没有专门的硬件来进行matching offload,就不要在软件层面用CPU去做这样的转瞬即逝的事情,换句话说,那就是match匹配的粒度太小了,大炮不是用来打蚊子的。CPU是流水化作业的。没有规划好流水线的运行流是不适合CPU来运行的。
喜欢hipac就仅仅剩下了第一个理由!
当我试用了ipset之后,发现hipac真的是个鸡肋项目。并且全然违背了UNIX的原则。怎么说呢?要知道假设我须要禁掉10000个IP地址,用iptables的-s。-d的话,就须要10000条规则,来了一个数据包就须要顺序匹配这10000条规则。注意,是一个一个比对。能不能反过来。让这10000个IP自己发现它们是否包括这个数据包的IP地址呢?这就须要将这10000个IP地址作为一个总体来对待。hipac项目实现的要旨就是这样,内部会将这10000个IP地址组织成一个便于高效查找的数据结构,而不是像iptables那样逐条匹配。然而ipset更适合做这件事,并且更符合UNIX的原则。
假设我们用诸如hipac的方案。我会这样加入10000个IP地址规则(我使用了iptables的语法):
hipac -s ip1 -j DROP
...
hipac -s ip10000 -j DROP
写法上和iptables一样,仅仅是内部将这些IP地址组织成了树或者hash表,假设既要匹配源又要匹配目标的话,每条规则仅仅须要略微复杂一点:
hipac -s ip1 or -d ip1 -j DROP
...
hipac -s ip10000 or -d ip10000 -j DROP
显然,一条规则包括了两个匹配,完毕了两件事。假设我用ipset的话。则是全然分开了全部的事情:
ipset create srcset hash:ip
ipset create dstset hash:ip
ipset add srcset ip1
...
ipset add srcset ip10000
ipset add dstset ip1
...
ipset add dstset ip10000
iptables -A FORWARD -m set --match-set srcset src -j DROP
iptables -A FORWARD -m set --match-set dstset dst -j DROP
依旧用的是iptables,最后我贴出性能測试的结果后就会发现,iptables本身并非性能瓶颈。假设说10000条规则确实减少了性能。那么错误在于你加入了10000条规则。全然能够将iptables作为一个机制而不是策略,你须要优化的是match而不是iptables框架本身。
1.裸跑,没有iptables,没有ipset
2.使用ipset,加入超级多的IP地址
3.使用iptables,加入10000条左右iptables
这个结果足以让nf-hipac下课了。
另外我觉得。nf-hipac下课也有它自己的原因。它从来没有做到内核模块化和用户程序即编译即使用,为内核打patch。又一次编译等就会吓退非常多有心者。
近期关于iptables的工作并不在其本身的性能优化。而是代码感观上的优化,比方nftables项目等。