本文首先介绍网络性能測量的一些基本概念和方法。然后结合 netperf 工具的使用。详细的讨论怎样測试不同情况下的网络性能。
在构建或管理一个网络系统时。我们很多其它的是关心网络的可用性。即网络是否连通，而对于其总体的性能往往考虑不多。或者即使考虑到性能的问题，可是却发现没有合适的手段去測试网络的性能。
当开发出一个网络应用程序后，我们会发现，在实际的网络环境使用中。网络应用程序的使用效果不是非常理想，问题可能出如今程序的开发上面，也有可能因为实际的网络环境中存在着瓶颈。面对这样的问题。程序猿通常会一筹莫展，原因就在于不掌握一些网络性能測量的工具。
在本文中，首先介绍网络性能測量的一些基本概念和方法，然后结合 netperf 工具的使用。详细的讨论怎样測试不同情况下的网络性能。
网络性能測试概述
网络性能測量的五项指标
測量网络性能的五项指标是：
- 可用性（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% 的利用率。
计算一个网段的网络利用率相对照较easy，可是确定一个网络的利用率就比較复杂。
因此，网络測试工具一般使用网络吞吐量和网络带宽容量来确定网络中两个节点之间的性能。
4． 网络吞吐量
网络吞吐量是指在某个时刻，在网络中的两个节点之间，提供给网络应用的剩余带宽。
网络吞吐量能够帮组寻找网络路径中的瓶颈。比方。即使 client 和 server 都被分别连接到各自的 100M Ethernet 上，可是假设这两个 100M 的Ethernet 被 10M 的 Ethernet 连接起来，那么 10M 的 Ethernet 就是网络的瓶颈。
网络吞吐量很依赖于当前的网络负载情况。因此。为了得到正确的网络吞吐量，最好在不同一时候间（一天中的不同一时候刻，或者一周中不同的天）分别进行測试。仅仅有这样才干得到对网络吞吐量的全面认识。
有些网络应用程序在开发过程的測试中可以正常执行，可是到实际的网络环境中却无法正常工作（由于没有足够的网络吞吐量）。这是由于測试仅仅是在空暇的网络环境中，没有考虑到实际的网络环境中还存在着其他的各种网络流量。所以。网络吞吐量定义为剩余带宽是有实际意义的。
5． 网络带宽容量
与网络吞吐量不同，网络带宽容量指的是在网络的两个节点之间的最大可用带宽。
这是由组成网络的设备的能力所决定的。
測试网络带宽容量有两个困难之处：在网络存在其他网络流量的时候，怎样得知网络的最大可用带宽；在測试过程中，怎样对现有的网络流量不造成影响。
网络測试工具一般採用 packet pairs 和 packet trains 技术来克服这种困难。
收集网络性能数据的方式
当确定了网络性能的測试指标以后。就须要使用网络測试工具收集对应的性能数据，分别有三种从网络获取数据的方式：
1． 通过snmp协议直接到网络设备中获取。如net-snmp工具
2． 侦听相关的网络性能数据，典型的工具是tcpdump
3． 自行产生对应的測试数据，如本文中使用的netperf工具
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将给出错误的结果。因此，对于接收到分组的统计不一定准确，须要结合发送分组的统计综合得出结论。
Netperf的命令行參数
在unix系统中，能够直接执行可执行程序来启动netserver，也能够让inetd或xinetd来自己主动启动netserver。
当netserver在server端启动以后，就能够在client端执行netperf来測试网络的性能。netperf通过命令行參数来控制測试的类型和详细的測试选项。
依据作用范围的不同，netperf的命令行參数能够分为两大类：全局命令行參数、測试相关的局部參数，两者之间使用--分隔：
netperf [global options]-- [test-specific options]
这里我们仅仅解释那些经常使用的命令行參数。其他的參数读者能够查询netperf的man手冊。
-H host ：指定远端执行netserver的server IP地址。
-l testlen：指定測试的时间长度（秒）
-t testname：指定进行的測试类型，包含TCP_STREAM，UDP_STREAM。TCP_RR。TCP_CRR，UDP_RR。在下文中分别对它们说明。
在后面的測试中，netserver执行在192.168.0.28，server与client通过局域网连接（100M Hub）。
Netperf測试网络性能
測试批量（bulk）网络流量的性能
批量传输数据典型的样例有ftp和其他类似的网络应用（即一次传输整个文件）。依据使用传输协议的不同，批量传输数据又分为TCP批量传输和UDP批量传输。
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） 吞吐量的測试结果为88Mbits/秒
在缺省情况下。netperf向发送的測试分组大小设置为本地系统所使用的socket发送缓冲大小。
TCP_STREAM方式下与測试相关的局部參数例如以下表所看到的：
| 參数 | 说明 |
|---|---|
| -s size | 设置本地系统的socket发送与接收缓冲大小 |
| -S size | 设置远端系统的socket发送与接收缓冲大小 |
| -m size | 设置本地系统发送測试分组的大小 |
| -M size | 设置远端系统接收測试分组的大小 |
| -D | 对本地与远端系统的socket设置TCP_NODELAY选项 |
通过改动以上的參数，并观察结果的变化，我们能够确定是什么因素影响了连接的吞吐量。比如，假设怀疑路由器因为缺乏足够的缓冲区空间。使得转发大的分组时存在问题。就能够添加測试分组（-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协议的不可靠性。远端系统的接收吞吐量要远远小于发送出去的吞吐量。
測试请求/应答（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 192.168.0.28 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 1 1 10.00 9502.73 16384 87380
Netperf输出的结果也是由两行组成。
第一行显示本地系统的情况，第二行显示的是远端系统的信息。
平均的交易率（transaction rate）为9502.73次/秒。
注意到这里每次交易中的request和response分组的大小都为1个字节。不具有非常大的实际意义。用户能够通过測试相关的參数来改变request和response分组的大小，TCP_RR方式下的參数例如以下表所看到的：
| 參数 | 说明 |
|---|---|
| -r req,resp | 设置request和reponse分组的大小 |
| -s size | 设置本地系统的socket发送与接收缓冲大小 |
| -S size | 设置远端系统的socket发送与接收缓冲大小 |
| -D | 对本地与远端系统的socket设置TCP_NODELAY选项 |
通过使用-r參数。我们能够进行更有实际意义的測试：
./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次/秒。TCP_CRR使用与TCP_RR同样的局部參数。
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不同的缓冲区空间和处理技术。
结束语
除了netperf以外，还有非常多其他的网络性能測试工具。如dbs, iperf, pathrate, nettest, netlogger, tcptrace, ntop等。
这些工具有其各自的特色和不同的側重点，我们能够依据详细的应用环境。有选择的使用它们。这样就能够使这些工具发挥出最大的功效。尽管都是开放源码的软件，可是这些工具的功能与商业的网络測试工具相同强大。并且也得到了广泛的应用，熟悉这些工具对我们的实际工作一定会有非常大的帮助。
版权声明：本文博主原创文章，博客，未经同意不得转载。