NAP6官方旗舰店
搜索
发新帖
午饭无线 推广广告R7800 完胜 华硕路由器NETGEAR Vs ASUS T-Mobile定制版NETGEAR团购
开启左侧

网络基本功(二十):细说网络性能监测与实例(下)

[复制链接]
1076 0

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
netperf

该程序是由HP创造,该程序免费可用,运行于一些Unix平台,有支持文档,也被移植到Windows平台。虽然不像ttcp那样无处不在,但它的测试范围更加广泛。

与ttcp不同,客户端和服务器端是分开的程序。服务器端是netserver,能够单独启动,或通过inetd启动。客户端是netperf。下例中,服务器和客户端启动于同一台机器:

bsd1# netserver

Starting netserver at port 12865

bsd1# netperf

TCP STREAM TEST to localhost : histogram

Recv Send Send

Socket Socket Message Elapsed

Size Size Size Time Throughput

bytes bytes bytes secs. 10^6bits/sec



16384 16384 16384 10.00 326.10

测试的是loop-back接口,报告显示吞吐量为326Mbps。


下例中,netserver启动于主机:

bsd1# netserver

Starting netserver at port 12865

netperf加上-H选项指定服务器地址:

bsd2# netperf -H 205.153.60.247

TCP STREAM TEST to 205.153.60.247 : histogram

Recv Send Send

Socket Socket Message Elapsed

Size Size Size Time Throughput

bytes bytes bytes secs. 10^6bits/sec


16384 16384 16384 10.01 6.86

大致与ttcp所得出的吞吐量相同。netperf还进行了一些额外的测试。以下测试中,还计算了连接的transaction rate:

bsd2# netperf -H 205.153.60.247 -tTCP_RR

TCP REQUEST/RESPONSE TEST to 205.153.60.247 : histogram

Local /Remote

Socket Size Request Resp. Elapsed Trans.

Send Recv Size Size Time Rate

bytes Bytes bytes bytes secs. per sec


16384 16384 1 1 10.00 655.84

16384 16384

该程序包含一些测试脚本。也可以使用netperf做各种流测试。


iperf

如果ttcp和netperf都不符合你的要求,那么可以考虑iperf。iperf也可以用于测试UDP带宽,丢失率,和抖动。Java前端让该工具便于使用。该工具同样移植入windows。

下例是运行iperf服务器端:

bsd2# iperf -s -p3000

------------------------------------------------------------

Server listening on TCP port 3000

TCP window size: 16.0 KByte (default)

------------------------------------------------------------

[ 4] local 172.16.2.236 port 3000 connected with 205.153.63.30 port 1133

[ ID] Interval Transfer Bandwidth

[ 4] 0.0-10.0 sec 5.6 MBytes 4.5 Mbits/sec

^C

下例是在windows运行客户端:

C:\>iperf -c205.153.60.236

-p3000

------------------------------------------------------------

Client connecting to 205.153.60.236, TCP port 3000

TCP window size: 8.0 KByte (default)

------------------------------------------------------------

[ 28] local 205.153.63.30 port 1133 connected with 205.153.60.236 port 3000

[ ID] Interval Transfer Bandwidth

[ 28] 0.0-10.0 sec 5.6 MBytes 4.5 Mbits/sec



注意使用Ctrl-C来终止服务器端。在TCP模式下,iperf相当于ttcp,所以它可盈用户客户端或服务器。

在研究TCP窗口是否足够大时,使用iperf特别方便。-w选项设置socket buffer大小。对于TCP来说,这就是窗口大小。通过-w选项,用户可以单步调试各种窗口大小来看它们是怎样影响吞吐量的。


其他工具

你也许想要考虑一些相关或类似的工具。treno使用的方法类似于traceroute来计算块容量,路径MTU,以及最小RTP。如下例所示:

bsd2# treno 205.153.63.30

MTU=8166 MTU=4352 MTU=2002 MTU=1492 ..........

Replies were from sloan.lander.edu [205.153.63.30]

Average rate: 3868.14 kbp/s (3380 pkts in + 42 lost = 1.2%) in 10.07 s

Equilibrium rate: 0 kbp/s (0 pkts in + 0 lost = 0%) in 0 s

Path properties: min RTT was 13.58 ms, path MTU was 1440 bytes

XXX Calibration checks are still under construction, use –v

通常来说,netperf,iperf和treno提供更加丰富的feature,但ttcp更加容易找到。


通过netstat进行流量测量:

在理想的网络环境下,如果把overhead算在内,吞吐量是很接近于带宽的。但是吞吐量往往低于期望值,这种情况下,你会想要知道差异在哪。如之前所提到的,可能与硬件或软件相关。但通常是由于网络上其他数据流的影响。如果你无法确定原因,下一步就是查看你网络上的数据流。

有三种基本方法可供采用。第一,最快的方法是使用如netstat这样的工具来查看链路行为。或通过抓包来查看数据流。最后,可使用基于SNMP的工具如ntop。

要得到网络上数据流的快照,使用-i选项。举例来说:

bsd2# netstat -i

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

lp0* 1500 <Link> 0 0 0 0 0

