网络性能检测：流量测量
网络路径性能检测主要包括三方面的内容：
- 带宽测量能够获知网络的硬件特性，如网络的最大容量。
- 吞吐量测量能够获得网络实际可提供的最大容量。
- 数据流测量能够了解真实占用的网络容量。
本文介绍在评估网络性能是否合理时，需要收集的数据及收集方式。
涉及工具包括：ping, pathchar, bing, ttcp, netperf, iperf, netstat。
流量测量
netstat
在理想的网络环境下，如果把overhead算在内，吞吐量是很接近于带宽的。但是吞吐量往往低于期望值，这种情况下，你会想要知道差异在哪。如之前所提到的，可能与硬件或软件相关。但通常是由于网络上其他数据流的影响。如果你无法确定原因，下一步就是查看你网络上的数据流。
有三种基本方法可供采用。
- 第一，最快的方法是使用如netstat这样的工具来查看链路行为。
- 或通过抓包来查看数据流。
- 最后，可使用基于SNMP的工具如ntop。
要得到网络上数据流的快照，使用-i选项。
举例来说：
$ 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选项指定，如：
$ 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平台的输出：
$ 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来得到当前值：
$ 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报文：
$ 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来看看是否存在问题：
$ 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选项显示非零值的总和，如下所示：
$ 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非零值的统计信息：
$ 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,例如错误校验和，通常产生于服务器。冲突往往意味着网络拥塞。当然，这只是一般情况。