Linux软防火墙ACL匹配的优化点

首先，请求不要再诬陷Netfilter！虽然它有一些固有性能损耗，但敬请不要将iptables和Netfilter等同，如果你要抓元凶，请直接说iptables，而不要说成Netfilter！

       iptables真的是弱爆了！它的ipt_do_table竟然是五大元凶之一，如果规则超过了7000，那么它就是之首(其它的元凶是nf_conntrack函数，它们也是Netfilter的HOOK)。iptables低效的原因在于它的ACL规则没有经过预处理，直接使用人类配置的方式和顺序让数据包逐个匹配，就跟在Linux协议栈中路由表没有转换成转发表而直接让数据包执行最长前缀匹配一样！这不是Linux的错，也不是Netfilter的错，而是你的错。你咋就不试着使用或者修改nf-HiPAC呢？

       ACL的元素匹配可以分为“与”和“或“，一般认为，与操作在同一条规则内进行，而或操作则表示不同的规则，比如下面的规则：

iptables -A FORWARD -d $ip1 -p tcp -j DROP
iptables -A FORWARD -d $ip2 -p udp -j DROP

其中，ip1和tcp以及ip2和udp就是与操作，而两条规则则是或操作，如果我们进行分组，就会得出同组要串行，不同组可并行操作的结论。

       如果将两条规则进行预处理，重新颠倒分组，我们能否不按规则而按匹配元素来重新分组呢？这么做是有理由的，因为匹配元素的数量是固定的，而规则数量则是不固定的，我们必须在海量元素之间可以执行快速的查找算法而不是顺序遍历匹配的算法，因此必须不能让海量元素作为同组元素串行。在ACL匹配过程中，遍历和快速查找都是需要的(前面说过的，同组串行-只能遍历，异组并行-可执行任意算法)，但是必须记住的是，不要按照规则将规则分到一个组，而要以匹配元素为分组基准。要知道，人的理解方式和计算机的处理方式是完全不同的，甚至是相反的。

       大多数的防火墙产品(Cisco，华为的暂不说，XXWRT的都有类似的补丁，也许？嗯，好象是真的，虽然我没有亲见，只是猜的...)都对待人工敲进去的ACL规则链都进行了预处理，这其实也是nf-HiPAC的方式，我之前写过几篇相关的文章。而Linux的iptables并没有任何的预处理，这就是它低效的原因，但这种低效不能归结到Linux或者Netfilter身上，请明悉。

       这个周末有点真又十分假！台风盼了又没来，擦过！我早在几天就对台风登陆报太大的希望，虽然气象台一直吵吵嚷嚷...他们这帮人都是根据历史数据进行大数据分析的，根本就不明白西风带，台风，副高，上海的纬度之间的关系，我前几年分析过这个，只是没有发表，气象论坛的帐号丢了，且级别也不高，在IT论坛搞这个又有点清高，只能心里空自叹了。昨天上海嘉定区雨不算大，中雨水平吧，我没打伞出去搞了一会儿灵感，结果回来跟老婆吵架...唉，如此自己喜欢的好天气竟然泡汤了，下午雨势稍微大了一些，傍晚还可以，哄好了老婆一起去出去吃饭，闹市区好一个安静，周末晚饭点好一个不用排队！我自己淋着大雨出饭店买泡芙，看见俩老外手里拿着伞但是没打开却淋着雨，瞬间有一种找到组织的感觉，随性就好，干嘛跟着别人或者大众的路子走啊。我喜欢下雨天，所以下雨天我不会打伞，如果有人较真儿说为什么看见我打伞了，我会告诉他，我喜欢下雨，可我的手机不喜欢....