網絡基本功（十六）：細說網絡性能監測與實例（下）
轉載請在文首保留原文出處：EMC中文支持論壇https://community.emc.com/go/chinese 
介紹
網絡問題中，性能問題是最複雜的問題之一，解決這樣的問題能夠透徹的瞭解整個網絡的結構。但通過合適的吞吐量和數據流測試工具，能夠幫你快速找到問題所在。本文承接上文，闡述netperf和netstat的用法。
更多信息
吞吐量測量:
(承接上文)
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,例如錯誤校驗和，通常產生於服務器。衝突往往意味着網絡擁塞。當然，這只是一般情況。