网络测试工具--Iperf、Netperf 、MZ
网络性能测量的五项指标
可用性（availability）
响应时间（response time）
网络利用率（network utilization）
网络吞吐量（network throughput）
网络带宽容量（network bandwidth capacity）
1． 可用性
测试网络性能的第一步是确定网络是否正常工作，最简单的方法是使用 ping 命令。通过向远端的机器发送 icmp echo request，并等待接收 icmp echo reply 来判断远端的机器是否连通，网络是否正常工作。
Ping 命令有非常丰富的命令选项，比如 -c 可以指定发送 echo request 的个数，-s 可以指定每次发送的 ping 包大小。
网络设备内部一般有多个缓冲池，不同的缓冲池使用不同的缓冲区大小，分别用来处理不同大小的分组（packet）。例如交换机中通常具有三种类型的包缓冲：一类针对小的分组，一类针对中等大小的分组，还有一类针对大的分组。为了测试这样的网络设备，测试工具必须要具有发送不同大小分组的能力。Ping 命令的 -s 就可以使用在这种场合。
2． 响应时间
Ping 命令的 echo request/reply 一次往返所花费时间就是响应时间。有很多因素会影响到响应时间，如网段的负荷，网络主机的负荷，广播风暴，工作不正常的网络设备等等。
在网络工作正常时，记录下正常的响应时间。当用户抱怨网络的反应时间慢时，就可以将现在的响应时间与正常的响应时间对比，如果两者差值的波动很大，就能说明网络设备存在故障。
3． 网络利用率
网络利用率是指网络被使用的时间占总时间（即被使用的时间+空闲的时间）的比例。比如，Ethernet 虽然是共享的，但同时却只能有一个报文在传输。因此在任一时刻，Ethernet 或者是 100% 的利用率，或者是 0% 的利用率。
计算一个网段的网络利用率相对比较容易，但是确定一个网络的利用率就比较复杂。因此，网络测试工具一般使用网络吞吐量和网络带宽容量来确定网络中两个节点之间的性能。
4． 网络吞吐量
网络吞吐量是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。
网络吞吐量可以帮助寻找网络路径中的瓶颈。比如，即使 client 和 server 都被分别连接到各自的 100M Ethernet 上，但是如果这两个 100M 的Ethernet 被 10M 的 Ethernet 连接起来，那么 10M 的 Ethernet 就是网络的瓶颈。
网络吞吐量非常依赖于当前的网络负载情况。因此，为了得到正确的网络吞吐量，最好在不同时间（一天中的不同时刻，或者一周中不同的天）分别进行测试，只有这样才能得到对网络吞吐量的全面认识。
有些网络应用程序在开发过程的测试中能够正常运行，但是到实际的网络环境中却无法正常工作（由于没有足够的网络吞吐量）。这是因为测试只是在空闲的网络环境中，没有考虑到实际的网络环境中还存在着其它的各种网络流量。所以，网络吞吐量定义为剩余带宽是有实际意义的。
5． 网络带宽容量
与网络吞吐量不同，网络带宽容量指的是在网络的两个节点之间的最大可用带宽。这是由组成网络的设备的能力所决定的。
测试网络带宽容量有两个困难之处：在网络存在其它网络流量的时候，如何得知网络的最大可用带宽；在测试过程中，如何对现有的网络流量不造成影响。网络测试工具一般采用 packet pairs 和 packet trains 技术来克服这样的困难。
收集网络性能数据的方式
当确定了网络性能的测试指标以后，就需要使用网络测试工具收集相应的性能数据，分别有三种从网络获取数据的方式：
- 通过snmp协议直接到网络设备中获取，如net-snmp工具
- 侦听相关的网络性能数据，典型的工具是tcpdump
- 自行产生相应的测试数据，即本文中介绍的iperf、netperf、mz工具
Iperf
Iperf 是一个网络性能测试工具。Iperf可以测试最大TCP和UDP带宽性能，具有多种参数和UDP特性，可以根据需要调整，可以报告带宽、延迟抖动和数据包丢失。
0
客户端与服务器共用选项
| 命令行选项 | 描述 |
|---|---|
| -u | –udp：使用UDP方式而不是TCP方式。需要客户端与服务器端同时使用此参数。 |
| -p | –port : 设置端口，与服务器端的监听端口一致。默认是5001端口。 |
| -l | –len : 设置读写缓冲区的长度。TCP方式默认为8KB，UDP方式默认为1470字节。 |
| -w | –window : 设置套接字缓冲区为指定大小。对于TCP方式，此设置为TCP窗口大小。对于UDP方式，此设置为接受UDP数据包的缓冲区大小，限制可以接受数据包的最大值。 |
| -m | –print_mss :输出TCP MSS值（通过TCP_MAXSEG支持）。MSS值一般比MTU值小40字节。通常情况 |
服务器端专用选项
| 命令行选项 | 描述 |
|---|---|
| -s | –server : Iperf服务器模式 |
| -c | –client host : 如果Iperf运行在服务器模式，并且用-c参数指定一个主机，那么Iperf将只接受指定主机的连接。此参数不能工作于UDP模式。 |
| -P | –parallel： 服务器关闭之前保持的连接数。默认是0，这意味着永远接受连接。 |
客户端端专用选项
| 命令行选项 | 描述 |
|---|---|
| -c | –client host ： 运行Iperf的客户端模式，连接到指定的Iperf服务器端。 |
| -b | –bandwidth ：UDP模式使用的带宽，必须配合-u参数，默认值是1 Mbit/sec。 |
| -d | –dualtest ： 运行双测试模式。这将使服务器端反向连接到客户端，使用-L 参数中指定的端口（或默认使用客户端连接到服务器端的端口）。这些在操作的同时就立即完成了。如果你想要一个交互的测试，请尝试-r参数。 |
| -r | –tradeoff ： 往复测试模式。当客户端到服务器端的测试结束时，服务器端通过-l选项指定的端口（或默认为客户端连接到服务器端的端口），反向连接至客户端。当客户端连接终止时，反向连接随即开始。如果需要同时进行双向测试，请尝试-d参数。 |
| -L | –listenport ： 指指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。 |
| -t | –time ： 设置传输的总时间。Iperf在指定的时间内，重复的发送指定长度的数据包。默认是10秒钟。 |
| -P | –parallel： 线程数。指定客户端与服务端之间使用的线程数。默认是1线程。需要客户端与服务器端同时使用此参数。 |
实例
带宽测试通常采用UDP模式，因为能测出极限带宽、时延抖动、丢包率。在进行测试时，首先以链路理论带宽作为数据发送速率进行测试，例如，从客户端到服务器之间的链路的理论带宽为100Mbps，先用-b 100M进行测试，然后根据测试结果（包括实际带宽，时延抖动和丢包率），再以实际带宽作为数据发送速率进行测试，会发现时延抖动和丢包率比第一次好很多，重复测试几次，就能得出稳定的实际带宽。
UDP模式
服务器端：
iperf -u -s
客户端：
/*在udp模式下，以100Mbps为数据发送速率，客户端到服务器192.168.1.1上传带宽测试，测试时间为60秒*/
iperf -u -c 192.168.1.1 -b 100M -t 60
/*客户端以5Mbps为数据发送速率,同时向服务器端发起30个连接线程*/
iperf -u -c 192.168.1.1 -b 5M -P 30 -t 60
/*以100M为数据发送速率，进行上下行带宽测试,-L参数指定本端双测试监听的端口*/
iperf -u -c 192.168.1.1 -b 100M -d -t 60 -L 30000
TCP模式
服务器端：
iperf -s 客户端：
/*在tcp模式下，客户端到服务器192.168.1.1上传带宽测试，测试时间为60秒*/
iperf -c 192.168.1.1 -t 60
/*进行上下行带宽测试*/
iperf -c 192.168.1.1 -d -t 60
/*测试单线程TCP*/
iperf –c 192.168.1.1 –p 12345 –i 1 –t 10 –w 20K
-c：客户端模式，后接服务器ip
-p：后接服务端监听的端口
-i：设置带宽报告的时间间隔，单位为秒
-t：设置测试的时长，单位为秒
-w：设置tcp窗口大小，一般可以不用设置，默认即可
对应服务器端：
iperf –s –p 12345 –i 1 –t 10 –m -y
/*测试多线程TCP: 客户端同时向服务器端发起30个连接线程*/
iperf -c 192.168.1.1 -P 30 -t 60
发包完成后，可以通过ifconfig ethx 和 ethtool -S ethx 查看对应收发包情况，确定发包数、包长、是否丢包等。
Netperf
Netperf是一种网络性能的测量工具，主要针对基于TCP或UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即批量数据传输（bulk data transfer）模式和请求/应答（request/reponse）模式。
| 参数 | 说明 |
|---|---|
| -H host | 指定远端运行netserver的server IP地址 |
| -l testlen | 指定测试的时间长度(秒) |
| -t testname | 指定进行的测试类型(TCP_STREAM，UDP_STREAM，TCP_RR，TCP_CRR，UDP_RR) |
可选参数有如下几个：
| 参数 | 说明 |
|---|---|
| -s size | 设置本地系统的socket发送与接收缓冲大小 |
| -S size | 设置远端系统的socket发送与接收缓冲大小 |
| -m size | 设置本地系统发送测试分组的大小 |
| -M size | 设置远端系统接收测试分组的大小 |
| -D | 对本地与远端系统的socket设置TCP_NODELAY选项 |
| -r req,resp | 设置request和reponse分组的大小 |
实例：
服务器端：
#./netserver
客户端：
1、批量(bulk)网络流量的性能
1） TCP_STREAM
Netperf缺省情况下进行TCP批量传输，即-t TCP_STREAM。测试过程中，netperf向netserver发送批量的TCP数据分组，以确定数据传输过程中的吞吐量：
#./netperf -H 192.168.0.28 -l 60
TCP STREAM TEST to 192.168.0.28
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 16384 60.00 88.00从netperf的结果输出中，我们可以知道以下的一些信息：
1）远端系统（即server）使用大小为87380字节的socket接收缓冲
2）本地系统（即client）使用大小为16384字节的socket发送缓冲
3）向远端系统发送的测试分组大小为16384字节
4）测试经历的时间为60秒
5）吞吐量的测试结果表明，TCP带宽为88Mbits/秒
通过修改可选参数，并观察结果的变化，我们可以确定是什么因素影响了连接的吞吐量。例如，如果怀疑路由器由于缺乏足够的缓冲区空间，使得转发大的分组时存在问题，就可以增加测试分组（-m）的大小，以观察吞吐量的变化：
#./netperf -H 192.168.0.28 -l 60 -- -m 2048
TCP STREAM TEST to 192.168.0.28
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
87380 16384 2048 60.00 87.62在这里，测试分组的大小减少到2048字节，而吞吐量却没有很大的变化（与前面例子中测试分组大小为16K字节相比）。相反，如果吞吐量有了较大的提升，则说明在网络中间的路由器确实存在缓冲区的问题。
2）． UDP_STREAM
UDP_STREAM用来测试进行UDP批量传输时的网络性能。需要特别注意的是，此时测试分组的大小不得大于socket的发送与接收缓冲大小，否则netperf会报出错提示：
#./netperf -t UDP_STREAM -H 192.168.0.28 -l 60
UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28
udp_send: data send error: Message too long为了避免这样的情况，可以通过命令行参数限定测试分组的大小，或者增加socket的发送/接收缓冲大小。UDP_STREAM方式使用与TCP_STREAM方式相同的局部命令行参数，因此，这里可以使用-m来修改测试中使用分组的大小：
#./netperf -t UDP_STREAM -H 192.168.0.28 -- -m 1024
UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
65535 1024 9.99 114127 0 93.55
65535 9.99 114122 93.54 UDP_STREAM方式的结果中有两行测试数据
第一行显示的是本地系统的发送统计，这里的吞吐量表示netperf向本地socket发送分组的能力。但是，我们知道，UDP是不可靠的传输协议，发送出去的分组数量不一定等于接收到的分组数量。
第二行显示的就是远端系统接收的情况，由于client与server直接连接在一起，而且网络中没有其它的流量，所以本地系统发送过去的分组几乎都被远端系统正确的接收了，远端系统的吞吐量也几乎等于本地系统的发送吞吐量。但是，在实际环境中，一般远端系统的socket缓冲大小不同于本地系统的socket缓冲区大小，而且由于UDP协议的不可靠性，远端系统的接收吞吐量要远远小于发送出去的吞吐量。
2、请求/应答(request/response)网络流量的性能
另一类常见的网络流量类型是应用在client/server结构中的request/response模式。在每次交易（transaction）中，client向server发出小的查询分组，server接收到请求，经处理后返回大的结果数据。
1） TCP_RR
TCP_RR方式的测试对象是多次TCP request和response的交易过程，但是它们发生在同一个TCP连接中，这种模式常常出现在数据库应用中。数据库的client程序与server程序建立一个TCP连接以后，就在这个连接中传送数据库的多次交易过程。 用户可以通过-r参数来改变request和response分组的大小，进行更有实际意义的测试：
#./netperf -t TCP_RR -H 192.168.0.28 -- -r 32,1024
TCP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 87380 32 1024 10.00 4945.97
16384 87380从结果中可以看出，增加request/reponse分组的大小，会导致交易率明显的下降。
注：相对于实际的系统，这里交易率的计算没有充分考虑到交易过程中的应用程序处理时延，因此结果往往会高于实际情况
2） TCP_CRR
与TCP_RR不同，TCP_CRR为每次交易建立一个新的TCP连接。最典型的应用就是HTTP，每次HTTP交易是在一条单独的TCP连接中进行的。因此，由于需要不停地建立新的TCP连接，并且在交易结束后拆除TCP连接，交易率一定会受到很大的影响。
#./netperf -t TCP_CRR -H 192.168.0.28
TCP Connect/Request/Response TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
131070 131070 1 1 9.99 2662.20
16384 87380即使是使用一个字节的request/response分组，交易率也明显的降低了，只有2662.20次/秒。
3） UDP_RR
UDP_RR方式使用UDP分组进行request/response的交易过程。由于没有TCP连接所带来的负担，所以我们推测交易率一定会有相应的提升。
#./netperf -t UDP_RR -H 192.168.0.28
UDP REQUEST/RESPONSE TEST to 192.168.0.28
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
65535 65535 1 1 9.99 10141.16
65535 65535 结果证实了我们的推测，交易率为10141.16次/秒，高过TCP_RR的数值。不过，如果出现了相反的结果，即交易率反而降低了，也不需要担心，因为这说明了在网络中，路由器或其它的网络设备对UDP采用了与TCP不同的缓冲区空间和处理技术。
MZ
Mausezahn是什么？
它是一个用C语言开发的快速产生流量的工具，用户可以用它来发送几乎所有可能和不可能产生的包。它可以用来做如下工作：
- 流量产生器（比如高压的多点传送网络）
- 防火墙和IDS的穿透测试
- 网络中的DoS攻击
- 在网络软件或工具中发现bug
- 用大量的ping和端口扫描搜索攻击
- 测试网络行为在奇怪的环境下（如压力测试，畸形包）
- 实验室里教学工具
MZ是一个有着简单语法和在线帮助的命令行的万能发包工具，它还能用在脚本里做各种测试。目前mz只有Linux平台的版本或者类似Unix平台的版本，没有windows版本的。
| 参数 | 说明 |
|---|---|
| -t | 指定包类型（IP，UDP，TCP，ARP，BPDU，CDP，部分的ICMP，RTP,DNS和SYSLOG |
| -a | 指定源mac |
| -b | 指定目的mac |
| -A | 指定源ip |
| -B | 指定目的ip |
| -p | 指定未加工的帧指定长度（随机字节数）； |
| -P | 指定ASCII字符有效载荷 |
| -r | 指定delay的时间为随机值 |
| -f | 从文件中读取ASCII的有效载荷 |
| -F | 从文件中读取16进制数字的有效载荷 |
| -S | 模拟方式：电线里不放任何数据，它通常与详细的模式（－v或者V） |
自动产生包
当前有如下类型包的产生器（ARP，BPDU，CDP，IP，部分的ICMP，UDP，TCP，RTP,DNS和SYSLOG）,对于每个包你都可以指定可选的有效载荷,这既可以用参数payload（或小写的p）来表示十六进制符号或直接用“－P”选项来表示ASCII文本：
# 字节被定义为2个16进制数。多字节必须用空格，冒号，横线或者任何你喜欢的分隔
mz eth0 -t ip p=68:65:6c:6c:6f:20:77:6f:72:6c:64
# ASCII文本
mz eth0 -t ip -P "Hello World" 二层：
默认情况是每次只有一个包发送，如果你想发送多个包可以用选项 －c ，当count＝0时mz会永远发送。
每间隔50毫秒发送100,000个帧：
# mz -c 100000 -d 50msec "aa bb cc dd ...."
间隔2秒发送一个无穷大的BPDU帧
# mz -c 0 -d 2s -t bpdu conf
用最大速度发送帧，用随机的MAC地址和广播的目的地址，另外把帧设置为1000字节：
# mz eth0 -c 0 -a rand -b bcast -p 1000 "08 00 aa bb cc dd"
在VLAN500发送一个CoS＝7的TCP的包
# mz eth0 -t tcp -Q 7:500 "dp=80, flags=rst, p=aa:aa:aa"
发送一个VLAN标志为100（外部）和651（内部）的UDP包
# mz eth0 -t udp "dp=8888, sp=13442" -P "Mausezahn is great" -Q 100,651三－七层：
UDP
Mz支持UDP数据包的产生。简单地指定目的地址（－B选项）并且可选的选择任意的源地址（－A选项）作为参数，你还可以通过dp（目的端口）和sp（源端口）指定端口号以及有效载荷。甚至你可以指定整个端口范围，如此一来就可以发送多个包。
发送测试包到RTP端口的范围：
mz eth0 -B 192.168.1.1 -t udp "dp=16384-32767, \
p=A1:00:CC:00:00:AB:CD:EE:EE:DD:DD:00"
TCP
Mz运行你很轻松的建TCP包。类似UDP你可以用sp和dp来指定源和目标端口参数。接着你可以通过“|”作为分隔符直接指定想要的标志如果你想指定多个标志的话。例如，对于1.1.1.1的SYN－Flood攻击就使用随机的源地址定时的使用所有的1023个端口：
mz eth0 -A rand -B 1.1.1.1 -c 0 -t tcp "dp=1-1023, flags=syn" \
-P "Good morning! This is a SYN Flood Attack. \
We apologize for any inconvenience."