在構建或管理一個網絡系統時，我們更多的是關心網絡的可用性，即網絡是否連通，而對於其整體的性能往往考慮不多。
或者即使考慮到性能的問題，但是卻發現沒有合適的手段去測試網絡的性能。 當開發出一個網絡應用程序后。
我們會發現，在實際的網絡環境使用中。
網絡應用程序的使用效果不 是很理想，問題可能出現在程序的開發上面，也有可能由於實際的網絡環境中存在着瓶頸。面對這種問題。
程序員一般會一籌莫展，原因就在於不掌握一些網絡性能測量的工具。 在本文中。
首先介紹網絡性能測量的一些基本概念和方法，然后結合 netperf 工具的使用，具體的討論如何測試不同情況下的網絡性能。 網絡性能測試概述 測量網絡性能的五項指標是： 可用性（ilbility） 響應時間（repone tie） 網絡利用率（network utilition） 網絡吞吐量（network trougput） 網絡帶寬容量（network bndwidt cpcity）1． 可用性 測試網絡性能的第一步是確定網絡是否正常工作。
最簡單的方法是使用 ping 命令。通過向遠端的機器發送 icp eco requet，並等待接收 icp eco reply 來判斷遙端的機器是否連通。
網絡是否正常工作。 Ping 命令有非常豐富的命令選項，比如 -c 可以指定發送 eco requet 的個數。
- 可以指定每次發送的 ping 包大小。 網絡設備內部一般有多個緩沖池。
不同的緩沖池使用不同的緩沖區大小，分別用來處理不同大小的分組（pcket）。例如交換機中通常具有三種類型的 包緩沖：一類針對小的分組。
一類針對中等大小的分組。
還有一類針對大的分組。為了測試這樣的網絡設備。
測試工具必須要具有發送不同大小分組的能力。 Ping 命令的 - 就可以使用在這種場合。2． 響應時間 Ping 命令的 eco requet/reply 一次來回所花費時間就是響應時間。有很多因素會影響到響應時間。
如網段的負荷。
網絡主機的負荷。
廣播風暴。
工作不正常的網絡設備等等。 在網絡工作正常時。
記錄下正常的響應時間。當用戶抱怨網絡的反應時間慢時，就可以將現在的響應時間與正常的響應時間對比，如果兩者差值的波動很大，就能說明網絡設備存在故障。 字串93． 網絡利用率 字串9網絡利用率是指網絡被使用的時間占總時間（即被使用的時間+空閑的時間）的比例。比如，Eternet 雖然是共享的。
但同時卻只能有一個報文在傳輸。因此在任一時刻。
Eternet 或者是 100% 的利用率。
或者是 0% 的利用率。計算一個網段的網絡利用率相對比較容易，但是確定一個網絡的利用率就比較復雜。因此，網絡測試工具一般使用網絡吞吐量和網絡帶寬容量來確定網絡中兩個節點之間的性能。4． 網絡吞吐量網絡吞吐量是指在某個時刻。
在網絡中的兩個節點之間。
提供給網絡應用的剩余帶寬。 網絡吞吐量可以幫組尋找網絡路徑中的瓶頸。比如，即使 client 和 erer 都被分別連接到各自的 100M Eternet 上。
但是如果這兩個 100M 的Eternet 被 10M 的 Eternet 連接起來。
那么 10M 的 Eternet 就是網絡的瓶頸。網絡吞吐量非常依賴於當前的網絡負載情況。因此。
為了得到正確的網絡吞吐量，最好在不同時間（一天中的不同時刻，或者一周中不同的天）分別進行測試。
只有這樣才能得到對網絡吞吐量的全面熟悉。 有些網絡應用程序在開發過程的測試中能夠正常運行。
但是到實際的網絡環境中卻無法正常工作（由於沒有足夠的網絡吞吐量）。這是因為測試只是在空閑的網絡環 境中。
沒有考慮到實際的網絡環境中還存在着其它的各種網絡流量。所以。
網絡吞吐量定義為剩余帶寬是有實際意義的。5． 網絡帶寬容量 與網絡吞吐量不同，網絡帶寬容量指的是在網絡的兩個節點之間的最大可用帶寬。這是由組成網絡的設備的能力所決定的。測試網絡帶寬容量有兩個困難之處：在網絡存在其它網絡流量的時候，如何得知網絡的最大可用帶寬；在測試過程中，如何對現有的網絡流量不造成影響。網絡測試工具一般采用 pcket pir 和 pcket trin 技術來克服這樣的困難。當確定了網絡性能的測試指標以后。
就需要使用網絡測試工具收集相應的性能數據，分別有三種從網絡獲取數據的方式： 1． 通過np協議直接到網絡設備中獲取，如net-np工具2． 偵聽相關的網絡性能數據。
典型的工具是tcpdup 3． 自行產生相應的測試數據。
如本文中使用的netperf工具Netperf是一種網絡性能的測量工具，主要針對基於TCP 或UDP的傳輸。Netperf根據應用的不同，可以進行不同模式的網絡性能測試。
即批量數據傳輸（bulk dt trnfer）模式和請求/應答（requet/repone）模式。Netperf測試結果所反映的是一個系統能夠以多快的速度向另外一個系統 發送數據。
以及另外一個系統能夠以多塊的速度接收數據。 Netperf工具以client/erer方式工作。erer端是neterer。
用來偵聽來自client端的連接。
client 端是netperf。
用來向erer發起網絡測試。在client與erer之間，首先建立一個控制連接，傳遞有關測試配置的信息，以及測試的結 果；在控制連接建立並傳遞了測試配置信息以后，client與erer之間會再建立一個測試連接，用來來回傳遞着特殊的流量模式。
以測試網絡的性能。 由於TCP協議能夠提供端到端的可靠傳輸，因此被大量的網絡應用程序使用。但是。
可靠性的建立是要付出代價的。TCP協議保證可靠性的措施。
如建立並維護連接、控制數據有序的傳遞等都會消耗一定的網絡帶寬。 Netperf可以模擬三種不同的TCP流量模式： 1） 單個TCP連接。
批量（bulk）傳輸大量數據 2） 單個TCP連接。
client請求/erer應答的交易（trnction）方式 3） 多個TCP連接。
每個連接中一對請求/應答的交易方式 UDP沒有建立連接的負擔。
但是UDP不能保證傳輸的可靠性。
所以使用UDP的應用程序需要自行跟蹤每個發出的分組。
並重發丟失的分組。Netperf可以模擬兩種UDP的流量模式： 1） 從client到erer的單向批量傳輸2） 請求/應答的交易方式 由於UDP傳輸的不可靠性。
在使用netperf時要確保發送的緩沖區大小不大於接收緩沖區大小，否則數據會丟失，netperf將給出錯誤的結果。因此。
對於接收到分組的統計不一定准確，需要結合發送分組的統計綜合得出結論。 在unix系統中。
可以直接運行可執行程序來啟動neterer，也可以讓inetd或xinetd來自動啟動neterer。 當neterer在erer端啟動以后。
就可以在client端運行netperf來測試網絡的性能。netperf通過命令行參數來控制 測試的類型和詳細的測試選項。根據作用范圍的不同，netperf的命令行參數可以分為兩大類：全局命令行參數、測試相關的局部參數。
兩者之間使用--分 隔： netperf [globl option]-- [tet-pecific option] 這里我們只解釋那些常用的命令行參數，其它的參數讀者可以查詢netperf的n手冊。-H ot ：指定遠端運行neterer的erer IP地址。 -l tetlen：指定測試的時間長度（秒）-t tetne：指定入行的測試類型。
包括TCP_STREAM，UDP_STREAM。
TCP_RR，TCP_CRR，UDP_RR。
在下文中分別對它們說明。在后面的測試中，neterer運行在192.168.0.28，erer與client通過局域網連接（100M Hub）。 字串3 測試批量（bulk）網絡流量的性能批量數據傳輸典型的例子有ftp和其它類似的網絡應用（即一次傳輸整個文件）。根據使用傳輸協議的不同，批量數據傳輸又分為TCP批量傳輸和UDP批量傳輸。 1． TCP_STREAM Netperf缺省情況下進行TCP批量傳輸，即-t TCP_STREAM。測試過程中，netperf向neterer發送批量的TCP數據分組，以確定數據傳輸過程中的吞吐量： ./netperf -H 192.168.0.28 -l 60TCP STREAM TEST to 192.168.0.28Rec Send SendSocket Socket Mege ElpedSie Sie Sie Tie Trougputbyte byte byte ec. 10^6bit/ec87380 16384 16384 60.00 88.00 從netperf的結果輸出中，我們可以知道以下的一些信息： 1） 遙端系統（即erer）使用大小為87380字節的ocket接收緩沖2） 本地系統（即client）使用大小為16384字節的ocket發送緩沖 3） 向遠端系統發送的測試分組大小為16384字節4） 測試經歷的時間為60秒5） 吞吐量的測試結果為88Mbit/秒 在缺省情況下。
netperf向發送的測試分組大小設置為本地系統所使用的ocket發送緩沖大小。 TCP_STREAM方式下與測試相關的局部參數如下表所示： 參數 說明 - ie設置本地系統的ocket發送與接收緩沖大小-S ie 設置遙端系統的ocket發送與接收緩沖大小- ie 設置本地系統發送測試分組的大小-M ie設置遙端系統接收測試分組的大小-D對本地與遙端系統的ocket設置TCP_NODELAY選項 通過修改以上的參數。
並看察結果的變化。
我們可以確定是什么因素影響了連接的吞吐量。例如，如果懷疑路由器由於缺乏足夠的緩沖區空間，使得轉發大的分組時存在問題。
就可以增加測試分組（-）的大小，以觀察吞吐量的變化：./netperf -H 192.168.0.28 -l 60 -- - 2048 TCP STREAM TEST to 192.168.0.28 Rec Send SendSocket Socket Mege Elped Sie Sie Sie Tie Trougputbyte byte byte ec. 10^6bit/ec87380 16384 2048 60.00 87.62 在這里。
測試分組的大小減少到2048字節。
而吞吐量卻沒有很大的變化（與前面例子中測試分組大小為16K字節相比）。相反。
如果吞吐量有了較大的提升，則說明在網絡中間的路由器確實存在緩沖區的問題。2． UDP_STREAMUDP_STREAM用來測試進行UDP批量傳輸時的網絡性能。需要特別注意的是，此時測試分組的大小不得大於ocket的發送與接收緩沖大小。
否則netperf會報出錯提示： ./netperf -t UDP_STREAM -H 192.168.0.28 -l 60 UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28 udp_end: dt end error: Mege too long為了避免這樣的情況。
可以通過命令行參數限定測試分組的大小。
或者增加ocket的發送/接收緩沖大小。UDP_STREAM方式使用與TCP_STREAM方式相同的局部命令行參數。
因此。
這里可以使用-來修改測試中使用分組的大小：./netperf -t UDP_STREAM -H 192.168.0.28 -- - 1024UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28Socket Mege Elped MegeSie Sie Tie Oky Error Trougput byte byte ec # # 10^6bit/ec65535 1024 9.99 114127 0 93.55 65535 9.99 114122 93.54UDP_STREAM方式的結果中有兩行測試數據，第一行顯示的是本地系統的發送統計。
這里的吞吐量表示netperf向本地ocket發送分組的能力。但是。
我們知道。
UDP是不可靠的傳輸協議，發送出去的分組數量不一定等於接收到的分組數量。 字串1第二行顯示的就是遙端系統接收的情況，由於client與erer直接連接在一起。
而且網絡中沒有其它的流量。
所以本地系統發送過去的分組幾乎 都被遙端系統正確的接收了，遙端系統的吞吐量也幾乎等於本地系統的發送吞吐量。但是。
在實際環境中。
一般遙端系統的ocket緩沖大小不同於本地系統的 ocket緩沖區大小，而且由於UDP協議的不可靠性。
遙端系統的接收吞吐量要遙遙小於發送出去的吞吐量。另一類常見的網絡流量類型是應用在client/erer結構中的requet/repone模式。在每次交易（trnction）中。
client向erer發出小的查詢分組，erer接收到請求。
經處理后返回大的結果數據。1． TCP_RR TCP_RR方式的測試對象是多次TCP requet和repone的交易過程。
但是它們發生在同一個TCP連接中，這種模式常常出現在數據庫應用中。數據庫的client程序與erer程序建立一個TCP連接以后，就在這個連接中傳送數據庫的多次交易過程。./netperf -t TCP_RR -H 192.168.0.28 TCP REQUEST/RESPONSE TEST to 192.168.0.28 Locl /Reote Socket Sie Requet Rep. Elped Trn. Send Rec Sie Sie Tie Rtebyte Byte byte byte ec. per ec16384 87380 1 1 10.00 9502.7316384 87380 Netperf輸出的結果也是由兩行組成。第一行顯示本地系統的情況，第二行顯示的是遙端系統的信息。平均的交易率（trnction rte）為9502.73次/秒。注意到這里每次交易中的requet和repone分組的大小都為1個字節。
不具有很大的實際意義。用戶可以通 過測試相關的參數來改變requet和repone分組的大小。
TCP_RR方式下的參數如下表所示： 參數說明 -r req,rep 設置requet和repone分組的大小 - ie 設置本地系統的ocket發送與接收緩沖大小-S ie 設置遙端系統的ocket發送與接收緩沖大小-D對本地與遠端系統的ocket設置TCP_NODELAY選項通過使用-r參數。
我們可以入行更有實際意義的測試：./netperf -t TCP_RR -H 192.168.0.28 -- -r 32,1024TCP REQUEST/RESPONSE TEST to 192.168.0.28 Locl /ReoteSocket Sie Requet Rep. Elped Trn.Send Rec Sie Sie Tie Rte byte Byte byte byte ec. per ec16384 87380 32 1024 10.00 4945.9716384 87380 從結果中可以觀出，由於requet/repone分組的大小增加了，導致了交易率明顯的下降。注：相對於實際的系統。
這里交易率的計算沒有充分考慮到交易過程中的應用程序處理時延。
因此結果往往會高於實際情況。 2． TCP_CRR 與TCP_RR不同，TCP_CRR為每次交易建立一個新的TCP連接。最典型的應用就是HTTP。
每次HTTP交易是在一條單獨的TCP連接中入行的。因此。
由於需要不停地建立新的TCP連接。
並且在交易結束后拆除TCP連接，交易率一定會受到很大的影響。 ./netperf -t TCP_CRR -H 192.168.0.28 TCP Connect/Requet/Repone TEST to 192.168.0.28 Locl /Reote Socket Sie Requet Rep. Elped Trn.Send Rec Sie Sie Tie Rtebyte Byte byte byte ec. per ec131070 131070 1 1 9.99 2662.20 16384 87380 即使是使用一個字節的requet/repone分組。
交易率也明顯的降低了，只有2662.20次/秒。TCP_CRR使用與TCP_RR相同的局部參數。 3． UDP_RR UDP_RR方式使用UDP分組進行requet/repone的交易過程。由於沒有TCP連接所帶來的負擔。
所以我們推測交易率一定會有相應的提升。 ./netperf -t UDP_RR -H 192.168.0.28 UDP REQUEST/RESPONSE TEST to 192.168.0.28Locl /Reote Socket Sie Requet Rep. Elped Trn.Send Rec Sie Sie Tie Rtebyte Byte byte byte ec. per ec65535 65535 1 1 9.99 10141.1665535 65535結果證明了我們的推測。
交易率為10141.16次/秒。
高過TCP_RR的數值。不過。
如果出現了相反的結果。
即交易率反而降低了。
也不需要擔心。
因為這說明了在網絡中，路由器或其它的網絡設備對UDP采用了與TCP不同的緩沖區空間和處理技術。 除了netperf以外。
還有很多其它的網絡性能測試工具。
如db, iperf, ptrte, nettet, netlogger, tcptrce, ntop等。這些工具有其各自的特色和不同的側重點，我們可以根據具體的應用環境，有選擇的使用它們，這樣就可以使這些工具發揮出最大的功效。雖然都是開 放源代碼的軟件。
但是這些工具的功能與商業的網絡測試工具同樣強大。
而且也得到了廣泛的應用。
認識這些工具對我們的實際工作一定會有很大的幫助。 Network Perfornce Open Source Toolkit, Ricrd Blu, Wiley Publiing, Inc. netperf webite,ttp://www.netperf.org
轉自：http://blog.csdn.net/adrian169/article/details/9152897/