Why is my file transfer slower than my internet connection? TCP window, latency, and overhead explained

How this is calculated

There are several reasons a transfer runs below the link rate, and the bandwidth-delay product is the most common one people miss. The checklist, roughly in order of likelihood: the TCP window is smaller than the bandwidth-delay product (common on WAN and cloud transfers), the transfer tool is single-threaded and cannot parallelize, the disk at one end cannot sustain the link rate, the link is shared and contended, or the protocol (SMB, NFS, HTTPS) has per-connection overhead. On a local LAN the window almost never matters because the RTT is under 1 ms and even a 64 KB window cycles fast enough to fill a 1 Gbps link. On a WAN the window is the first thing to check, and the test is whether enabling window scaling materially changes the throughput.

Verdict

A file transfer running at a fraction of the rated link speed is almost always bottlenecked by the TCP receive window on a high-latency path rather than by the link itself, and the 1 Gbps transatlantic example is the cleanest proof: at 80 ms round-trip the default 64 KB window delivers 6.55 Mbps, which is 0.66% of the 1000 Mbps the link can carry. The diagnostic order that resolves most real cases is to check whether window scaling is negotiated first (because that is the cheapest fix and the most common silent failure), then check whether the transfer tool is single-threaded, then check whether the disk at either end can sustain the link rate, then suspect link contention. The structural reason a naive size-over-speed calculator misdiagnoses this is that it assumes the link is the only bottleneck, which is true on a LAN and false the moment the RTT crosses roughly 10 ms.