網絡基本功（十六）：細說網絡性能監測與實例（下） · 網絡基本功系列

# 網絡基本功（十六）：細說網絡性能監測與實例（下） **轉載請在文首保留原文出處：EMC中文支持論壇**[https://community.emc.com/go/chinese](https://community.emc.com/go/chinese) [![image001.gif](https://community.emc.com/servlet/JiveServlet/downloadImage/2-852040-102113/image001.gif)](https://community.emc.com/servlet/JiveServlet/showImage/2-852040-102113/image001.gif) ## 介紹網絡問題中，性能問題是最復雜的問題之一，解決這樣的問題能夠透徹的了解整個網絡的結構。但通過合適的吞吐量和數據流測試工具，能夠幫你快速找到問題所在。本文承接上文，闡述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,例如錯誤校驗和，通常產生于服務器。沖突往往意味著網絡擁塞。當然，這只是一般情況。參考 Network Troubleshooting Tools