PF_RING 对网络抓包性能的提升不仅仅是 30% – 40%

pf_ring 由于涉及的东西比较多,最初看的时候可能会云里雾里,不过多看几遍官方文档应该就能大致理解含义了。
安装的步骤可以看这里。 我建议还是自己跑一遍,这样能熟悉每个零部件的作用。要是实在没空,也可以直接用官方提供的 rpm, deb 安装。
这里提示下,除了编译出来的 pf_ring.ko 之外,如果你的 NIC 不支持 PF_RING™-aware driver,那么只能使用 mode 0,如果支持的话,可以使用 mode 1 以及 mode 2,三者在我们的系统上 benchmark 下来差距并不大,不过加载了 pf_ring.ko 跟不加载 pf_ring.ko 的差距那真是天壤之别了。基本目前主流的 Intel、Broadcom 的都支持(igb, ixgbe, e1000e, tg3, bnx2),注意,tg3 目前(10/18/2014)最新的稳定版本 6.0.1 并没有,需要使用 nightly builds 版本,PF_RING_aware/non-ZC-drivers/broadcom/tg3-3.136h,PF_RING_aware/non-ZC-drivers/2.6.x/broadcom/tg3/tg3-3.102 .2.6.x 目录下面的都是已经废弃的版本,就不要使用了。

一般的应用也不大用到 pf_ring,不过如果是一些 IDS、snort 之类的系统,就派上用场了。我们的情况有点特殊,某条产品线由于前端的机器网卡比较弱(BCM5719),再加上发过来的绝大多数都是 75B 以下的小包,导致 rx_discards 以每秒数 k 的恐怖值增加。最初想抓包看看发过来的都是什么样结构的包,结果普通的 tcpdump 就完全没法用了,传统的 BPF(libpcap) 抓包相比简直是弱爆了。下面两张图,一张是通过 ntopng(也是使用的传统的 pcap)分析的包的大小,跟 iptraf 结果一致,一个只抓到了 2% 不到的包:-(


有需求就有动力了,后来研究了下 pf_ring,情况立马变好转了。看看下面两个对比就知道了。

加载了 pf_ring 的:
$ sudo /var/tmp/pfring/PF_RING-6.0.1/userland/tcpdump-4.1.1/tcpdump   -i bond1 -n -c 1000000 -w tmp
tcpdump: listening on bond1, link-type EN10MB (Ethernet), capture size 8192 bytes
1000000 packets captured
1000000 packets received by filter
0 packets dropped by kernel

使用传统 libpcap 抓包的:
$ sudo tcpdump   -i bond1 -n -c 1000000 -w tmp
tcpdump: listening on bond1, link-type EN10MB (Ethernet), capture size 65535 bytes
1000000 packets captured
1722968 packets received by filter
722784 packets dropped by kernel
12139 packets dropped by interface

所以说,pf_ring 对抓包的提升不仅仅是官方宣传的 30%-40% 的提升,更是一种技术对另外一种技术的革新,以及实际生产效率的大幅度提升。
另外,广告下 ntop.org 这个网站,上面有不少有意思的玩意儿,ntop, ntopng,再比如代替 OpenDPI 的 nDPI。我曾经玩过 OpenDPI,没几天官方就不更新了,这东西最重要的是实时的分析目前主流的协议,好在 nDPI 站在巨人肩膀上发扬光大了。提醒一下,这个也仅仅做娱乐只用,如果要实打实的,还是去买设备。