在构建或管理一个网络系统时，我们更多的是关心网络的可用性，即网络是否连通，而对于其整体的性能往往考虑不多。
或者即使考虑到性能的问题，但是却发现没有合适的手段去测试网络的性能。 当开发出一个网络应用程序后。
我们会发现，在实际的网络环境使用中。
网络应用程序的使用效果不 是很理想，问题可能出现在程序的开发上面，也有可能由于实际的网络环境中存在着瓶颈。面对这种问题。
程序员一般会一筹莫展，原因就在于不掌握一些网络性能测量的工具。 在本文中。
首先介绍网络性能测量的一些基本概念和方法，然后结合 netperf 工具的使用，具体的讨论如何测试不同情况下的网络性能。 网络性能测试概述 测量网络性能的五项指标是： 可用性（ilbility） 响应时间（repone tie） 网络利用率（network utilition） 网络吞吐量（network trougput） 网络带宽容量（network bndwidt cpcity）1． 可用性 测试网络性能的第一步是确定网络是否正常工作。
最简单的方法是使用 ping 命令。通过向远端的机器发送 icp eco requet，并等待接收 icp eco reply 来判断遥端的机器是否连通。
网络是否正常工作。 Ping 命令有非常丰富的命令选项，比如 -c 可以指定发送 eco requet 的个数。
- 可以指定每次发送的 ping 包大小。 网络设备内部一般有多个缓冲池。
不同的缓冲池使用不同的缓冲区大小，分别用来处理不同大小的分组（pcket）。例如交换机中通常具有三种类型的 包缓冲：一类针对小的分组。
一类针对中等大小的分组。
还有一类针对大的分组。为了测试这样的网络设备。
测试工具必须要具有发送不同大小分组的能力。 Ping 命令的 - 就可以使用在这种场合。2． 响应时间 Ping 命令的 eco requet/reply 一次来回所花费时间就是响应时间。有很多因素会影响到响应时间。
如网段的负荷。
网络主机的负荷。
广播风暴。
工作不正常的网络设备等等。 在网络工作正常时。
记录下正常的响应时间。当用户抱怨网络的反应时间慢时，就可以将现在的响应时间与正常的响应时间对比，如果两者差值的波动很大，就能说明网络设备存在故障。 字串93． 网络利用率 字串9网络利用率是指网络被使用的时间占总时间（即被使用的时间+空闲的时间）的比例。比如，Eternet 虽然是共享的。
但同时却只能有一个报文在传输。因此在任一时刻。
Eternet 或者是 100% 的利用率。
或者是 0% 的利用率。计算一个网段的网络利用率相对比较容易，但是确定一个网络的利用率就比较复杂。因此，网络测试工具一般使用网络吞吐量和网络带宽容量来确定网络中两个节点之间的性能。4． 网络吞吐量网络吞吐量是指在某个时刻。
在网络中的两个节点之间。
提供给网络应用的剩余带宽。 网络吞吐量可以帮组寻找网络路径中的瓶颈。比如，即使 client 和 erer 都被分别连接到各自的 100M Eternet 上。
但是如果这两个 100M 的Eternet 被 10M 的 Eternet 连接起来。
那么 10M 的 Eternet 就是网络的瓶颈。网络吞吐量非常依赖于当前的网络负载情况。因此。
为了得到正确的网络吞吐量，最好在不同时间（一天中的不同时刻，或者一周中不同的天）分别进行测试。
只有这样才能得到对网络吞吐量的全面熟悉。 有些网络应用程序在开发过程的测试中能够正常运行。
但是到实际的网络环境中却无法正常工作（由于没有足够的网络吞吐量）。这是因为测试只是在空闲的网络环 境中。
没有考虑到实际的网络环境中还存在着其它的各种网络流量。所以。
网络吞吐量定义为剩余带宽是有实际意义的。5． 网络带宽容量 与网络吞吐量不同，网络带宽容量指的是在网络的两个节点之间的最大可用带宽。这是由组成网络的设备的能力所决定的。测试网络带宽容量有两个困难之处：在网络存在其它网络流量的时候，如何得知网络的最大可用带宽；在测试过程中，如何对现有的网络流量不造成影响。网络测试工具一般采用 pcket pir 和 pcket trin 技术来克服这样的困难。当确定了网络性能的测试指标以后。
就需要使用网络测试工具收集相应的性能数据，分别有三种从网络获取数据的方式： 1． 通过np协议直接到网络设备中获取，如net-np工具2． 侦听相关的网络性能数据。
典型的工具是tcpdup 3． 自行产生相应的测试数据。
如本文中使用的netperf工具Netperf是一种网络性能的测量工具，主要针对基于TCP 或UDP的传输。Netperf根据应用的不同，可以进行不同模式的网络性能测试。
即批量数据传输（bulk dt trnfer）模式和请求/应答（requet/repone）模式。Netperf测试结果所反映的是一个系统能够以多快的速度向另外一个系统 发送数据。
以及另外一个系统能够以多块的速度接收数据。 Netperf工具以client/erer方式工作。erer端是neterer。
用来侦听来自client端的连接。
client 端是netperf。
用来向erer发起网络测试。在client与erer之间，首先建立一个控制连接，传递有关测试配置的信息，以及测试的结 果；在控制连接建立并传递了测试配置信息以后，client与erer之间会再建立一个测试连接，用来来回传递着特殊的流量模式。
以测试网络的性能。 由于TCP协议能够提供端到端的可靠传输，因此被大量的网络应用程序使用。但是。
可靠性的建立是要付出代价的。TCP协议保证可靠性的措施。
如建立并维护连接、控制数据有序的传递等都会消耗一定的网络带宽。 Netperf可以模拟三种不同的TCP流量模式： 1） 单个TCP连接。
批量（bulk）传输大量数据 2） 单个TCP连接。
client请求/erer应答的交易（trnction）方式 3） 多个TCP连接。
每个连接中一对请求/应答的交易方式 UDP没有建立连接的负担。
但是UDP不能保证传输的可靠性。
所以使用UDP的应用程序需要自行跟踪每个发出的分组。
并重发丢失的分组。Netperf可以模拟两种UDP的流量模式： 1） 从client到erer的单向批量传输2） 请求/应答的交易方式 由于UDP传输的不可靠性。
在使用netperf时要确保发送的缓冲区大小不大于接收缓冲区大小，否则数据会丢失，netperf将给出错误的结果。因此。
对于接收到分组的统计不一定准确，需要结合发送分组的统计综合得出结论。 在unix系统中。
可以直接运行可执行程序来启动neterer，也可以让inetd或xinetd来自动启动neterer。 当neterer在erer端启动以后。
就可以在client端运行netperf来测试网络的性能。netperf通过命令行参数来控制 测试的类型和详细的测试选项。根据作用范围的不同，netperf的命令行参数可以分为两大类：全局命令行参数、测试相关的局部参数。
两者之间使用--分 隔： netperf [globl option]-- [tet-pecific option] 这里我们只解释那些常用的命令行参数，其它的参数读者可以查询netperf的n手册。-H ot ：指定远端运行neterer的erer IP地址。 -l tetlen：指定测试的时间长度（秒）-t tetne：指定入行的测试类型。
包括TCP_STREAM，UDP_STREAM。
TCP_RR，TCP_CRR，UDP_RR。
在下文中分别对它们说明。在后面的测试中，neterer运行在192.168.0.28，erer与client通过局域网连接（100M Hub）。 字串3 测试批量（bulk）网络流量的性能批量数据传输典型的例子有ftp和其它类似的网络应用（即一次传输整个文件）。根据使用传输协议的不同，批量数据传输又分为TCP批量传输和UDP批量传输。 1． TCP_STREAM Netperf缺省情况下进行TCP批量传输，即-t TCP_STREAM。测试过程中，netperf向neterer发送批量的TCP数据分组，以确定数据传输过程中的吞吐量： ./netperf -H 192.168.0.28 -l 60TCP STREAM TEST to 192.168.0.28Rec Send SendSocket Socket Mege ElpedSie Sie Sie Tie Trougputbyte byte byte ec. 10^6bit/ec87380 16384 16384 60.00 88.00 从netperf的结果输出中，我们可以知道以下的一些信息： 1） 遥端系统（即erer）使用大小为87380字节的ocket接收缓冲2） 本地系统（即client）使用大小为16384字节的ocket发送缓冲 3） 向远端系统发送的测试分组大小为16384字节4） 测试经历的时间为60秒5） 吞吐量的测试结果为88Mbit/秒 在缺省情况下。
netperf向发送的测试分组大小设置为本地系统所使用的ocket发送缓冲大小。 TCP_STREAM方式下与测试相关的局部参数如下表所示： 参数 说明 - ie设置本地系统的ocket发送与接收缓冲大小-S ie 设置遥端系统的ocket发送与接收缓冲大小- ie 设置本地系统发送测试分组的大小-M ie设置遥端系统接收测试分组的大小-D对本地与遥端系统的ocket设置TCP_NODELAY选项 通过修改以上的参数。
并看察结果的变化。
我们可以确定是什么因素影响了连接的吞吐量。例如，如果怀疑路由器由于缺乏足够的缓冲区空间，使得转发大的分组时存在问题。
就可以增加测试分组（-）的大小，以观察吞吐量的变化：./netperf -H 192.168.0.28 -l 60 -- - 2048 TCP STREAM TEST to 192.168.0.28 Rec Send SendSocket Socket Mege Elped Sie Sie Sie Tie Trougputbyte byte byte ec. 10^6bit/ec87380 16384 2048 60.00 87.62 在这里。
测试分组的大小减少到2048字节。
而吞吐量却没有很大的变化（与前面例子中测试分组大小为16K字节相比）。相反。
如果吞吐量有了较大的提升，则说明在网络中间的路由器确实存在缓冲区的问题。2． UDP_STREAMUDP_STREAM用来测试进行UDP批量传输时的网络性能。需要特别注意的是，此时测试分组的大小不得大于ocket的发送与接收缓冲大小。
否则netperf会报出错提示： ./netperf -t UDP_STREAM -H 192.168.0.28 -l 60 UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28 udp_end: dt end error: Mege too long为了避免这样的情况。
可以通过命令行参数限定测试分组的大小。
或者增加ocket的发送/接收缓冲大小。UDP_STREAM方式使用与TCP_STREAM方式相同的局部命令行参数。
因此。
这里可以使用-来修改测试中使用分组的大小：./netperf -t UDP_STREAM -H 192.168.0.28 -- - 1024UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28Socket Mege Elped MegeSie Sie Tie Oky Error Trougput byte byte ec # # 10^6bit/ec65535 1024 9.99 114127 0 93.55 65535 9.99 114122 93.54UDP_STREAM方式的结果中有两行测试数据，第一行显示的是本地系统的发送统计。
这里的吞吐量表示netperf向本地ocket发送分组的能力。但是。
我们知道。
UDP是不可靠的传输协议，发送出去的分组数量不一定等于接收到的分组数量。 字串1第二行显示的就是遥端系统接收的情况，由于client与erer直接连接在一起。
而且网络中没有其它的流量。
所以本地系统发送过去的分组几乎 都被遥端系统正确的接收了，遥端系统的吞吐量也几乎等于本地系统的发送吞吐量。但是。
在实际环境中。
一般遥端系统的ocket缓冲大小不同于本地系统的 ocket缓冲区大小，而且由于UDP协议的不可靠性。
遥端系统的接收吞吐量要遥遥小于发送出去的吞吐量。另一类常见的网络流量类型是应用在client/erer结构中的requet/repone模式。在每次交易（trnction）中。
client向erer发出小的查询分组，erer接收到请求。
经处理后返回大的结果数据。1． TCP_RR TCP_RR方式的测试对象是多次TCP requet和repone的交易过程。
但是它们发生在同一个TCP连接中，这种模式常常出现在数据库应用中。数据库的client程序与erer程序建立一个TCP连接以后，就在这个连接中传送数据库的多次交易过程。./netperf -t TCP_RR -H 192.168.0.28 TCP REQUEST/RESPONSE TEST to 192.168.0.28 Locl /Reote Socket Sie Requet Rep. Elped Trn. Send Rec Sie Sie Tie Rtebyte Byte byte byte ec. per ec16384 87380 1 1 10.00 9502.7316384 87380 Netperf输出的结果也是由两行组成。第一行显示本地系统的情况，第二行显示的是遥端系统的信息。平均的交易率（trnction rte）为9502.73次/秒。注意到这里每次交易中的requet和repone分组的大小都为1个字节。
不具有很大的实际意义。用户可以通 过测试相关的参数来改变requet和repone分组的大小。
TCP_RR方式下的参数如下表所示： 参数说明 -r req,rep 设置requet和repone分组的大小 - ie 设置本地系统的ocket发送与接收缓冲大小-S ie 设置遥端系统的ocket发送与接收缓冲大小-D对本地与远端系统的ocket设置TCP_NODELAY选项通过使用-r参数。
我们可以入行更有实际意义的测试：./netperf -t TCP_RR -H 192.168.0.28 -- -r 32,1024TCP REQUEST/RESPONSE TEST to 192.168.0.28 Locl /ReoteSocket Sie Requet Rep. Elped Trn.Send Rec Sie Sie Tie Rte byte Byte byte byte ec. per ec16384 87380 32 1024 10.00 4945.9716384 87380 从结果中可以观出，由于requet/repone分组的大小增加了，导致了交易率明显的下降。注：相对于实际的系统。
这里交易率的计算没有充分考虑到交易过程中的应用程序处理时延。
因此结果往往会高于实际情况。 2． TCP_CRR 与TCP_RR不同，TCP_CRR为每次交易建立一个新的TCP连接。最典型的应用就是HTTP。
每次HTTP交易是在一条单独的TCP连接中入行的。因此。
由于需要不停地建立新的TCP连接。
并且在交易结束后拆除TCP连接，交易率一定会受到很大的影响。 ./netperf -t TCP_CRR -H 192.168.0.28 TCP Connect/Requet/Repone TEST to 192.168.0.28 Locl /Reote Socket Sie Requet Rep. Elped Trn.Send Rec Sie Sie Tie Rtebyte Byte byte byte ec. per ec131070 131070 1 1 9.99 2662.20 16384 87380 即使是使用一个字节的requet/repone分组。
交易率也明显的降低了，只有2662.20次/秒。TCP_CRR使用与TCP_RR相同的局部参数。 3． UDP_RR UDP_RR方式使用UDP分组进行requet/repone的交易过程。由于没有TCP连接所带来的负担。
所以我们推测交易率一定会有相应的提升。 ./netperf -t UDP_RR -H 192.168.0.28 UDP REQUEST/RESPONSE TEST to 192.168.0.28Locl /Reote Socket Sie Requet Rep. Elped Trn.Send Rec Sie Sie Tie Rtebyte Byte byte byte ec. per ec65535 65535 1 1 9.99 10141.1665535 65535结果证明了我们的推测。
交易率为10141.16次/秒。
高过TCP_RR的数值。不过。
如果出现了相反的结果。
即交易率反而降低了。
也不需要担心。
因为这说明了在网络中，路由器或其它的网络设备对UDP采用了与TCP不同的缓冲区空间和处理技术。 除了netperf以外。
还有很多其它的网络性能测试工具。
如db, iperf, ptrte, nettet, netlogger, tcptrce, ntop等。这些工具有其各自的特色和不同的侧重点，我们可以根据具体的应用环境，有选择的使用它们，这样就可以使这些工具发挥出最大的功效。虽然都是开 放源代码的软件。
但是这些工具的功能与商业的网络测试工具同样强大。
而且也得到了广泛的应用。
认识这些工具对我们的实际工作一定会有很大的帮助。 Network Perfornce Open Source Toolkit, Ricrd Blu, Wiley Publiing, Inc. netperf webite,ttp://www.netperf.org
转自：http://blog.csdn.net/adrian169/article/details/9152897/