ep0 1500 <Link> 00.60.97.06.22.22 13971293 0 1223799 1 0

ep0 1500 205.153.63 bsd2 13971293 0 1223799 1 0

tun0* 1500 <Link> 0 0 0 0 0

sl0* 552 <Link> 0 0 0 0 0

ppp0* 1500 <Link> 0 0 0 0 0

lo0 16384 <Link> 234 0 234 0 0

lo0 16384 127 localhost 234 0 234 0 0

输出显示了自上一次重启以来,各接口所处理的报文数量。在本例中,接口ep0收到13,971,293个没有差错(Ierrs)的报文(Ipkts),发送了1,223,799 个报文(Opkts),有1个差错,没有冲突(Coll)。少量错误通常并不是造成告警的原因,但各错误所占比例应当是维持在较低水平,应该明显低于报文总量的0.1%。冲突可以稍微高一些,但应当少于数据流总量的10%。冲突数量仅包括那些影响接口的。较高数量的冲突喻示着网络负载较高,用户应当考虑分段。冲突只出现在特定媒介上。


如果你只想要单一接口的输出,可以通过-I选项指定,如:

bsd2# netstat -Iep0

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

ep0 1500 <Link> 00.60.97.06.22.22 13971838 0 1223818 1 0

ep0 1500 205.153.63 bsd2 13971838 0 1223818 1 0

随着实现的不同,输出可能看起来有些差异,但基本信息是一样的。例如,Linux平台的输出:

lnx1# netstat -i

Kernel Interface table

Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg

eth0 1500 0 7366003 0 0 0 93092 0 0 0 BMRU

eth1 1500 0 289211 0 0 0 18581 0 0 0 BRU

lo 3924 0 123 0 0 0 123 0 0 0 LRU

如上例所示,Linux将丢失报文拆成三个目录:errors, drops,以及overruns。

不方便的是,netstat的返回值是系统自上一次重启之后的累计值。我们真正关心的是这些数值最近是怎样变化的,因为问题是在发展的,在它增长到足以显现问题之前会花费相当长的时间。


有时你会对系统做一些压力测试来看错误是否增加,可以使用ping加 –I选项或spray命令。

首先,运行netstat来得到当前值:

bsd2# netstat -Iep0

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

ep0 1500 <Link> 00.60.97.06.22.22 13978296 0 1228137 1 0

ep0 1500 205.153.63 bsd2 13978296 0 1228137 1 0


接下来,发送大量报文到目的地址。本例中,发送了1000个UDP报文:

bsd1# spray -c1000 205.153.63.239

sending 1000 packets of lnth 86 to 205.153.63.239 ...

in 0.09 seconds elapsed time

464 packets (46.40%) dropped

Sent: 11267 packets/sec, 946.3K bytes/sec

Rcvd: 6039 packets/sec, 507.2K bytes/sec

注意到该测试超出了网络容量,因为464个报文被丢弃了。这可能意味着网络拥塞。更加可能的是,主机正在尝试与一个慢速设备通信。当spray在相反方向运行时,没有报文丢弃。

最后,回到netstat来看看是否存在问题:

bsd2# netstat -Iep0

Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll

ep0 1500 <Link> 00.60.97.06.22.22 13978964 0 1228156 1 0

ep0 1500 205.153.63 bsd2 13978964 0 1228156 1 0

本例显示没有问题。


如果显示有问题,可以通过-s选项来得到。输出数据量可能有点吓人,但可以提供丰富的信息。信息按照协议和错误类型来分段,如bad checksum或报文头不完整。


在某些系统上,两次-s选项显示非零值的总和,如下所示:

bsd2# netstat -s -s

ip:

255 total packets received

255 packets for this host

114 packets sent from this host

icmp:

ICMP address mask responses are disabled

igmp:

tcp:

107 packets sent

81 data packets (8272 bytes)

26 ack-only packets (25 delayed)

140 packets received

77 acks (for 8271 bytes)

86 packets (153 bytes) received in-sequence

1 connection accept

1 connection established (including accepts)

77 segments updated rtt (of 78 attempts)

2 correct ACK header predictions

62 correct data packet header predictions

udp:

115 datagrams received

108 broadcast/multicast datagrams dropped due to no socket

7 delivered

7 datagrams output

通过-p选项显示某一协议的汇总信息,下例显示TCP非零值的统计信息:

bsd2# netstat -p tcp -s -s

tcp:

147 packets sent

121 data packets (10513 bytes)

26 ack-only packets (25 delayed)

205 packets received

116 acks (for 10512 bytes)

122 packets (191 bytes) received in-sequence

1 connection accept

1 connection established (including accepts)

116 segments updated rtt (of 117 attempts)

2 correct ACK header predictions

88 correct data packet header predictions

解释这一结果是需要一些经验的。一开始可以从大量错误信息开始看起。接下来,识别错误类型。通常,input error是由于硬件故障应期的。 Output error是由本地主机的问题造成。Data corruption,例如错误校验和,通常产生于服务器。冲突往往意味着网络拥塞。当然,这只是一般情况。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

快速回复 返回顶部 返回列表