Last updated: 2026-06-24

TCP Throughput

TCP throughput is the sustained data rate a single TCP connection can achieve across a network path. It is not the same as the link rate: a 1 Gbps link can still deliver only a few megabits per second to one connection if the path has high latency and occasional packet loss. This calculator uses the Mathis equation to estimate that single-flow ceiling, which is the figure that matters for backups, replication, large uploads, and any transfer that rides on one TCP stream.

The Mathis equation

A long-lived TCP flow limited by random packet loss settles at a throughput of roughly:

Here $MSS$ is the maximum segment size in bytes and the multiplier of eight converts those bytes into bits. The round-trip time $RTT$ uses seconds as its unit, and $p$ is the packet loss probability expressed as a fraction. The result $T$ comes out in bits per second.

The form comes from how TCP congestion control behaves. After each loss, TCP halves its congestion window and then rebuilds it by one segment per round trip — the familiar additive-increase, multiplicative-decrease sawtooth. Averaging that sawtooth over many cycles gives a window proportional to $1/\sqrt{p}$, and dividing the window by the RTT yields the throughput above. Matthew Mathis and colleagues published this result in 1997, and it remains the standard back-of-the-envelope model for loss-limited TCP.

Worked example

Take a segment size of 1250 bytes, a round-trip time of 100 ms, and a packet loss rate of 0.01% (a fraction of 0.0001):

That is 10 Mbps from a single flow — regardless of whether the underlying link is rated at 100 Mbps or 10 Gbps. The path's latency and loss, not its raw capacity, set the ceiling.

Why latency and loss dominate

Two terms in the denominator explain why a fast link can feel slow:

• Round-trip time. Throughput is inversely proportional to RTT. Doubling the distance between two endpoints roughly halves the single-flow rate, because every window adjustment waits a full round trip to take effect.
• Packet loss. Throughput falls with the square root of the loss rate. Moving from 0.01% to 1% loss — a hundredfold rise — divides throughput by ten. On a long path the recovery is slow, so even rare loss compounds badly.

This combination of high latency and non-zero loss is sometimes called a "long fat network," and it is exactly where single-flow TCP underperforms.

When the model does not apply

The Mathis equation assumes the flow is loss-limited. If the path is clean and the TCP receive window is large enough to keep the pipe full, the connection is instead limited by the link rate or by the window itself. In that regime the bandwidth-delay product — bandwidth multiplied by RTT — tells you how large the window must be to saturate the link, and the Mathis formula no longer governs.

Modern congestion-control algorithms such as BBR also change the picture: they pace sending based on measured bandwidth and RTT rather than reacting to every loss, so they tolerate lossy paths far better than the classic loss-based model predicts. Treat the Mathis estimate as a conservative ceiling for traditional loss-based TCP, and remember that running several parallel connections multiplies the single-flow result.

Improving throughput

Reducing loss gives the biggest return because of the square-root relationship — track down flaky cabling, congested hops, and faulty hardware first. Shortening the RTT by moving servers closer to users or placing content on a CDN helps proportionally. Enabling jumbo frames raises the MSS where every hop on the path supports them. And where a single flow simply cannot fill the pipe, parallel streams or a loss-tolerant congestion-control algorithm close the gap.

Related calculators

To size the TCP window needed to fill a clean, high-latency link, use the Bandwidth-Delay Product Calculator calculator. To estimate how long a file takes to move once you know an effective rate, use the Data Transfer Time Calculator calculator. To convert a throughput figure between bits-per-second and bytes-per-second units, use the Throughput (bps) Converter calculator.