Netperf概況
Netperf是一種網路性能的測量工具，主要針對基於TCP或UDP的傳輸。Netperf根據套用的不同，可以進行不同模式的網路性能測試，即批量數據傳輸（bulk data transfer）模式和請求/應答（request/reponse）模式。Netperf測試結果所反映的是一個系統能夠以多快的速度向另外一個系統傳送數據，以及另外一個系統能夠以多塊的速度接收數據。Netperf工具以client/server方式工作。server端是netserver，用來偵聽來自client端的連線，client端是netperf，用來向server發起網路測試。在client與server之間，首先建立一個控制連線，傳遞有關測試配置的信息，以及測試的結果；在控制連線建立並傳遞了測試配置信息以後，client與server之間會再建立一個測試連線，用來來回傳遞著特殊的流量模式，以測試網路的性能。
行參數
在unix系統中，可以直接運行可執行程式來啟動netserver，也可以讓inetd或xinetd來自動啟動netserver。
當netserver在server端啟動以後，就可以在client端運行netperf來測試網路的性能。netperf通過命令行參數來控制測試的類型和具體的測試選項。根據作用範圍的不同，netperf的命令行參數可以分為兩大類：全局命令行參數、測試相關的局部參數，兩者之間使用--分隔：
| netperf [global options]-- [test-specific options] |
這裡我們只解釋那些常用的命令行參數，其它的參數讀者可以查詢netperf的man手冊。
-H host ：指定遠端運行netserver的server IP位址。
-l testlen：指定測試的時間長度（秒）
-t testname：指定進行的測試類型，包括TCP_STREAM，UDP_STREAM，TCP_RR，TCP_CRR，UDP_RR，在下文中分別對它們說明。
在後面的測試中，netserver運行在192.168.0.28，server與client通過區域網路連線（100M Hub）。
Netperf測試網路性能
測試批量（bulk）網路流量的性能批量數據傳輸典型的例子有ftp和其它類似的網路套用（即一次傳輸整個檔案）。根據使用傳輸協定的不同，批量數據傳輸又分為TCP批量傳輸和UDP批量傳輸。1． TCP_STREAMNetperf預設情況下進行TCP批量傳輸，即-t TCP_STREAM。測試過程中，netperf向netserver傳送批量的TCP數據分組，以確定數據傳輸過程中的吞吐量：./netperf -H 192.168.0.28 -l 60TCP STREAM TEST to 192.168.0.28Recv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec 87380 16384 16384 60.00 88.00從netperf的結果輸出中，我們可以知道以下的一些信息：1） 遠端系統（即server）使用大小為87380位元組的socket接收緩衝2） 本地系統（即client）使用大小為16384位元組的socket傳送緩衝3） 向遠端系統傳送的測試分組大小為16384位元組4） 測試經歷的時間為60秒5） 吞吐量的測試結果為88Mbits/秒在預設情況下，netperf向傳送的測試分組大小設定為本地系統所使用的socket傳送緩衝大小。TCP_STREAM方式下與測試相關的局部參數如下表所示：參數 說明-s size 設定本地系統的socket傳送與接收緩衝大小-S size 設定遠端系統的socket傳送與接收緩衝大小-m size 設定本地系統傳送測試分組的大小-M size 設定遠端系統接收測試分組的大小-D 對本地與遠端系統的socket設定TCP_NODELAY選項通過修改以上的參數，並觀察結果的變化，我們可以確定是什麼因素影響了連線的吞吐量。例如，如果懷疑路由器由於缺乏足夠的緩衝區空間，使得轉發大的分組時存在問題，就可以增加測試分組（-m）的大小，以觀察吞吐量的變化：./netperf -H 192.168.0.28 -l 60 -- -m 2048TCP STREAM TEST to 192.168.0.28Recv Send SendSocket Socket Message ElapsedSize Size Size Time Throughputbytes bytes bytes secs. 10^6bits/sec 87380 16384 2048 60.00 87.62在這裡，測試分組的大小減少到2048位元組，而吞吐量卻沒有很大的變化（與前面例子中測試分組大小為16K位元組相比）。相反，如果吞吐量有了較大的提升，則說明在網路中間的路由器確實存在緩衝區的問題。2． UDP_STREAMUDP_STREAM用來測試進行UDP批量傳輸時的網路性能。需要特別注意的是，此時測試分組的大小不得大於socket的傳送與接收緩衝大小，否則netperf會報出錯提示：./netperf -t UDP_STREAM -H 192.168.0.28 -l 60UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28udp_send: data send error: Message too long為了避免這樣的情況，可以通過命令行參數限定測試分組的大小，或者增加socket的傳送/接收緩衝大小。UDP_STREAM方式使用與TCP_STREAM方式相同的局部命令行參數，因此，這裡可以使用-m來修改測試中使用分組的大小：./netperf -t UDP_STREAM -H 192.168.0.28 -- -m 1024UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28Socket Message Elapsed MessagesSize Size Time Okay Errors Throughputbytes bytes secs # # 10^6bits/sec 65535 1024 9.99 114127 0 93.55 65535 9.99 114122 93.54UDP_STREAM方式的結果中有兩行測試數據，第一行顯示的是本地系統的傳送統計，這裡的吞吐量表示netperf向本地socket傳送分組的能力。但是，我們知道，UDP是不可靠的傳輸協定，傳送出去的分組數量不一定等於接收到的分組數量。第二行顯示的就是遠端系統接收的情況，由於client與server直接連線在一起，而且網路中沒有其它的流量，所以本地系統傳送過去的分組幾乎都被遠端系統正確的接收了，遠端系統的吞吐量也幾乎等於本地系統的傳送吞吐量。但是，在實際環境中，一般遠端系統的socket緩衝大小不同於本地系統的socket緩衝區大小，而且由於UDP協定的不可靠性，遠端系統的接收吞吐量要遠遠小於傳送出去的吞吐量。測試請求/應答（request/response）網路流量的性能另一類常見的網路流量類型是套用在client/server結構中的request/response模式。在每次交易（transaction）中，client向server發出小的查詢分組，server接收到請求，經處理後返回大的結果數據。1． TCP_RRTCP_RR方式的測試對象是多次TCP request和response的交易過程，但是它們發生在同一個TCP連線中，這種模式常常出現在資料庫套用中。資料庫的client程式與server程式建立一個TCP連線以後，就在這個連線中傳送資料庫的多次交易過程。./netperf -t TCP_RR -H 192.168.0.28TCP REQUEST/RESPONSE TEST to 192.168.0.28Local /RemoteSocket Size Request Resp. Elapsed Trans.Send Recv Size Size Time Ratebytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 9502.7316384 87380Netperf輸出的結果也是由兩行組成。第一行顯示本地系統的情況，第二行顯示的是遠端系統的信息。平均的交易率（transaction rate）為9502.73次/秒。注意到這裡每次交易中的request和response分組的大小都為1個位元組，不具有很大的實際意義。用戶可以通過測試相關的參數來改變request和response分組的大小，TCP_RR方式下的參數如下表所示：參數 說明-r req,resp 設定request和reponse分組的大小-s size 設定本地系統的socket傳送與接收緩衝大小-S size 設定遠端系統的socket傳送與接收緩衝大小-D 對本地與遠端系統的socket設定TCP_NODELAY選項通過使用-r參數，我們可以進行更有實際意義的測試：./netperf -t TCP_RR -H 192.168.0.28 -- -r 32,1024TCP REQUEST/RESPONSE TEST to 192.168.0.28Local /RemoteSocket Size Request Resp. Elapsed Trans.Send Recv Size Size Time Ratebytes Bytes bytes bytes secs. per sec 16384 87380 32 1024 10.00 4945.9716384 87380從結果中可以看出，由於request/reponse分組的大小增加了，導致了交易率明顯的下降。 註：相對於實際的系統，這裡交易率的計算沒有充分考慮到交易過程中的應用程式處理時延，因此結果往往會高於實際情況。2． TCP_CRR與TCP_RR不同，TCP_CRR為每次交易建立一個新的TCP連線。最典型的套用就是HTTP，每次HTTP交易是在一條單獨的TCP連線中進行的。因此，由於需要不停地建立新的TCP連線，並且在交易結束後拆除TCP連線，交易率一定會受到很大的影響。./netperf -t TCP_CRR -H 192.168.0.28 TCP Connect/Request/Response TEST to 192.168.0.28Local /RemoteSocket Size Request Resp. Elapsed Trans.Send Recv Size Size Time Ratebytes Bytes bytes bytes secs. per sec 131070 131070 1 1 9.99 2662.2016384 87380即使是使用一個位元組的request/response分組，交易率也明顯的降低了，只有2662.20次/秒。TCP_CRR使用與TCP_RR相同的局部參數。3． UDP_RRUDP_RR方式使用UDP分組進行request/response的交易過程。由於沒有TCP連線所帶來的負擔，所以我們推測交易率一定會有相應的提升。./netperf -t UDP_RR -H 192.168.0.28 UDP REQUEST/RESPONSE TEST to 192.168.0.28Local /RemoteSocket Size Request Resp. Elapsed Trans.Send Recv Size Size Time Ratebytes Bytes bytes bytes secs. per sec 65535 65535 1 1 9.99 10141.1665535 65535結果證實了我們的推測，交易率為10141.16次/秒，高過TCP_RR的數值。不過，如果出現了相反的結果，即交易率反而降低了，也不需要擔心，因為這說明了在網路中，路由器或其它的網路設備對UDP採用了與TCP不同的緩衝區空間和處理技術。結束除了netperf以外，還有很多其它的網路性能測試工具，如dbs, iperf, pathrate, nettest, netlogger, tcptrace, ntop等。這些工具有其各自的特色和不同的側重點，我們可以根據具體的套用環境，有選擇的使用它們，這樣就可以使這些工具發揮出最大的功效。雖然都是開放原始碼的軟體，但是這些工具的功能與商業的網路測試工具同樣強大，而且也得到了廣泛的套用，熟悉這些工具對我們的實際工作一定會有很大的幫助。
