TCP/UDP網路效能測試工具 – Netperf (zz) ..網路測試載入器

http://www.qc333.com/thread-3853-1-1.html

在構建或管理一個網路系統時，我們更多的是關心網路的可用性，即網路是否連通，而對於其整體的效能往往考慮不多。

       或者即使考慮到效能的問題，但是卻發現沒有合適的手段去測試網路的效能。 當開發出一個網路應用程式後。
       我們會發現，在實際的網路環境使用中。
       網路應用程式的使用效果不 是很理想，問題可能出現在程式的開發上面，也有可能由於實際的網路環境中存在著瓶頸。面對這種問題。
       程式員一般會一籌莫展，原因就在於不掌握一些網路效能測量的工具。 在本文中。
       首先介紹網路效能測量的一些基本概念和方法，然後結合 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