網絡基本功(十五):細說網絡性能監測與實例(上)網絡
轉載請在文首保留原文出處:EMC中文支持論壇https://community.emc.com/go/chinese 架構
網絡路徑性能檢測主要包括三方面的內容:帶寬測量可以獲知網絡的硬件特性,如網絡的最大容量,吞吐量測量可以得到網絡實際可提供的最大容量,數據流測量可以瞭解真實佔用的網絡容量。socket
本文介紹在評估網絡性能是否合理時,須要收集的數據及收集方式。涉及工具包括:ping, pathchar, bing, ttcp, netperf, iperf, netstat。tcp
帶寬測量:ide
ping工具
ping這一工具返回的時間,雖然一般被描述爲傳輸延時,其實是發送,傳輸,隊列延時之和。上一節中,咱們經過ping來粗略計算帶寬。這一過程可經過以下方式改進:首先計算鏈路近端的路徑行爲,而後計算遠端路徑,而後用二者差別來估算鏈路帶寬。性能
這一過程須要四次使用ping。首先,用兩個不一樣大小報文ping近端鏈路。減掉傳輸大報文中額外數據的傳輸時間之外,時間差可估算傳輸以及隊列延時。接下來,用一樣兩個報文ping遠端鏈路。再次用大報文和小報文的時間差來估算開銷。最後,用兩次差值的差值就是在最後一段鏈路中傳輸額外數據的時間值。這是一個往返時間,除以2就是額外數據在單向鏈路傳輸所用時間。帶寬則是額外數據總量除以單向傳輸時間。測試
下表是第二跳和第三跳的時間值,報文大小爲100和1100字節。spa
下表顯示了帶寬計算結果,用time difference除以2,用8000bit除以這個值,再乘1000(毫秒轉換爲秒)。結果是bps轉換爲Mbps。.net
pathchar
將上述過程自動話完成的一個工具是pathchar。pathchar在路徑的一端即能檢測各鏈路的帶寬。方法與以前描述的ping相相似,可是pathchar使用各類大小不一的報文。以下例所示:
bsd1# pathchar 165.166.0.2
pathchar to 165.166.0.2 (165.166.0.2)
mtu limited to 1500 bytes at local host
doing 32 probes at each of 45 sizes (64 to 1500 by 32)
0 205.153.60.247 (205.153.60.247)
| 4.3 Mb/s, 1.55 ms (5.88 ms)
1 cisco (205.153.60.2)
| 1.5 Mb/s, -144 us (13.5 ms)
2 165.166.36.17 (165.166.36.17)
| 10 Mb/s, 242 us (15.2 ms)
3 e0.r01.ia-gnwd.Infoave.Net (165.166.36.33)
| 1.2 Mb/s, 3.86 ms (32.7 ms)
4 165.166.125.165 (165.166.125.165)
| ?? b/s, 2.56 ms (37.7 ms)
5 165.166.125.106 (165.166.125.106)
| 45 Mb/s, 1.85 ms (41.6 ms), +q 3.20 ms (18.1 KB) *4
6 atm1-0-5.r01.ncchrl.infoave.net (165.166.126.1)
| 17 Mb/s, 0.94 ms (44.3 ms), +q 5.83 ms (12.1 KB) *2
7 h10-1-0.r01.ia-chrl.infoave.net (165.166.125.33)
| ?? b/s, 89 us (44.3 ms), 1% dropped
8 dns1.InfoAve.Net (165.166.0.2)
8 hops, rtt 21.9 ms (44.3 ms), bottleneck 1.2 Mb/s, pipe 10372 bytes
pathchar的運行過程當中,首先顯示的信息描述探測如何進行。從第三行輸出開始,可看到pathchar使用從64到1500字節的45中不一樣大小報文。對於每一跳使用32種不一樣報文組合進行測試。所以,共8跳生成了11,520個測試報文加上相應回覆信息。
顯示中給出了帶寬和延時。pathchar也包括了隊列延時信息(如本例中5和6)。如上述信息,pathchar並不老是能成功估算出帶寬(如鏈路4和7)或是延時(如鏈路1)。
在pathchar運行過程當中,每發送一個報文就啓動一次倒計時:顯示內容以下所示:
1: 31 288 0 3
1指示跳數而且隨着路徑上後續跳數而增長。下一個數字是倒計時值,給出這一鏈路剩餘的探測組數。第三個值是當前發送報文大小。第二個和第三個值改變都很是迅速。倒數第二個值是目前爲止丟棄報文數,最後一個是該鏈路的平均往返時間。
當一條的探測完成時,這一行內容被帶寬,傳輸延時,往返時間所取代。pathchar使用觀測到的最小延時來改進帶寬估算值。
bing
pathchar的一個替代工具是bing。pathchar估算的是一條路徑上各鏈路的帶寬,而bing用來測量點到點的帶寬。一般,若是你不知道路徑上的各條鏈路,須要首先執行traceroute命令。以後能夠運行bing來指定鏈路的近端和遠端。下例顯示了第三跳的帶寬:
bsd1# bing -e10 -c1 205.153.60.2 165.166.36.17
BING 205.153.60.2 (205.153.60.2) and 165.166.36.17 (165.166.36.17)
44 and 108 data bytes
1024 bits in 0.835ms: 1226347bps, 0.000815ms per bit
1024 bits in 0.671ms: 1526080bps, 0.000655ms per bit
1024 bits in 0.664ms: 1542169bps, 0.000648ms per bit
1024 bits in 0.658ms: 1556231bps, 0.000643ms per bit
1024 bits in 0.627ms: 1633174bps, 0.000612ms per bit
1024 bits in 0.682ms: 1501466bps, 0.000666ms per bit
1024 bits in 0.685ms: 1494891bps, 0.000669ms per bit
1024 bits in 0.605ms: 1692562bps, 0.000591ms per bit
1024 bits in 0.618ms: 1656958bps, 0.000604ms per bit
--- 205.153.60.2 statistics ---
bytes out in dup loss rtt (ms): min avg max
44 10 10 0% 3.385 3.421 3.551
108 10 10 0% 3.638 3.684 3.762
--- 165.166.36.17 statistics ---
bytes out in dup loss rtt (ms): min avg max
44 10 10 0% 3.926 3.986 4.050
108 10 10 0% 4.797 4.918 4.986
--- estimated link characteristics ---
estimated throughput 1656958bps
minimum delay per packet 0.116ms (192 bits)
average statistics (experimental) :
packet loss: small 0%, big 0%, total 0%
average throughput 1528358bps
average delay per packet 0.140ms (232 bits)
weighted average throughput 1528358bps
resetting after 10 samples.
輸出從地址和報文大小信息開始,以後是探測pair。接下來,返回往返時間和丟失數據。最後,返回一些吞吐量的估測值。
吞吐量測量:
吞吐量不夠的緣由不只在於硬件不足,還有多是網絡設計架構的問題。例如,廣播域設置得太大,則即便硬件夠磅也會形成問題。解決方案是重構網絡,在充分理解數據流模式後,將這類域隔離開或是分段。
吞吐量一般是測量大塊數據傳輸延時來完成的。一般須要在鏈路各端運行軟件。通常這類軟件運行在應用層,因此它不只測量網絡也測量了軟硬件。
一個比較簡單粗放的方式是用FTP。用FTP來傳輸一份文件而且看一下它report的數據。須要將結果轉換成比特率,例如,這是文件傳輸的最後一行:
1294522 bytes received in 1.44 secs (8.8e+02 Kbytes/sec)
將1,294,522字節乘8轉換成bit以後再除以時間,1.44秒。 結果爲7,191,789 bps。
這種方法的不足在於磁盤訪問時間可能對結果形成影響。若是須要提升精度則須要使用一些工具。
ttcp
運行這一程序首先須要在遠端設備運行server,一般用-r和-s選項。以後運行client,用-t和-s選項,以及主機名或地址。數據從client端發送至server端,測量性能以後,在各端返回結果,以後終止client端和server端。例如,server端以下所示:
bsd2# ttcp -r -s
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp
ttcp-r: socket
ttcp-r: accept from 205.153.60.247
ttcp-r: 16777216 bytes in 18.35 real seconds = 892.71 KB/sec +++
ttcp-r: 11483 I/O calls, msec/call = 1.64, calls/sec = 625.67
ttcp-r: 0.0user 0.9sys 0:18real 5% 15i+291d 176maxrss 0+2pf 11478+28csw
client端以下所示:
bsd1# ttcp -t -s 205.153.63.239
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001 tcp -> 205.153.63.239
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 18.34 real seconds = 893.26 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 9.17, calls/sec = 111.66
ttcp-t: 0.0user 0.5sys 0:18real 2% 16i+305d 176maxrss 0+2pf 3397+7csw
該程序報告中顯示了信息傳輸總量,標識了鏈接的創建,而且給出告終果,包括raw data,throughput,I/O call信息,執行時間。最有用的信息應該是transfer rate,892.71 KB/sec (or 893.26 KB/sec)。
這一數據反映了數據的傳輸速率,而不是鏈路的容量。將這一數據轉化成帶寬多是有問題的,由於實際上傳輸了比這一值更多的比特數。這一程序顯示18.35秒傳送了16,777,216字節,可是這僅僅是數據。以太網報文封裝還包括TCP,IP,以太網報文頭,估算容量時,須要把這些值加上去。
吞吐量低一般意味着擁塞,但也並不老是如此。吞吐量也會取決於配置問題,如鏈接的TCP窗口大小。若是窗口大小不足,會嚴重影響到性能。
(未完待續)