Netperf概况
Netperf是一种网络性能的测量工具，主要针对基于TCP或UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试，即批量 数据传输（bulk data transfer）模式和请求/应答（request/reponse）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统 发送数据，以及另外一个系统能够以多块的速度接收数据。
Netperf工具以client/server方式工作。server端是 netserver，用来侦听来自client端的连接，client端是netperf，用来向server发起网络测试。在client与 server之间，首先建立一个控制连接，传递有关测试配置的信息，以及测试的结果；在控制连接建立并传递了测试配置信息以后，client与 server之间会再建立一个测试连接，用来来回传递着特殊的流量模式，以测试网络的性能。
TCP网络性能
由于TCP协议能够提供端到端的可靠传输，因此被大量的网络应用程序使用。但是，可靠性的建立是要付出代价的。TCP协议保证可靠性的措施，如建立并维护连接、控制数据有序的传递等都会消耗一定的网络带宽。
Netperf可以模拟三种不同的TCP流量模式：
1） 单个TCP连接，批量（bulk）传输大量数据
2） 单个TCP连接，client请求/server应答的交易（transaction）方式
3） 多个TCP连接，每个连接中一对请求/应答的交易方式
UDP网络性能
UDP没有建立连接的负担，但是UDP不能保证传输的可靠性，所以使用UDP的应用程序需要自行跟踪每个发出的分组，并重发丢失的分组。
Netperf可以模拟两种UDP的流量模式：
1） 从client到server的单向批量传输
2） 请求/应答的交易方式
由于UDP传输的不可靠性，在使用netperf时要确保发送的缓冲区大小不大于接收缓冲区大小，否则数据会丢失，netperf将给出错误的结果。因此，对于接收到分组的统计不一定准确，需要结合发送分组的统计综合得出结论。
在后面的测试中，netserver运行在10.3.10.238，server与client直连。服务端输入命令：netserver(有时候会启动失败，可以通过sudo netstat -aputen | grep 12865查询netserver服务端是否启动)
Netperf安装过程：
上传netperf-master.zip安装包到机器
unzip netperf-master.zip
cd netperf-master/
cp /usr/share/automake-1.16/config.guess /root/xyr/netperf-master/ //针对SW架构，进行配置时，会报错识别不到SW架构，需手动指定架构
cp /usr/share/automake-1.16/config.sub /root/xyr/netperf-master/ //针对SW架构，进行配置时，会报错识别不到SW架构，需手动指定架构
cd /root/xyr/netperf-master/
./autogen.sh
./configure
make
sudo make install
Netperf测试网络性能
测试批量（bulk）网络流量的性能
批量数据传输典型的例子有ftp和其它类似的网络应用（即一次传输整个文件）。
根据使用传输协议的不同，批量数据传输又分为TCP批量传输和UDP批量传输。
1． TCP_STREAM Netperf缺省情况下进行TCP批量传输，即-t TCP_STREAM。测试过程中，netperf向netserver发送批量的TCP数据分组，以确定数据传输过程中的吞吐量：
netperf -H 10.3.10.238（例） -t TCP_STREAM
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.3.10.238 () port 0 AF_INET
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
131072 16384 16384 10.03 940.24
从netperf的结果输出中，我们可以知道以下的一些信息：
1） 远端系统（即server）使用大小为131072字节的socket接收缓冲
2） 本地系统（即client）使用大小为16384字节的socket发送缓冲
3） 向远端系统发送的测试分组大小为16384字节
4） 测试经历的时间为10.03秒
5） 吞吐量的测试结果为940.24Mbits/秒
在缺省情况下，netperf向发送的测试分组大小设置为本地系统所使用的socket发送缓冲大小。
TCP_STREAM方式下与测试相关的局部参数如下表所示：
参数 说明
-s size 设置本地系统的socket发送与接收缓冲大小
-S size 设置远端系统的socket发送与接收缓冲大小
-m size 设置本地系统发送测试分组的大小
-M size 设置远端系统接收测试分组的大小
-D 对本地与远端系统的socket设置TCP_NODELAY选项
通过修改以上的参数，并观察结果的变化，我们可以确定是什么因素影响了连接的吞吐量。
2． UDP_STREAM UDP_STREAM用来测试进行UDP批量传输时的网络性能。
netperf -H 10.3.10.238（例） -t UDP_STREAM
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.3.10.238 () port 0 AF_INET
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
2097152 65507 10.00 18342 0 961.21
2097152 10.00 18342 961.21
UDP_STREAM方式的结果中有两行测试数据，
第一行显示的是本地系统的发送统计，这里的吞吐量表示netperf向本地socket发送分组的能力。但是，我们知道，UDP是不可靠的传输协议，发送出去的分组数量不一定等于接收到的分组数量。
第二行显示的就是远端系统接收的情况，由于client与server直接连接在一起，而且网 络中没有其它的流量，所以本地系统发送过去的分组几乎都被远端系统正确的接收了，远端系统的吞吐量也几乎等于本地系统的发送吞吐量。但是，在实际环境中， 一般远端系统的socket缓冲大小不同于本地系统的socket缓冲区大小，而且由于UDP协议的不可靠性，远端系统的接收吞吐量要远远小于发送出去的 吞吐量。
3.TCP协议网络传输平均延迟
netperf -H 10.3.10.238 -t TCP_STREAM -- -m 15000 -d rr -O "THROUGHPUT, THROUGHPUT_UNITS, MIN_LATENCY, MAX_LATENCY, MEAN_LATENCY"
MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.3.10.238 () port 0 AF_INET
Throughput Throughput Minimum Maximum Mean
Units Latency Latency Latency
Microseconds Microseconds Microseconds
939.78 10^6bits/s 1 14599 11.55
最小延时：为1微秒
最大延时：为14599微秒
平均延时：为11.55微秒
4.UDP协议网络传输平均延迟
netperf -H 10.3.10.238 -t UDP_STREAM -- -m 15000 -d rr -O "THROUGHPUT, THROUGHPUT_UNITS, MIN_LATENCY, MAX_LATENCY, MEAN_LATENCY"
MIGRATED UDP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.3.10.238 () port 0 AF_INET
Throughput Throughput Minimum Maximum Mean
Units Latency Latency Latency
Microseconds Microseconds Microseconds
461.91 10^6bits/s 15 697 24.63
最小延时：为15微秒
最大延时：为697微秒
平均延时：为24.63微秒
测试请求/应答（request/response）网络流量的性能
另一类常见的网络流量类型是应用在client/server结构中的request/response模式。在每次交易（transaction）中，client向server发出小的查询分组，server接收到请求，经处理后返回大的结果数据。 如下图所示：
1． TCP_RR
TCP_RR方式的测试对象是多次TCP request和response的交易过程，但是它们发生在同一个TCP连接中，这种模式常常出现在数据库应用中。数据库的client程序与 server程序建立一个TCP连接以后，就在这个连接中传送数据库的多次交易过程。
netperf -t TCP_RR -H 10.3.10.236 -l 120 -- -r 32,1024 //通过使用-r参数，我们可以进行更有实际意义的测试：
MIGRATED TCP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.3.10.238 () port 0 AF_INET : first burst 0
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 131072 32 1024 120.00 1547.14
16384 131072
Netperf输出的结果也是由两行组成。
第一行显示本地 系统的情况，第二行显示的是远端系统的信息。平均的交易率（transaction rate）为1547.14次/秒。注意到这里每次交易中的request和response分组的大小都为1个字节，不具有很大的实际意义。用户可以通 过测试相关的参数来改变request和response分组的大小，TCP_RR方式下的参数如下表所示：
参数 说明
-r req,resp 设置request和reponse分组的大小
-s size 设置本地系统的socket发送与接收缓冲大小
-S size 设置远端系统的socket发送与接收缓冲大小
-D 对本地与远端系统的socket设置TCP_NODELAY选项
2． TCP_CRR
与TCP_RR不同，TCP_CRR为每次交易建立一个新的TCP连接。
最典型的应用就是HTTP，每次HTTP交易是在一条单独的TCP连接中进行的。
因此，由于需要不停地建立新的TCP连接，并且在交易结束后拆除TCP连接，交易率一定会受到很大的影响。
netperf -H 10.3.10.238 -l 120 -t TCP_CRR
MIGRATED TCP Connect/Request/Response TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.3.10.238 () port 0 AF_INET
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
16384 131072 1 1 120.00 770.27
16384 131072
即使是使用一个字节的request/response分组，交易率也明显的降低了，只有770.27 次/秒。
TCP_CRR使用与TCP_RR相同的局部参数。
3． UDP_RR
UDP_RR方式使用UDP分组进行request/response的交易过程。
由于没有TCP连接所带来的负担，所以我们推测交易率一定会有相应的提升。
netperf -H 10.3.10.238 -l 120 -t UDP_RR
MIGRATED UDP REQUEST/RESPONSE TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 10.3.10.238 () port 0 AF_INET : first burst 0
Local /Remote
Socket Size Request Resp. Elapsed Trans.
Send Recv Size Size Time Rate
bytes Bytes bytes bytes secs. per sec
2097152 2097152 1 1 120.00 1619.38
2097152 2097152
结果证实了我们的推测，交易率为1619.38次/秒，高过TCP_RR的数值。
网络性能测量的五项指标
1． 可用性（availability）
测试网络性能的第一步是确定网络是否正常工作，最简单的方法是使用 ping 命令。通过向远端的机器发送 icmp echo request，并等待接收 icmp echo reply 来判断远端的机器是否连通，网络是否正常工作。
Ping 命令有非常丰富的命令选项，比如 -c 可以指定发送 echo request 的个数，-s 可以指定每次发送的 ping 包大小。
网络设备内部一般有多个缓冲池，不同的缓冲池使用不同的缓冲区大小，分别用来处理不同大小的分组（packet）。例如交换机中通常具 有三种类型的包缓冲：一类针对小的分组，一类针对中等大小的分组，还有一类针对大的分组。为了测试这样的网络设备，测试工具必须要具有发送不同大小分组的 能力。Ping 命令的 -s 就可以使用在这种场合。
2． 响应时间（response time）
Ping 命令的 echo request/reply 一次往返所花费时间就是响应时间。有很多因素会影响到响应时间，如网段的负荷，网络主机的负荷，广播风暴，工作不正常的网络设备等等。
在网络工作正常时，记录下正常的响应时间。当用户抱怨网络的反应时间慢时，就可以将现在的响应时间与正常的响应时间对比，如果两者差值的波动很大，就能说明网络设备存在故障。
3． 网络利用率（network utilization）
网络利用率是指网络被使用的时间占总时间（即被使用的时间+空闲的时间）的比例。比如，Ethernet 虽然是共享的，但同时却只能有一个报文在传输。因此在任一时刻，Ethernet 或者是 100% 的利用率，或者是 0% 的利用率。
计算一个网段的网络利用率相对比较容易，但是确定一个网络的利用率就比较复杂。因此，网络测试工具一般使用网络吞吐量和网络带宽容量来确定网络中两个节点之间的性能。
4． 网络吞吐量（network throughput）
网络吞吐量是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。
网络吞吐量可以帮助寻找网络路径中的瓶颈。比如，即使 client 和 server 都被分别连接到各自的 1000M Ethernet 上，但是如果这两个 1000M 的Ethernet 被 100M 的 Ethernet 连接起来，那么 100M 的 Ethernet 就是网络的瓶颈。
网络吞吐量非常依赖于当前的网络负载情况。因此，为了得到正确的网络吞吐量，最好在不同时间（一天中的不同时刻，或者一周中不同的天）分别进行测试，只有这样才能得到对网络吞吐量的全面认识。
有些网络应用程序在开发过程的测试中能够正常运行，但是到实际的网络环境中却无法正常工作（由于没有足够的网络吞吐量）。这是因为测试只是在空闲的网络环境中，没有考虑到实际的网络环境中还存在着其它的各种网络流量。所以，网络吞吐量定义为剩余带宽是有实际意义的。
5． 网络带宽容量（network bandwidth capacity）
与网络吞吐量不同，网络带宽容量指的是在网络的两个节点之间的最大可用带宽。这是由组成网络的设备的能力所决定的。
测试网络带宽容量有两个困难之处：在网络存在其它网络流量的时候，如何得知网络的最大可用带宽；在测试过程中，如何对现有的网络流量不造成影响。网络测试工具一般采用 packet pairs 和 packet trains 技术来克服这样的困难。