There's often a gap between theoretical network bandwidth and actual throughput, and latency can vary with path and load. In such cases, a reliable tool is needed to provide quantifiable data. Netperf is a classic and powerful network performance benchmarking tool that helps us measure TCP and UDP throughput, latency, and connection rates under different conditions.

Netperf works using a client-server model. During testing, the Netperf server (netserver) needs to be started at one end of the tested link, and the Netperf client (netperf) runs at the other end. The client initiates specific network traffic to the server, and performance metrics are ultimately calculated. This design makes it ideal for testing end-to-end network performance between two points.

Before using Netperf, it needs to be installed on the machines involved in the test. On most Linux distributions, the installation process is very simple.

# Install on Debian/Ubuntu-based systems

sudo apt-get update

sudo apt-get install netperf -y

# Install on RHEL/CentOS-based systems

sudo yum install epel-release -y

sudo yum install netperf -y

After installation, we need to start the netserver process on the "server" side of the network path being tested. By default, it listens on port 12865. To ensure the test is not interfered with by firewalls, you may need to temporarily adjust the firewall rules.

# Start netserver on the machine acting as the server

# Use the '-p' parameter to specify the listening port

netserver -p 12865

# Verify that netserver is running

sudo netstat -tlnp | grep netserver

Next, on another machine acting as the client, we can run the netperf command for testing. The most basic test is TCP_STREAM mode, which measures one-way TCP throughput, and this is also the most commonly used test scenario.

# Basic TCP Throughput Test

# -H Specifies the server IP address

# -t Specifies the test type as TCP_STREAM

# -l Specifies the test duration (seconds)

netperf -H 192.168.1.100 -t TCP_STREAM -l 60

After executing this command, the netperf client will establish a TCP connection to the server and continuously send data for 60 seconds. At the end of the test, it will output a series of results. The key metric we need to focus on is "Throughput," usually measured in megabits per second (Mbps) or megabytes per second (MB/s). This number intuitively reflects the actual effective bandwidth that TCP transmission can achieve under current network conditions. Many factors affect this result, including the physical bandwidth of the network itself, the TCP buffer size of both ends of the machine, CPU processing power, and latency and packet loss along the path.

Simply knowing the throughput is sometimes not enough. For more in-depth tuning or diagnosis, we often need to adjust the size of the TCP socket buffer and observe its impact on performance. Netperf allows us to easily modify these parameters. # Test the impact of different send and receive buffer sizes on throughput

# -s Set the local (send) socket buffer size

# -S Set the remote (receive) socket buffer size

netperf -H 192.168.1.100 -t TCP_STREAM -l 60 -- -s 256K -S 256K

The TCP_STREAM test is unidirectional, while many real-world applications (such as HTTP and databases) involve request and response interactions. For this model, Netperf provides the TCP_RR (Request/Response) test. It measures how many TCP transactions (one small request sent plus one small response received) can be completed per second. This metric is crucial for evaluating the network performance of interactive applications.

# TCP Request/Response Rate Test

netperf -H 192.168.1.100 -t TCP_RR -l 60

# You can specify the size of the request and response packets (in bytes)

netperf -H 192.168.1.100 -t TCP_RR -l 60 -- -r 32,1024

Besides TCP, Netperf can also perform a detailed evaluation of UDP performance. UDP testing is particularly important because it helps us discover the network's own packet loss and out-of-order rates, unaffected by TCP retransmission and flow control mechanisms. The UDP_STREAM test reports throughput, packet loss, and out-of-order packet status.

# UDP Throughput and Packet Loss Test

# Note: UDP tests must specify the packet size (-m or -M)

netperf -H 192.168.1.100 -t UDP_STREAM -l 60 -- -m 1400

After performing a series of isolated tests, we often need to integrate Netperf into automation scripts to simulate more complex scenarios or perform long-term monitoring. A simple shell script can loop through different parameters and log the results to a file for later analysis.

#!/bin/bash

SERVER_IP="192.168.1.100"

LOG_FILE="netperf_results_$(date +%Y%m%d).csv"

DURATION=30

# Write CSV file header

echo "Timestamp,Test_Type,Buffer_Size,Throughput_Mbps" > $LOG_FILE

# Test different socket buffer sizes

for SIZE in 32K 64K 128K 256K 512K 1024K

do

OUTPUT=$(netperf -H $SERVER_IP -t TCP_STREAM -l $DURATION -- -s $SIZE -S $SIZE | tail -n 1)

THROUGHPUT=$(echo $OUTPUT | awk '{print $5}')

TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

echo "$TIMESTAMP,TCP_STREAM,$SIZE,$THROUGHPUT" >> $LOG_FILE

sleep 5

done

Interpreting Netperf results requires considering the specific context. Lower TCP throughput may be caused by high latency, small buffers, or policy limitations of intermediate network devices. High packet loss rates in UDP tests clearly point to network link quality or bottlenecks in switches and firewalls. In my own tests, by comparing results within an intranet and across data centers, I clearly quantified the negative impact of increased WAN latency on the transaction rate (TCP_RR) of interactive applications, providing crucial data support for subsequent application architecture adjustments.

To obtain stable and reliable results, several key points need to be considered during testing. Ensure there is no interference from other large network traffic during the test; the test duration should not be too short, generally recommended to be at least 30 seconds, to allow the TCP stream to reach a stable state; for UDP testing, the sending rate should not exceed the known network physical bandwidth, otherwise all packet loss will be attributed to human overload and will lose diagnostic value.

In summary, Netperf is a straightforward and powerful tool. It lacks a graphical interface and outputs plain text, but this simplicity allows it to be seamlessly integrated into various automated operation and maintenance and testing processes. By systematically using Netperf to measure TCP throughput, transaction rate, and UDP performance, we can transform network performance from a subjective perception into objective data, thus laying a solid factual foundation for capacity planning, troubleshooting, and performance optimization. Mastering it is like having the ability to diagnose and treat your network.