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身上，請明悉。