Todd

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 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方式下與測試相關的局部參數如下表所示：

通過修改以上的參數，并觀察結果的變化，我們可以確定是什么因素影響了連接的吞吐量。例如，如果懷疑路由器由于缺乏足夠的緩沖區空間，使得轉發大的分組時存在問題，就可以增加測試分組（-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參數，我們可以進行更有實際意義的測試：

./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不同的緩沖區空間和處理技術。