转载

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 站在巨人肩膀上发扬光大了。提醒一下，这个也仅仅做娱乐只用，如果要实打实的，还是去买设备。

正文到此结束