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

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

 

轉載請在文首保留原文出處：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,例如錯誤校驗和，一般產生於服務器。衝突每每意味着網絡擁塞。固然，這只是通常狀況。