A brief history of fast file transfer (1971 — 2025)

Most “fast file transfer” pitches treat the technology as if it appeared yesterday. It didn’t. The fundamental insight — that TCP is the wrong tool for long-fat networks and UDP with custom reliability is the right one — has been independently rediscovered roughly every five years for the last quarter-century. Here’s the short version of how we got here.

1971 — FTP (RFC 114)

Abhay Bhushan publishes RFC 114 on April 16, 1971. ARPANET has 23 hosts. TCP doesn’t exist yet — it’ll be specified six years later. FTP is built for the assumption that machines are in the same room, or at least the same building, with predictable latency.

The protocol works fine for the world that exists. It also bakes in two architectural decisions that won’t age well: a new control + data connection per file, and a synchronous request-response model under the hood.

1995–2001 — TCP gets the long-haul problem

By the mid-1990s the public internet is global, and the asymmetry between bandwidth and latency starts showing up everywhere. RFC 1323 (1992) introduces TCP window scaling to push the receive window past 64 KB. SACK ships in RFC 2018 (1996). HTTP/1.1 introduces persistent connections in 1999.

These are all real wins. They are also all working around TCP’s stop-and-wait nature rather than replacing it. The throughput formula window_size / RTT still holds — you can make the numerator bigger, but you can’t make the wait disappear.

2001–2003 — The UDP turn

The decisive shift happens in a three-year window when three different groups, working independently, all arrive at the same architectural answer.

2001: UDT. Yunhong Gu starts the UDP-based Data Transfer project. In October 2003, NCDM uses it to push 6.8 Gbps from Chicago to Amsterdam — a number that was previously thought to require dedicated hardware. UDT becomes the foundation of much of the high-energy-physics file movement that follows.

~2003: FASP. Michelle Munson and Serban Simu invent the Fast and Secure Protocol, productize it as Aspera, and prove the model in broadcast and post-production workflows. IBM acquires Aspera in 2014; FASP becomes the gold standard for enterprise media transfer for the next decade.

Same period: GridFTP. Globus extends FTP itself with parallel TCP streams and partial-file restart. It’s still TCP-based, but it’s the bridge protocol that proves “parallelism is most of the win” before everyone migrates to UDP.

Three names, one architecture: skip the ack-then-send dance, run your own congestion control in userspace, accept some packet loss as the price of saturation.

~2013 — Facebook open-sources WDT

Around the same window QUIC starts shipping, Facebook quietly puts Warp Speed Data Transfer (WDT) on GitHub. It isn’t a product — it’s a C++ library their infra team uses to move datasets between hosts inside the company, with a small CLI bolted on for testing. The headline number from the docs: a single WDT session saturates a 40 Gbit/s NIC.

WDT’s wins are still about parallelism — many streams over TCP, not one stream over UDP — but the conclusion is the same one UDT and FASP reached a decade earlier: a single sequential connection is the wrong abstraction for a long-fat link, and the fix is to split it. By 2013 that lesson had been independently rediscovered at file-transfer startups, in the IETF, and inside the hyperscalers. The naming debt we owe Facebook here is, we acknowledge, conspicuous.

2013 — QUIC

Google starts shipping QUIC to Chrome in 2013. The original goal is web latency — TLS 1.3 + transport in one round trip — but the design ends up validating the UDP-with-userspace-reliability model for general-purpose internet traffic.

The IETF picks it up in 2016. QUIC ships as RFC 9000 in 2021. By the time HTTP/3 is widely deployed, the idea that “important traffic should not run over TCP” has gone from a fringe academic position to the default for Google, Cloudflare, Meta, and most CDNs.

For file transfer specifically, QUIC doesn’t replace FASP-style products — its connection model and flow control are tuned for HTTP-shaped workloads, not multi-GB sustained streams. But it does demolish the cultural argument that “UDP is for games and VOIP.” Once HTTP/3 runs on it, nobody can call UDP transport experimental anymore.

2018–2024 — The bandwidth-control thaw

Two other things happen during this stretch that matter for the modern shape of the category:

• BBR (Google, 2016) shows that TCP can be smarter about congestion control. It doesn’t catch up to UDP-based systems on long-haul links, but it raises the floor — TCP throughput on well-tuned modern kernels is materially better in 2024 than it was in 2014.
• Cloudflare’s R2 / edge network changes the cost model for serving files. The bandwidth-egress fees that made S3 expensive for transfer-heavy workloads are no longer the only option. Now you can architect a transfer service that uses Cloudflare for the relay path and pay roughly nothing for egress.

The second one is what makes 2025-era services possible at the price point they hit.

2025 — WarpSend

We didn’t invent the architecture. UDP transport, custom congestion control, packet packing, parallel streams — all of that was settled by 2003.

What we did is take that architecture and package it for the buyer the early winners didn’t serve: the four-person studio, the regional agency, the NAS-first business. Same protocol family. Cloudflare R2 as the relay backbone. $5/TB instead of $75,000/year.

Most of the engineering wins in this space were made before half our customers were born. The packaging is what was still missing.

Try it free — 1 TB / month, no card.