netperf 與網路效能測量

本文首先介紹網路效能測量的一些基本概念和方法，然後結合 netperf 工具的使用，具體的討論如何測試不同情況下的網路效能。

湯凱 (tangk73@hotmail.com),

2004 年 7 月 01 日

• 內容

在構建或管理一個網路系統時，我們更多的是關心網路的可用性，即網路是否連通，而對於其整體的效能往往考慮不多，或者即使考慮到效能的問題，但是卻發現沒有合適的手段去測試網路的效能。

當開發出一個網路應用程式後，我們會發現，在實際的網路環境使用中，網路應用程式的使用效果不是很理想，問題可能出現在程式的開發上面，也有可能由於實際的網路環境中存在著瓶頸。面對這種問題，程式員一般會一籌莫展，原因就在於不掌握一些網路效能測量的工具。

在本文中，首先介紹網路效能測量的一些基本概念和方法，然後結合 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

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協議能夠提供端到端的可靠傳輸，因此被大量的網路應用程式使用。但是，可靠性的建立是要付出代價的。TCP協議保證可靠性的措施，如建立並維護串連、控制資料有序的傳遞等都會消耗一定的網路頻寬。

Netperf可以類比三種不同的TCP流量模式：

1） 單個TCP串連，批量（bulk）傳輸大量資料

2） 單個TCP串連，client請求/server應答的交易（transaction）方式

3） 多個TCP串連，每個串連中一對請求/應答的交易方式

UDP網路效能

UDP沒有建立串連的負擔，但是UDP不能保證傳輸的可靠性，所以使用UDP的應用程式需要自行跟蹤每個發出的分組，並重發丟失的分組。

Netperf可以類比兩種UDP的流量模式：

1） 從client到server的單向批量傳輸

2） 請求/應答的交易方式

由於UDP傳輸的不可靠性，在使用netperf時要確保發送的緩衝區大小不大於接收緩衝區大小，否則資料會丟失，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）。

Netperf測試網路效能

測試批量（bulk）網路流量的效能

批量資料轉送典型的例子有ftp和其它類似的網路應用（即一次傳輸整個檔案）。根據使用傳輸協議的不同，批量資料轉送又分為TCP批量傳輸和UDP批量傳輸。

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的結果輸出中，我們可以知道以下的一些資訊：

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_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.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.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  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,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_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 sec 65535  65535  1        1       9.99     10141.1665535  65535

結果證實了我們的推測，交易率為10141.16次/秒，高過TCP_RR的數值。不過，如果出現了相反的結果，即交易率反而降低了，也不需要擔心，因為這說明了在網路中，路由器或其它的網路裝置對UDP採用了與TCP不同的緩衝區空間和處理技術。

回頁首

結束語

除了netperf以外，還有很多其它的網路效能測試工具，如dbs, iperf, pathrate, nettest, netlogger, tcptrace, ntop等。這些工具有其各自的特色和不同的側重點，我們可以根據具體的應用環境，有選擇的使用它們，這樣就可以使這些工具發揮出最大的功效。雖然都是開放原始碼的軟體，但是這些工具的功能與商業的網路測試載入器同樣強大，而且也得到了廣泛的應用，熟悉這些工具對我們的實際工作一定會有很大的協助。