TCP Window Scaling & Download Speed Explained
How the Bandwidth-Delay Product limits single TCP connections and how multi-segmenting fixes it.
Under the Transmission Control Protocol (TCP), data transmission speed is not solely governed by your physical broadband bandwidth; it is strictly constrained by the Bandwidth-Delay Product (BDP) and the size of the receiver's TCP sliding buffer window.
1. The Bandwidth-Delay Product (BDP) Formula
The theoretical maximum amount of unacknowledged data that can be in flight over a network at any given millisecond is calculated by:
For example, on a 1 Gbps connection (125 MB/s) downloading from a server across the ocean with an RTT latency of 150ms (0.15s):
2. Why Single TCP Streams Fail to Saturate Bandwidth
Standard TCP headers without window scaling (RFC 7323) allocate only 16 bits for the receive window (maximum 65,535 bytes or 64 KB). When downloading with a 64 KB buffer over a 150ms connection, throughput is capped by Mathis's formula to:
Even with window scaling enabled, packet drops, server congestion algorithms (like CUBIC or BBR), and slow-start phases continually throttle a single connection.
3. How 64 Parallel Connections Solve the Bottleneck
By opening 64 parallel TCP connections, NeXDM distributes the total required BDP across 64 independent sliding windows. If one connection encounters packet loss or backoff, the other 63 connections continue transmitting at peak wire speed.