上面的更多的是放在带宽使用率上，即如何尽可能的打满，但是都遗漏一个重要的细节，那就是 packet/s，这个论坛的作者一语中的:
– how many packets/sec you have. In fact, network throughput mostly depends on packets/sec, not bytes/sec
可能对于大部分的应用来说，根本无需关注每秒钟到达的包的数量甚至大小，但是对于某些应用来说，这些指标是至关重要的。
要对包(大小、数量、时间)方面的指标做 benchmark，iperf, netperf 之类的就没法用了，他们只能测试带宽，经过一天的使用比较发现下面的一些工具能基本满足需求。要快速的上手的话还是需要对 tcp/ip 有比较深入的了解，比如 ip header，tcp header 之类的，再比如最小的 frame 应该是 64B，这也是众多网络设备厂商做包转发测试的基础，不明白的看下面两张(1, 2)图就清楚了。
跟网络厂商一样，我们也重点关注小包(0-75)的性能，至于小包如何定义，没有严格的标注，我上面的 0-75 也仅仅是从 iptraf 拿到的一个范围，最终还是要根据业务来定。
一般而言，frame(fps) 是针对 data-link(Ethernet) 而言，packet(pps) 是针对 IP 层而言，segment 是针对 TCP 层而言。
nping
基本的功能还是不错的，但是发包能力相对弱了些，试了几种方式，比如下面这个根本达不到 500K/s 的要求，实际也就 150K/s 左右，记得加上 -N/-H，这样速度能提高几个数量级别:
# nping –tcp 192.168.50.52 –rate 500000 -c 500000000 -N -H
三个使用方式:
1. cheatsheet
2. ARP 的 MIT 还是很方便的
3. 常用方法
hping3
基本功能跟 nping 类似，tcp, udp, icmp, arp 都可以伪造篡改，但是发包的效率比上面好的多，
我发送 60B 的小包(40B head + 20B data)，–fast/–faster/–flood 三种不同的类型分别能达到 20 rxpck/s, ~130K rxpck/s, 260K rxpck/s，并且在 –flood 状态，tcp, interrupts 基本饱和:
# hping3 -c 100000000 -d 20 -S -p 80 –fast/–faster/–flood 192.168.50.52 –rand-source
使用:
1. cheatsheet
2. dos using hping3 with spoofed ip in kali linux
pktgen
直接 modpore 往 /proc/net/pktgen/ 里面填 tcp/ip 的选项就好了，操作蛮简单的，可以看下面几篇文档:
* 《pktgen linuxfoundation》
* 《pktgen》
* 《How do I stress test my local network using pktgen?》
总的来说，这个工具不管是带宽还是发包速率都不是很好控制，一旦启动就直接打满。
packETH
这是目前用的最满意的一个，分为 gui、cli 两种，cli 的功能不全面，gui 的可以根据带宽、包的大小来做 benchmark。测试服务器通过 X11 forwarding 就可以打开界面了。
关于 GUI 的使用方法，可以看这里:
* http://packeth.sourceforge.net/packeth/GUI_version.html
* http://www.kuncar.net/blog/packeth-tutorial-part-i-the-inetrface-and-the-packet-builder/2013/
* http://www.kuncar.net/blog/packeth-tutorial-part-ii-the-gen-bgen-s-and-pcap-options/2013/
这里我做了一个快速的分别是针对 60B, 150B, 1400B 的包，随机 src MAC、src IP，在尽可能利用带宽的情况下的 benchmark。这个 gist 记录的是 rx_discard 每秒的丢包结果。
用到的工具，观察的现象也很朴素，如下:
while true; do echo “—- $(date +’%H:%M:%S’)” ;R1=$(ethtool -S em1 | grep rx_dis | cut -d”:” -f 2) ;sleep 1;R2=$(ethtool -S em1 | grep rx_dis| cut -d “:” -f 2); R=`expr $R2 – $R1`; echo $R ; done;
上面这个是计算每秒 drop 的数量，下面这些是一些不同层面的监控对比:
* sar -n DEV 1 | grep bond0
* iptraf
* ibmonitor
* mpstat -P ALL 1
简要说下结果。小包对系统资源的消耗是非常明显的，这也是无数的公司都花了大量的时间在提升小包处理的效率上。
对于 60B 的小包，系统只能打到 300M，600Kpps/s，rx_discards/s 非常大。
150B 的包，能打到 700M，600Kpps/s，rx_discard/s 同样严重。
1400B 的包，能打到 1800M(两条千兆 bonding)，pps 下降到了 200K，rx_discard 要好的多。
600B 以上的包的情况大为好转，基本都能打到 1800M，同时 rx_discards 明显小很多。
这里有使用 packETH 做的 40G benchmark。
Ostinato
跟 packETH 类似，对于各种协议的包的组合非常灵活，可以生成很多非标准的包，比如 IP over IP, ARP over TCP 等等，文档写的很清楚，上手很快。比较麻烦的是是需要在被 benchmark 的机器部署同样的包，跟 iometer 有点类似，而 packETH 则是 standalone 的。
再介绍两个工具，一个叫 scapy；一个叫 netsniff-ng(1, 2) ，后者有集大成的架势，这里是他的使用文档，因为太全面了，是一个综合性的工具，反而没有专心把一件事做好的工具更精致。
上面的工具还不够胃口？看这里(1, 2)。依然不满意？直接上专业硬件线速发包工具吧，1G、10G、40G 已经没意思了，直接上 400G 的吧。
转载请注明：爱开源 » 服务器网卡收包性能测试