Throughput

Throughput is the amount of data that was actually transferred across a link or network path in a given time. It is usually expressed in bits per second (bps, Mbps, Gbps). It is not the same as bandwidth, the theoretical maximum capacity of the link. Bandwidth tells you how much data the link could carry. Throughput tells you how much really got through once you subtract protocol overhead, retransmissions, queuing, and hardware limits. In practice, throughput is always lower than the link’s capacity.

How does throughput differ from bandwidth and goodput?

These three terms form a hierarchy: bandwidth > throughput > goodput. Each level removes another type of overhead.

• Bandwidth (theoretical capacity) — the maximum capacity of the link set by its physics, e.g. 1 Gbps for 1000BASE-T or 10 Gbps for 10GBASE-T. This is the figure a provider advertises, not what you actually get.
• Throughput (actual rate) — the real transfer rate measured on the link. It counts all traffic: protocol headers, control frames, and retransmissions. So it also includes data that is not useful application content.
• Goodput (useful rate) — only the application payload delivered correctly to the receiver. It excludes lower-layer headers (e.g. a 20-byte IPv4 header, a 40-byte IPv6 header, TCP headers, Ethernet framing) and packets that had to be resent. Goodput is always lower than throughput.

We cover bandwidth in a separate entry. Put simply: bandwidth is the width of the pipe, throughput is the water that actually flowed through it, and goodput is the water that arrived clean and usable.

How is throughput measured?

Throughput is usually reported as an average over a measurement window, because the instantaneous value jumps around a lot. There are two approaches.

• Active testing — you generate test traffic between two hosts, for example with iperf3. On the server side: iperf3 -s, on the client side: iperf3 -c <server_ip>. Parameters like parallel streams (-P), block size (-l), or UDP testing (-u) let you probe TCP/UDP limits. The retransmission counter shows packet loss.
• Passive testing — you observe real production traffic without injecting any test data. You can use interface counters (SNMP), flow telemetry (NetFlow/IPFIX/sFlow), or packet captures. This method is used in network monitoring because it does not load the link with an extra test.

When you read the result, keep the weakest-link rule in mind: end-to-end throughput is capped by the slowest link on the path, no matter how large the other segments are.

What factors limit throughput?

• Latency (RTT) — for TCP this is often the main brake. The maximum throughput of a single stream is roughly TCP window / RTT. The higher the delay, the lower the achievable throughput, unless the window is large enough.
• Bandwidth-delay product (BDP) — BDP = bandwidth × RTT tells you how much data must be “in flight” to use the link fully. If the TCP receive window is smaller than the BDP, the sender stalls waiting for acknowledgements and the link sits underused. That is why high-BDP links need window scaling (tcp_window_scaling) and well-sized buffers.
• Packet loss — each loss forces a retransmission, and in classic congestion-control algorithms it also shrinks the send window. That cuts throughput sharply, especially on high-RTT links.
• Protocol overhead and MTU — L2–L4 headers and fragmentation from a badly matched MTU raise the share of data that is not application content. Larger frames (jumbo frames) and a matched MTU reduce this overhead.
• Congestion and queuing — crowded queues in devices along the path add delay, jitter, and drops, so effective throughput falls.
• Host and NIC limits — CPU performance, NIC offload settings (e.g. TSO, GRO), buffer sizes, and queue counts can become the bottleneck at high speeds, even when the network itself is fine.

Why does throughput matter for security and network monitoring?

Throughput is not only a performance measure. It is also telemetry that helps detect threats and keep defenses running.

• Inspection-device performance — next-generation firewalls (NGFW), IPS systems, SSL/TLS gateways, and IDS/NDR sensors have a rated maximum inspection throughput. That figure drops once you enable TLS decryption and deep packet inspection. Once it is exceeded, the device saturates: packets get queued, dropped, or — with a misconfigured fail-open mode — passed through uninspected, which creates a visibility gap.
• Anomaly detection — a sudden rise in throughput in an unusual direction may mean data exfiltration, malware spreading, or C2 activity. A sharp spike in inbound traffic can signal a volumetric (DDoS) attack. Once you know the baseline throughput per host, service, and direction, deviations are easier to spot.
• Monitoring blind spots — when an NDR sensor or flow collector cannot keep up with the link throughput, part of the traffic goes unanalyzed (drops on taps/SPAN). Sizing capture points and sensors to the real throughput is a prerequisite for full SOC visibility.
• Incident and performance diagnostics — when you line up a throughput drop with latency, loss, and retransmissions, it is easier to tell a network issue (a congested link, bad QoS) apart from an attack or from the application itself degrading.

Learn more

• NPM (Network Performance Monitoring) — NPM measures throughput to assess network performance and capacity.
• Secure Access Service Edge (SASE) — SASE depends on throughput for consistent access across cloud-delivered security paths.
• Network TAP — A Network TAP copies traffic for analysis, enabling accurate throughput measurement.