首先。请求不要再诬陷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论坛搞这个又有点清高，仅仅能心里空自叹了。昨天上海嘉定区雨不算大。中雨水平吧，我没打伞出去搞了一会儿灵感，结果回来跟老婆吵架...唉，如此自己喜欢的好天气居然泡汤了。下午雨势略微大了一些，傍晚还能够，哄好了老婆一起去出去吃饭。闹市区好一个安静。周末晚饭点好一个不用排队。我自己淋着大雨出饭店买泡芙。看见俩老外手里拿着伞可是没打开却淋着雨。瞬间有一种找到组织的感觉，随性就好，干嘛跟着别人或者大众的路子走啊。我喜欢下雨天，所以下雨天我不会打伞，假设有人较真儿说为什么看见我打伞了，我会告诉他。我喜欢下雨。可我的手机不喜欢....