The symptom everyone recognises
You pay for a gigabit. A transfer to the office across town runs near that. The same transfer to a partner on another continent runs at a fraction of it, on the same tools, with the same files. Nothing is broken. The protocol is doing exactly what it was designed to do.
TCP was built to share a network fairly between many flows. Its congestion control treats every lost packet as a signal that the network is full, cuts its sending rate, and then grows back slowly, one round trip at a time. On a short link a round trip is a millisecond and the recovery is invisible. On a long link a round trip is 100 to 300 milliseconds and the recovery is most of the transfer.
The arithmetic
A widely used approximation (the Mathis model) says a single TCP stream's throughput is roughly the segment size divided by the round-trip time times the square root of the loss rate. Two things fall out of it: doubling the distance halves the rate, and loss hurts far more than its percentage suggests.
| Round-trip time | Packet loss | Rough single-stream ceiling |
|---|---|---|
| 10 ms | 0.01% | hundreds of Mbps |
| 80 ms | 0.1% | tens of Mbps |
| 150 ms | 1% | single-digit Mbps |
| 150 ms | 3% | a few Mbps |
What helps while you stay on TCP
- Parallel streams: several TCP connections share the loss between them, so each recovers independently. Tools such as rclone, lftp and parallel scp do this. It helps, and it also multiplies connections, complicates resume, and still collapses on a bursty link.
- Window and buffer tuning: larger TCP windows let a stream keep more data in flight over a long path. It needs administrator access on both ends and is per-route work.
- Newer congestion control: BBR-style algorithms estimate bandwidth and delay instead of reacting only to loss and do much better on lossy paths. They require kernel support on the sending side and are still one stream with TCP's semantics.
- Compression and deduplication: reduce the bytes; do nothing for the protocol's behaviour, and most media and scientific data does not compress.
What a UDP-based transfer changes
UDP carries packets without TCP's built-in reaction to loss, so a transfer protocol on top of it can decide for itself how to respond. The protocols used by accelerated transfer products, including RIPTON's RIPT, send at a controlled rate, keep track of which blocks arrived, and retransmit only the missing blocks. A lost packet costs one retransmission, not a rate collapse and a slow climb back.
That is why the effect is largest exactly where TCP is weakest: long round trips and measurable loss. On a clean local link there is little to gain, and any honest vendor will tell you so.
What to do with this
- 1Measure the route: round-trip time with ping, loss over a few minutes, and the link speed each side actually has. The calculator turns those into an expected time for both approaches.
- 2If the link is short and clean, keep what you have and fix the disk or the application instead.
- 3If the link is long or lossy, try parallel streams first if you control both ends and the tooling is acceptable.
- 4If the route matters every day, test an accelerated transfer on it against your current tool and keep the numbers.