Throughput is what you actually get, and speed is what you’re promised.
Let’s see this in action. Imagine we have a simple setup:
Client (10.0.0.10) -- Ethernet (1 Gbps) --> Router (192.168.1.1) -- Ethernet (1 Gbps) --> Server (192.168.1.100)
We’ll use iperf3 to test. First, start iperf3 in server mode on the server:
iperf3 -s
Now, on the client, run iperf3 to connect to the server:
iperf3 -c 192.168.1.100
A typical output might look like this:
Connecting to host 192.168.1.100, port 5201
[...]
[ ID] Interval Transfer Bitrate
[ 5] 0.00-1.00 sec 110 MBytes 923 Mbits/sec
[ 5] 1.00-2.00 sec 111 MBytes 931 Mbits/sec
[ 5] 2.00-3.00 sec 110 MBytes 923 Mbits/sec
[...]
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bitrate
[ 5] 0.00-10.00 sec 1.08 GBytes 925 Mbits/sec sender
[ 5] 0.00-10.00 sec 1.08 GBytes 925 Mbits/sec receiver
[...]
iperf Done.
Here, the "Bitrate" of 925 Mbits/sec is the throughput. This is the actual amount of data successfully transferred per second. The "speed" we’re talking about with the Ethernet cables is the theoretical maximum, 1 Gbps (or 1000 Mbits/sec). The throughput is less than the speed because of overhead.
Think of network bandwidth like a highway. The "speed" is the posted speed limit (e.g., 70 mph). This is the maximum theoretical speed your car could travel. "Throughput" is how fast you actually get from Point A to Point B, accounting for traffic, road construction, the car’s actual capabilities, and how much cargo it’s carrying. Even on an empty highway with a 70 mph limit, your car might only average 65 mph due to engine limitations or traffic lights.
The problem this solves is understanding why your network doesn’t always perform at its advertised maximum. If you have gigabit Ethernet ports, you don’t automatically get 1000 Mbps of usable data transfer. You get less, and that "less" is throughput.
Internally, the difference between speed and throughput is accounted for by several factors:
- Protocol Overhead: Every packet sent across the network has headers added by various protocols (Ethernet, IP, TCP/UDP). These headers contain control information, not your actual data. For TCP/IP over Ethernet, this overhead can easily consume 5-10% of the raw link speed.
- Device Limitations: The network interface cards (NICs) in your devices, the CPU on your router, and the software processing the packets all have finite processing power. They can only handle so many packets per second or so much data in a given time.
- Network Congestion: If other devices on the same network segment are also using bandwidth, or if the path to your destination has congested links, your throughput will decrease.
- Duplex Mismatch/Errors: If a link is configured for full-duplex but one side is only half-duplex, or if there are many packet errors requiring retransmissions, throughput suffers.
The iperf3 output shows the aggregate throughput over a 10-second interval. The Bitrate reported is the actual data rate achieved. This is the crucial metric for understanding application performance. If you’re trying to transfer a large file, the time it takes is determined by this throughput, not the theoretical speed of your Ethernet ports.
The most surprising thing about network throughput is how much of your "advertised" speed is eaten up by the very protocols designed to make networking reliable and structured. TCP, for instance, adds sequence numbers, acknowledgments, and windowing information. Each of these bits of data, while essential for error checking and flow control, takes up space in the packet that could otherwise be used for your actual payload. This means that even on a perfect, uncongested 1 Gbps link with no other traffic, you’ll likely never see throughput much higher than 940-950 Mbps due to the fundamental overhead of the Ethernet frame and IP/TCP headers.
The next concept you’ll want to explore is latency, which is the time it takes for a single packet to travel from source to destination, and how it combines with throughput to impact perceived performance.