在構建或管理一個網絡系統時，我們更多的是關心網絡的可用性，即網絡是否連通，而對于其整體的性能往往考慮不多，或者即使考慮到性能的問題，但是卻發現沒有合適的手段去測試網絡的性能。
當開發出一個網絡應用程序后，我們會發現，在實際的網絡環境使用中，網絡應用程序的使用效果不是很理想，問題可能出現在程序的開發上面，也有可能由于實際的網絡環境中存在著瓶頸。面對這種問題，程序員一般會一籌莫展，原因就在于不掌握一些網絡性能測量的工具。
在本文中，首先介紹網絡性能測量的一些基本概念和方法，然后結合 netperf 工具的使用，具體的討論如何測試不同情況下的網絡性能。
測試網絡性能的第一步是確定網絡是否正常工作，最簡單的方法是使用 ping 命令。通過向遠端的機器發送 icmp echo request，并等待接收 icmp echo reply 來判斷遠端的機器是否連通，網絡是否正常工作。
Ping 命令有非常豐富的命令選項，比如 -c 可以指定發送 echo request 的個數，-s 可以指定每次發送的 ping 包大小。
網絡設備內部一般有多個緩沖池，不同的緩沖池使用不同的緩沖區大小，分別用來處理不同大小的分組（packet）。
例如交換機中通常具有三種類型的包緩沖：
一類針對小的分組一類針對中等大小的分組還有一類針對大的分組。為了測試這樣的網絡設備，測試工具必須要具有發送不同大小分組的能力。Ping 命令的 -s 就可以使用在這種場合。
Ping 命令的 echo request/reply 一次往返所花費時間就是響應時間。有很多因素會影響到響應時間，如網段的負荷，網絡主機的負荷，廣播風暴，工作不正常的網絡設備等等。
在網絡工作正常時，記錄下正常的響應時間。當用戶抱怨網絡的反應時間慢時，就可以將現在的響應時間與正常的響應時間對比，如果兩者差值的波動很大，就能說明網絡設備存在故障。
網絡利用率是指網絡被使用的時間占總時間（即被使用的時間+空閑的時間）的比例。比如，Ethernet 雖然是共享的，但同時卻只能有一個報文在傳輸。因此在任一時刻，Ethernet 或者是 100% 的利用率，或者是 0% 的利用率。
計算一個網段的網絡利用率相對比較容易，但是確定一個網絡的利用率就比較復雜。
因此，網絡測試工具一般使用網絡吞吐量和網絡帶寬容量來確定網絡中兩個節點之間的性能。
網絡吞吐量是指在某個時刻，在網絡中的兩個節點之間，提供給網絡應用的剩余帶寬。
網絡吞吐量可以幫組尋找網絡路徑中的瓶頸。比如，即使 client 和 server 都被分別連接到各自的 100M Ethernet 上，但是如果這兩個 100M 的Ethernet 被 10M 的 Ethernet 連接起來，那么 10M 的 Ethernet 就是網絡的瓶頸。
網絡吞吐量非常依賴于當前的網絡負載情況。因此，為了得到正確的網絡吞吐量，最好在不同時間（一天中的不同時刻，或者一周中不同的天）分別進行測試，只有這樣才能得到對網絡吞吐量的全面認識。
有些網絡應用程序在開發過程的測試中能夠正常運行，但是到實際的網絡環境中卻無法正常工作（由于沒有足夠的網絡吞吐量）。這是因為測試只是在空閑的網絡環境中，沒有考慮到實際的網絡環境中還存在著其它的各種網絡流量。所以，網絡吞吐量定義為剩余帶寬是有實際意義的。
與網絡吞吐量不同，網絡帶寬容量指的是在網絡的兩個節點之間的最大可用帶寬。這是由組成網絡的設備的能力所決定的。
測試網絡帶寬容量有兩個困難之處：在網絡存在其它網絡流量的時候，如何得知網絡的最大可用帶寬；在測試過程中，如何對現有的網絡流量不造成影響。網絡測試工具一般采用 packet pairs 和 packet trains 技術來克服這樣的困難。
當確定了網絡性能的測試指標以后，就需要使用網絡測試工具收集相應的性能數據，分別有三種從網絡獲取數據的方式：
通過snmp協議直接到網絡設備中獲取，如net-snmp工具偵聽相關的網絡性能數據，典型的工具是tcpdump自行產生相應的測試數據，如本文中使用的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流量模式：
單個TCP連接，批量（bulk）傳輸大量數據單個TCP連接，client請求/server應答的交易（transaction）方式多個TCP連接，每個連接中一對請求/應答的交易方式UDP沒有建立連接的負擔，但是UDP不能保證傳輸的可靠性，所以使用UDP的應用程序需要自行跟蹤每個發出的分組，并重發丟失的分組。
Netperf可以模擬兩種UDP的流量模式：
從client到server的單向批量傳輸請求/應答的交易方式由于UDP傳輸的不可靠性，在使用netperf時要確保發送的緩沖區大小不大于接收緩沖區大小，否則數據會丟失，netperf將給出錯誤的結果。因此，對于接收到分組的統計不一定準確，需要結合發送分組的統計綜合得出結論。
在Ubuntu下使用： apt-get install netperf
如果linux的發行版中沒有源的話，使用下載源碼的方式安裝：
http://www.netperf.org/netperf/NetperfPage.htmltar -xzvf netperf-2.4.5.tar.gzcd netperf-2.4.5./configuremakemake install5.2 運行
netperf采用客戶機/服務器方式工作，首先在服務器上啟動netserver。在unix/Linux系統中，可以直接運行可執行程序來啟動netserver，也可以讓inetd或xinetd來自動啟動netserver。
netserver或者netserver -D -4 -L 0.0.0.0 -p 9991當netserver在server端啟動以后，即可在客戶端上運行netperf開始性能測試：
netperf -H 服務器ip5.3 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）。
5.4 測試批量（bulk）網絡流量的性能
批量數據傳輸典型的例子有ftp和其它類似的網絡應用（即一次傳輸整個文件）。根據使用傳輸協議的不同，批量數據傳輸又分為TCP批量傳輸和UDP批量傳輸。
5.4.1 TCP_STREAM
Netperf缺省情況下進行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的結果輸出中，我們可以知道以下的一些信息：
遠端系統（即server）使用大小為87380字節的socket接收緩沖本地系統（即client）使用大小為16384字節的socket發送緩沖向遠端系統發送的測試分組大小為16384字節測試經歷的時間為60秒吞吐量的測試結果為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字節相比）。相反，如果吞吐量有了較大的提升，則說明在網絡中間的路由器確實存在緩沖區的問題。
5.4.2 UDP_STREAM
UDP_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協議的不可靠性，遠端系統的接收吞吐量要遠遠小于發送出去的吞吐量。
5.5 測試請求/應答（request/response）網絡流量的性能
另一類常見的網絡流量類型是應用在client/server結構中的request/response模式。在每次交易（transaction）中，client向server發出小的查詢分組，server接收到請求，經處理后返回大的結果數據。如下圖所示：
5.5.1 TCP_RR
TCP_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 sec16384 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 sec16384 87380 32 1024 10.00 4945.9716384 87380從結果中可以看出，由于request/reponse分組的大小增加了，導致了交易率明顯的下降。
注：相對于實際的系統，這里交易率的計算沒有充分考慮到交易過程中的應用程序處理時延，因此結果往往會高于實際情況。
5.5.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 sec131070 131070 1 1 9.99 2662.2016384 87380即使是使用一個字節的request/response分組，交易率也明顯的降低了，只有2662.20次/秒。TCP_CRR使用與TCP_RR相同的局部參數。
5.5.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.28Local /RemoteSocket Size Request Resp. Elapsed Trans.Send Recv Size Size Time Ratebytes Bytes bytes bytes secs. per sec65535 65535 1 1 9.99 10141.1665535 65535結果證實了我們的推測，交易率為10141.16次/秒，高過TCP_RR的數值。不過，如果出現了相反的結果，即交易率反而降低了，也不需要擔心，因為這說明了在網絡中，路由器或其它的網絡設備對UDP采用了與TCP不同的緩沖區空間和處理技術。
5.6 Misc
這里好像沒有提及到服務端怎樣執行：
netserver -D -4 -L 0.0.0.0 -p 9991 # 服務端netperf -l 60 -4 -f m -t TCP_CRR -H 10.20.216.249 -p 9991 -- -r 64,64 # 客戶端而且客戶端和服務端都存在性能瓶頸：
需要使用多個客戶端或多進程才能產生更大壓力（特別是小包的情況下）而且服務端瓶頸不一定是網卡，很多情況下CPU是瓶頸（特別是小包）參考文獻
http://www.netperf.org/netperf/NetperfPage.htmlhttp://www.cs.kent.edu/~farrell/dist/ref/Netperf.html Section 8. Netperf examples 很不錯！http://www.ibm.com/developerworks/cn/linux/l-netperf/
新聞熱點
疑難解答
