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論壇搞 這個又有點清高，隻能心裡空自歎了。昨天上海嘉定區雨不算大，中雨水準吧，我沒打傘出去搞了一會兒靈感，結果回來跟老婆吵架...唉，如此自己喜歡的好天 氣竟然泡湯了，下午雨勢稍微大了一些，傍晚還可以，哄好了老婆一起去出去吃飯，鬧市區好一個安靜，周末晚飯點好一個不用排隊！我自己淋着大雨出飯店買泡 芙，看見倆老外手裡拿着傘但是沒打開卻淋着雨，瞬間有一種找到組織的感覺，随性就好，幹嘛跟着别人或者大衆的路子走啊。我喜歡下雨天，是以下雨天我不會打 傘，如果有人較真兒說為什麼看見我打傘了，我會告訴他，我喜歡下雨，可我的手機不喜歡....

 本文轉自 dog250 51CTO部落格，原文連結:http://blog.51cto.com/dog250/1673585