介紹

網路路徑效能檢測主要包括三方面的內容：頻寬測量能夠獲知網路的硬體特性，如網路的最大容量，吞吐量測量能夠獲得網路實際可提供的最大容量，資料流測量能夠了解真實佔用的網路容量。

本文介紹在評估網路效能是否合理時，需要收集的資料及收集方式。涉及工具包括：ping, pathchar, bing, ttcp, netperf, iperf, netstat。

更多資訊

頻寬測量:

ping

ping這一工具返回的時間，雖然通常被描述為傳輸延時，實際上是傳送，傳輸，佇列延時之和。上一節中，我們通過ping來粗略計算頻寬。這一過程可通過如下方式改進：首先計算鏈路近端的路徑行為，然後計算遠端路徑，然後用兩者差異來估算鏈路頻寬。

這一過程需要四次使用ping。首先，用兩個不同大小報文ping近端鏈路。減掉傳輸大報文中額外資料的傳輸時間以外，時間差可估算傳輸以及佇列延時。接下來，用同樣兩個報文ping遠端鏈路。再次用大報文和小報文的時間差來估算開銷。最後，用兩次差值的差值就是在最後一段鏈路中傳輸額外資料的時間值。這是一個往返時間，除以2就是額外資料在單向鏈路傳輸所用時間。頻寬則是額外資料總量除以單向傳輸時間。

下表是第二跳和第三跳的時間值，報文大小為100和1100位元組。

下表顯示了頻寬計算結果，用time difference除以2，用8000bit除以這個值，再乘1000（毫秒轉換為秒）。結果是bps轉換為Mbps。

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視窗大小。如果視窗大小不足，會嚴重影響到效能。

（未完待續）

參考

Network Troubleshooting Tools