TCP Throughput Calculator

How to use the TCP throughput calculator

1. Enter the effective window: use the smallest practical per-flow limit imposed by receive-window, send-buffer, or other known configuration.
2. Measure RTT: use a representative end-to-end round-trip time rather than one-way latency.
3. Add packet loss and MSS: use a sustained path loss rate and the payload MSS after IP and TCP headers.
4. Set the target and link: the optional bottleneck rate caps the estimate and lets the calculator determine the BDP.
5. Read all three ceilings: the combined estimate is the lowest of window/RTT, Reno loss, and optional link capacity.

TCP throughput formulas and assumptions

Window-limited ceiling: window bytes × 8 ÷ RTT seconds

Reno loss estimate: factor × MSS bytes × 8 ÷ (RTT seconds × √loss probability)

Combined estimate: minimum(window ceiling, loss estimate, optional link rate)

Required target window / BDP: target bits per second × RTT seconds ÷ 8

Modeled loss budget: (factor × MSS × 8 ÷ (RTT × target bits per second))²

The Mathis model describes a long-lived TCP Reno-style flow in congestion avoidance with sufficient data, independent loss, and no retransmission timeouts. The default coefficient is 1.22. When loss is zero, the calculator does not treat the loss formula as an infinite promise; window size and the optional link remain the active ceilings.

Worked examples

Values are payload-rate planning estimates before application overhead and real implementation behavior.

How to interpret the limiting factor

Window / RTT

The connection cannot keep enough data in flight to fill the target path. Increase the effective receive window and sender buffer, confirm Window Scale was negotiated, or reduce RTT. A window at least as large as the bandwidth-delay product is necessary but does not guarantee the target rate.

Reno packet-loss model

The selected loss rate makes a classic Reno-style congestion window the smaller modeled constraint. Find and fix congestion or physical loss, check retransmissions and ECN behavior, and compare with the actual congestion controller. Parallel flows may change aggregate throughput but also compete with other traffic.

Bottleneck link

The configured path capacity is the smallest ceiling. A TCP payload rate will normally remain below raw line rate because Ethernet, IP, TCP, acknowledgments, encryption, and application protocols consume capacity.

References and methodology

• RFC 6349, Framework for TCP Throughput Testing, defines the window/RTT throughput relationship and uses RTT-based bandwidth-delay product for window sizing.
• RFC 7323, TCP Extensions for High Performance, specifies Window Scale and explains the 65,535-byte unscaled receive-window limit.
• RFC 9293, Transmission Control Protocol, is the current core TCP specification.
• Mathis, Semke, Mahdavi, and Ott, “The Macroscopic Behavior of the TCP Congestion Avoidance Algorithm”, provides the square-root congestion-avoidance model.
• RFC 9438, CUBIC for Fast and Long-Distance Networks, describes why a modern CUBIC flow does not follow Reno behavior exactly.

Last reviewed: July 2026. All calculations are deterministic and run locally in the browser.

TCP throughput FAQs

How does TCP window size limit throughput?

A sender can keep only the effective window of unacknowledged data in flight. In the ideal no-loss case, the window-limited ceiling is window bytes multiplied by 8 and divided by RTT in seconds.

Why does packet loss reduce TCP throughput?

Loss signals congestion to loss-based TCP and reduces its congestion window. This calculator uses the Mathis square-root model as a steady-state Reno-style estimate for independent, light-to-moderate loss.

What is bandwidth-delay product?

BDP is bottleneck bits per second multiplied by RTT seconds. Divide it by 8 for the minimum bytes of in-flight data needed to fill the path in an ideal steady state.

Does a window larger than 65,535 bytes require Window Scale?

Yes. The header window field is 16 bits. RFC 7323 Window Scale negotiates a multiplier during the handshake so effective receive windows can exceed 65,535 bytes.

Is this accurate for CUBIC or BBR?

The window and link ceilings still matter, but the Mathis loss model describes Reno-style congestion avoidance. CUBIC and BBR react differently, so measure the actual path and TCP implementation.

Should I enter receive window, congestion window, or socket buffer?

Enter the effective in-flight window available to one flow. In practice throughput is constrained by the smaller of the sender limit, advertised receive window, congestion window, and implementation limits.

Why can a speed test differ from this estimate?

Real transfers include slow start, changing RTT, application behavior, protocol overhead, retransmission timeouts, burst or correlated loss, host limits, competing traffic, and possibly multiple TCP flows.

Are my inputs uploaded?

No. Calculations run locally in the browser and the tool does not submit calculator inputs to a backend.

Planning limits

This calculator is an infrastructure planning aid, not a capacity guarantee. Validate important designs with host TCP statistics, packet captures, retransmission counters, path MTU tests, controlled single-flow and multi-flow measurements, and the actual congestion-control algorithm used in production.