ipset高大上性能果斷将nf-HiPac逼下課

netfilter，sourceforge，github上有一個凄涼的項目，那就是nf-hipac，這個曾經給Linux firewall設計帶來希望的項目早在2005年就停止了更新和維護，而我本人則是在2007年才被曹老師帶上道的...知道hipac則是2012年 的事，曾經在2.6.13上編譯成功，獲得了聲稱的所謂高性能，後來我的工作大部分都在2.6.32上進行，由于2.6.32引入大量2.6.13上沒有 的機制，也由于版本間隔太多，核心API不相容，hipac移植到2.6.32上費了不少勁，消耗了好幾個本來應該幹點别的的夜晚。

       事實上，曾經，我對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架構本身。

       以下是我的性能測試結果，注意這是一個相對值而不是絕對值，因為我是在虛拟機上跑的。是以我就不貼硬體配置了。另外，我用的是UDP，這樣隻能從丢包上看性能了，擺脫了TCP的流量控制算法的不同而帶來的結果不同。

<a href="http://s3.51cto.com/wyfs02/M02/53/76/wKioL1RoLA6Q7fbGAADbuPwrkTY217.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/76/wKioL1RoLETRlZ2MAAHQCQjm5Y8352.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/78/wKiom1RoK-zip0rpAABx2FBEWVE656.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M01/53/76/wKioL1RoLGzCqKExAABobSaPyzA485.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M02/53/76/wKioL1RoLHzTyUg0AACrffkth7A598.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/76/wKioL1RoLI3ARp4iAAHjAK8IdJg524.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M00/53/78/wKiom1RoLDWzh1GNAACDhCJLcC4339.jpg" target="_blank"></a>

<a href="http://s3.51cto.com/wyfs02/M01/53/76/wKioL1RoLLTBWO1mAAINl1dLjXs776.jpg" target="_blank"></a>

這個結果足以讓nf-hipac下課了。另外我覺得，nf-hipac下課也有它自己的原因，它從來沒有做到核心子產品化和使用者程式即編譯即使用，為核心打patch，重新編譯等就會吓退很多有心者。

       最近關于iptables的工作并不在其本身的性能優化，而是代碼感觀上的優化，比如nftables項目等。

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