网络基本功（十六）：细说网络性能监测与实例（下）

转载请在文首保留原文出处：EMC中文支持论坛https://community.emc.com/go/chinese
image001.gif

介绍

网络问题中，性能问题是最复杂的问题之一，解决这样的问题能够透彻的了解整个网络的结构。但通过合适的吞吐量和数据流测试工具，能够帮你快速找到问题所在。本文承接上文，阐述netperf和netstat的用法。

更多信息

吞吐量测量:

(承接上文)

netperf

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

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

  1. bsd1# netserver
  2. Starting netserver at port 12865
  3. bsd1# netperf
  4. TCP STREAM TEST to localhost : histogram
  5. Recv   Send    Send
  6. Socket Socket  Message  Elapsed
  7. Size   Size    Size     Time     Throughput
  8. bytes  bytes   bytes    secs.    10^6bits/sec
  9. 16384  16384  16384    10.00     326.10

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

下例中，netserver启动于主机：

  1. bsd1# netserver
  2. Starting netserver at port 12865
  3. netperf加上-H选项指定服务器地址：
  4. bsd2# netperf -H 205.153.60.247
  5. TCP STREAM TEST to 205.153.60.247 : histogram
  6. Recv   Send    Send
  7. Socket Socket  Message  Elapsed
  8. Size   Size    Size     Time     Throughput
  9. bytes  bytes   bytes    secs.    10^6bits/sec
  10. 16384  16384  16384    10.01       6.86

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

  1. bsd2# netperf -H 205.153.60.247 -tTCP_RR
  2. TCP REQUEST/RESPONSE TEST to 205.153.60.247 : histogram
  3. Local /Remote
  4. Socket Size   Request  Resp.   Elapsed  Trans.
  5. Send   Recv   Size     Size    Time     Rate
  6. bytes  Bytes  bytes    bytes   secs.    per sec
  7. 16384  16384  1        1       10.00     655.84
  8. 16384  16384

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

iperf

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

下例是运行iperf服务器端：

  1. 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运行客户端：

  1. C:\>iperf -c205.153.60.236
  2. -p3000
  3. ------------------------------------------------------------
  4. Client connecting to 205.153.60.236, TCP port 3000
  5. TCP window size:  8.0 KByte (default)
  6. ------------------------------------------------------------
  7. [ 28] local 205.153.63.30 port 1133 connected with 205.153.60.236 port 3000
  8. [ ID] Interval       Transfer     Bandwidth
  9. [ 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。如下例所示：

  1. bsd2# treno 205.153.63.30
  2. MTU=8166  MTU=4352  MTU=2002  MTU=1492 ..........
  3. Replies were from sloan.lander.edu [205.153.63.30]
  4.     Average rate: 3868.14 kbp/s (3380 pkts in + 42 lost = 1.2%) in 10.07 s
  5. Equilibrium rate:      0 kbp/s (0 pkts in + 0 lost =   0%) in    0 s
  6. Path properties: min RTT was  13.58 ms, path MTU was 1440 bytes
  7. XXX Calibration checks are still under construction, use –v

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

通过netstat进行流量测量:

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

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

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

  1. bsd2# netstat -i
  2. Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
  3. lp0*  1500  <Link>                               0     0        0     0     0
  4. ep0   1500  <Link>      00.60.97.06.22.22 13971293     0  1223799     1     0
  5. ep0   1500  205.153.63    bsd2            13971293     0  1223799     1     0
  6. tun0* 1500  <Link>                               0     0        0     0     0
  7. sl0*  552   <Link>                               0     0        0     0     0
  8. ppp0* 1500  <Link>                               0     0        0     0     0
  9. lo0   16384 <Link>                             234     0      234     0     0
  10. 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选项指定，如：

  1. bsd2# netstat -Iep0
  2. Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
  3. ep0   1500  <Link>      00.60.97.06.22.22 13971838     0  1223818     1     0
  4. ep0   1500  205.153.63    bsd2            13971838     0  1223818     1     0

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

  1. lnx1# netstat -i
  2. Kernel Interface table
  3. Iface   MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
  4. eth0   1500   0  7366003      0      0      0    93092      0      0      0 BMRU
  5. eth1   1500   0   289211      0      0      0    18581      0      0      0 BRU
  6. lo     3924   0      123      0      0      0      123      0      0      0 LRU

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

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

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

首先，运行netstat来得到当前值：

  1. bsd2# netstat -Iep0
  2. Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
  3. ep0   1500  <Link>      00.60.97.06.22.22 13978296     0  1228137     1     0
  4. ep0   1500  205.153.63    bsd2            13978296     0  1228137     1     0

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

  1. bsd1# spray -c1000 205.153.63.239
  2. sending 1000 packets of lnth 86 to 205.153.63.239 ...
  3.         in 0.09 seconds elapsed time
  4.         464 packets (46.40%) dropped
  5. Sent:   11267 packets/sec, 946.3K bytes/sec
  6. Rcvd:   6039 packets/sec, 507.2K bytes/sec

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

最后，回到netstat来看看是否存在问题：

  1. bsd2# netstat -Iep0
  2. Name  Mtu   Network       Address            Ipkts Ierrs    Opkts Oerrs  Coll
  3. ep0   1500  <Link>      00.60.97.06.22.22 13978964     0  1228156     1     0
  4. ep0   1500  205.153.63    bsd2            13978964     0  1228156     1     0

本例显示没有问题。

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

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

  1. bsd2# netstat -s -s
  2. ip:
  3.         255 total packets received
  4.         255 packets for this host
  5.         114 packets sent from this host
  6. icmp:
  7.         ICMP address mask responses are disabled
  8. igmp:
  9. tcp:
  10.         107 packets sent
  11.                 81 data packets (8272 bytes)
  12.                 26 ack-only packets (25 delayed)
  13.         140 packets received
  14.                 77 acks (for 8271 bytes)
  15.                 86 packets (153 bytes) received in-sequence
  16.         1 connection accept
  17.         1 connection established (including accepts)
  18.         77 segments updated rtt (of 78 attempts)
  19.         2 correct ACK header predictions
  20.         62 correct data packet header predictions
  21. udp:
  22.         115 datagrams received
  23.         108 broadcast/multicast datagrams dropped due to no socket
  24.         7 delivered
  25.         7 datagrams output

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

  1. bsd2# netstat -p tcp -s -s
  2. tcp:
  3.         147 packets sent
  4.                 121 data packets (10513 bytes)
  5.                 26 ack-only packets (25 delayed)
  6.         205 packets received
  7.                 116 acks (for 10512 bytes)
  8.                 122 packets (191 bytes) received in-sequence
  9.         1 connection accept
  10.         1 connection established (including accepts)
  11.         116 segments updated rtt (of 117 attempts)
  12.         2 correct ACK header predictions
  13.         88 correct data packet header predictions

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

参考

Network Troubleshooting Tools

原文: https://wizardforcel.gitbooks.io/network-basic/content/15.html