在構建或管理一個網絡系統時，我們更多的是關心網絡的可用性，即網絡是否連通，而對於其整體的性能往往考慮不多，或者即使考慮到性能的問題，但是卻發現沒有合適的手段去測試網絡的性能。
當開發出一個網絡應用程序後，我們會發現，在實際的網絡環境使用中，網絡應用程序的使用效果不是很理想，問題可能出現在程序的開發上面，也有可能由於實際的網絡環境中存在着瓶頸。面對這種問題，程序員一般會一籌莫展，原因就在於不掌握一些網絡性能測量的工具。
在本文中，首先介紹網絡性能測量的一些基本概念和方法，然後結合 netperf 工具的使用，具體的討論如何測試不同情況下的網絡性能。
測量網絡性能的五項指標是：
可用性（availability）
響應時間（response time）
網絡利用率（network utilization）
網絡吞吐量（network throughput）
網絡帶寬容量（network bandwidth capacity）
1．可用性
測試網絡性能的第一步是確定網絡是否正常工作，最簡單的方法是使用 ping 命令。通過向遠端的機器發送 icmp echo request，並等待接收 icmp echo reply 來判斷遠端的機器是否連通，網絡是否正常工作。
Ping 命令有非常豐富的命令選項，比如 -c 可以指定發送 echo request 的個數，-s 可以指定每次發送的 ping 包大小。
網絡設備內部一般有多個緩衝池，不同的緩衝池使用不同的緩衝區大小，分別用來處理不同大小的分組（packet）。例如交換機中通常具有三種類型的包緩衝：一類針對小的分組，一類針對中等大小的分組，還有一類針對大的分組。爲了測試這樣的網絡設備，測試工具必須要具有發送不同大小分組的能力。Ping 命令的 -s 就可以使用在這種場合。
2．響應時間
Ping 命令的 echo request/reply 一次往返所花費時間就是響應時間。有很多因素會影響到響應時間，如網段的負荷，網絡主機的負荷，廣播風暴，工作不正常的網絡設備等等。
在網絡工作正常時，記錄下正常的響應時間。當用戶抱怨網絡的反應時間慢時，就可以將現在的響應時間與正常的響應時間對比，如果兩者差值的波動很大，就能說明網絡設備存在故障。
3．網絡利用率
網絡利用率是指網絡被使用的時間佔總時間（即被使用的時間+空閒的時間）的比例。比如，Ethernet 雖然是共享的，但同時卻只能有一個報文在傳輸。因此在任一時刻，Ethernet 或者是 100% 的利用率，或者是 0% 的利用率。
計算一個網段的網絡利用率相對比較容易，但是確定一個網絡的利用率就比較複雜。因此，網絡測試工具一般使用網絡吞吐量和網絡帶寬容量來確定網絡中兩個節點之間的性能。
4．網絡吞吐量
網絡吞吐量是指在某個時刻，在網絡中的兩個節點之間，提供給網絡應用的剩餘帶寬。
網絡吞吐量可以幫組尋找網絡路徑中的瓶頸。比如，即使 client 和 server 都被分別連接到各自的 100M Ethernet 上，但是如果這兩個 100M 的Ethernet 被 10M 的 Ethernet 連接起來，那麼 10M 的 Ethernet 就是網絡的瓶頸。
網絡吞吐量非常依賴於當前的網絡負載情況。因此，爲了得到正確的網絡吞吐量，最好在不同時間（一天中的不同時刻，或者一週中不同的天）分別進行測試，只有這樣才能得到對網絡吞吐量的全面認識。
有些網絡應用程序在開發過程的測試中能夠正常運行，但是到實際的網絡環境中卻無法正常工作（由於沒有足夠的網絡吞吐量）。這是因爲測試只是在空閒的網絡環境中，沒有考慮到實際的網絡環境中還存在着其它的各種網絡流量。所以，網絡吞吐量定義爲剩餘帶寬是有實際意義的。
5．網絡帶寬容量
與網絡吞吐量不同，網絡帶寬容量指的是在網絡的兩個節點之間的最大可用帶寬。這是由組成網絡的設備的能力所決定的。
測試網絡帶寬容量有兩個困難之處：在網絡存在其它網絡流量的時候，如何得知網絡的最大可用帶寬；在測試過程中，如何對現有的網絡流量不造成影響。網絡測試工具一般採用 packet pairs 和 packet trains 技術來克服這樣的困難。
當確定了網絡性能的測試指標以後，就需要使用網絡測試工具收集相應的性能數據，分別有三種從網絡獲取數據的方式：
1．通過snmp協議直接到網絡設備中獲取，如net-snmp工具
2．偵聽相關的網絡性能數據，典型的工具是tcpdump
3．自行產生相應的測試數據，如本文中使用的netperf工具
Netperf是一種網絡性能的測量工具，主要針對基於TCP或UDP的傳輸。Netperf根據應用的不同，可以進行不同模式的網絡性能測試，即批量數據傳輸（bulk data transfer）模式和請求/應答（request/reponse）模式。Netperf測試結果所反映的是一個系統能夠以多快的速度向另外一個系統發送數據，以及另外一個系統能夠以多塊的速度接收數據。
Netperf工具以client/server方式工作。server端是netserver，用來偵聽來自client端的連接，client端是netperf，用來向server發起網絡測試。在client與server之間，首先建立一個控制連接，傳遞有關測試配置的信息，以及測試的結果；在控制連接建立並傳遞了測試配置信息以後，client與server之間會再建立一個測試連接，用來來回傳遞着特殊的流量模式，以測試網絡的性能。
由於TCP協議能夠提供端到端的可靠傳輸，因此被大量的網絡應用程序使用。但是，可靠性的建立是要付出代價的。TCP協議保證可靠性的措施，如建立並維護連接、控制數據有序的傳遞等都會消耗一定的網絡帶寬。
Netperf可以模擬三種不同的TCP流量模式：
1）單個TCP連接，批量（bulk）傳輸大量數據
2）單個TCP連接，client請求/server應答的交易（transaction）方式
3）多個TCP連接，每個連接中一對請求/應答的交易方式
UDP沒有建立連接的負擔，但是UDP不能保證傳輸的可靠性，所以使用UDP的應用程序需要自行跟蹤每個發出的分組，並重發丟失的分組。
Netperf可以模擬兩種UDP的流量模式：
1）從client到server的單向批量傳輸
2）請求/應答的交易方式
由於UDP傳輸的不可靠性，在使用netperf時要確保發送的緩衝區大小不大於接收緩衝區大小，否則數據會丟失，netperf將給出錯誤的結果。因此，對於接收到分組的統計不一定準確，需要結合發送分組的統計綜合得出結論。
在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）。
測試批量（bulk）網絡流量的性能
批量數據傳輸典型的例子有ftp和其它類似的網絡應用（即一次傳輸整個文件）。根據使用傳輸協議的不同，批量數據傳輸又分爲TCP批量傳輸和UDP批量傳輸。
1．TCP_STREAM
Netperf缺省情況下進行TCP批量傳輸，即-t TCP_STREAM。測試過程中，netperf向netserver發送批量的TCP數據分組，以確定數據傳輸過程中的吞吐量：
./netperf -H 192.168.0.28 -l 60 TCP STREAM TEST to 192.168.0.28 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes 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 2048 TCP STREAM TEST to 192.168.0.28 Recv Send Send Socket Socket Message Elapsed Size Size Size Time Throughput bytes bytes bytes secs. 10^6bits/sec 87380 16384 2048 60.00 87.62 |
在這裏，測試分組的大小減少到2048字節，而吞吐量卻沒有很大的變化（與前面例子中測試分組大小爲16K字節相比）。相反，如果吞吐量有了較大的提升，則說明在網絡中間的路由器確實存在緩衝區的問題。
2．UDP_STREAM
UDP_STREAM用來測試進行UDP批量傳輸時的網絡性能。需要特別注意的是，此時測試分組的大小不得大於socket的發送與接收緩衝大小，否則netperf會報出錯提示：
./netperf -t UDP_STREAM -H 192.168.0.28 -l 60 UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28 udp_send: data send error: Message too long |
爲了避免這樣的情況，可以通過命令行參數限定測試分組的大小，或者增加socket的發送/接收緩衝大小。UDP_STREAM方式使用與TCP_STREAM方式相同的局部命令行參數，因此，這裏可以使用-m來修改測試中使用分組的大小：
./netperf -t UDP_STREAM -H 192.168.0.28 -- -m 1024 UDP UNIDIRECTIONAL SEND TEST to 192.168.0.28 Socket Message Elapsed Messages Size Size Time Okay Errors Throughput bytes bytes secs # # 10^6bits/sec 65535 1024 9.99 114127 0 93.55 65535 9.99 114122 93.54 |
UDP_STREAM方式的結果中有兩行測試數據，第一行顯示的是本地系統的發送統計，這裏的吞吐量表示netperf向本地socket發送分組的能力。但是，我們知道，UDP是不可靠的傳輸協議，發送出去的分組數量不一定等於接收到的分組數量。
第二行顯示的就是遠端系統接收的情況，由於client與server直接連接在一起，而且網絡中沒有其它的流量，所以本地系統發送過去的分組幾乎都被遠端系統正確的接收了，遠端系統的吞吐量也幾乎等於本地系統的發送吞吐量。但是，在實際環境中，一般遠端系統的socket緩衝大小不同於本地系統的socket緩衝區大小，而且由於UDP協議的不可靠性，遠端系統的接收吞吐量要遠遠小於發送出去的吞吐量。
測試請求/應答（request/response）網絡流量的性能
另一類常見的網絡流量類型是應用在client/server結構中的request/response模式。在每次交易（transaction）中，client向server發出小的查詢分組，server接收到請求，經處理後返回大的結果數據。如下圖所示：
1．TCP_RR
TCP_RR方式的測試對象是多次TCP request和response的交易過程，但是它們發生在同一個TCP連接中，這種模式常常出現在數據庫應用中。數據庫的client程序與server程序建立一個TCP連接以後，就在這個連接中傳送數據庫的多次交易過程。
./netperf -t TCP_RR -H 192.168.0.28 TCP REQUEST/RESPONSE TEST to 192.168.0.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 1 1 10.00 9502.73 16384 87380 |
Netperf輸出的結果也是由兩行組成。第一行顯示本地系統的情況，第二行顯示的是遠端系統的信息。平均的交易率（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,1024 TCP REQUEST/RESPONSE TEST to 192.168.0.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 16384 87380 32 1024 10.00 4945.97 16384 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.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 131070 131070 1 1 9.99 2662.20 16384 87380 |
即使是使用一個字節的request/response分組，交易率也明顯的降低了，只有2662.20次/秒。TCP_CRR使用與TCP_RR相同的局部參數。
3．UDP_RR
UDP_RR方式使用UDP分組進行request/response的交易過程。由於沒有TCP連接所帶來的負擔，所以我們推測交易率一定會有相應的提升。
./netperf -t UDP_RR -H 192.168.0.28 UDP REQUEST/RESPONSE TEST to 192.168.0.28 Local /Remote Socket Size Request Resp. Elapsed Trans. Send Recv Size Size Time Rate bytes Bytes bytes bytes secs. per sec 65535 65535 1 1 9.99 10141.16 65535 65535 |
結果證實了我們的推測，交易率爲10141.16次/秒，高過TCP_RR的數值。不過，如果出現了相反的結果，即交易率反而降低了，也不需要擔心，因爲這說明了在網絡中，路由器或其它的網絡設備對UDP採用了與TCP不同的緩衝區空間和處理技術。
除了netperf以外，還有很多其它的網絡性能測試工具，如dbs, iperf, pathrate, nettest, netlogger, tcptrace, ntop等。這些工具有其各自的特色和不同的側重點，我們可以根據具體的應用環境，有選擇的使用它們，這樣就可以使這些工具發揮出最大的功效。雖然都是開放源代碼的軟件，但是這些工具的功能與商業的網絡測試工具同樣強大，而且也得到了廣泛的應用，熟悉這些工具對我們的實際工作一定會有很大的幫助。
來源：http://www.ibm.com/developerworks/cn/linux/l-netperf/index.html