A Brief History of Fast File Transfer: FTP, TCP, UDP, and QUIC
A short history of fast file transfer, from FTP and TCP limits to UDP-based congestion control, modern acceleration and reproducible benchmarks.
Moving a dataset between distant sites requires enough data in flight to use the connection, a way to recover from interruptions, and storage that can keep up. File-transfer systems have addressed those requirements through several approaches: larger TCP windows, parallel connections, application-level scheduling, and reliable transports built over UDP.
The history is useful when evaluating a product today. A protocol name describes only part of the system; file handling, congestion control, verification, and deployment determine how well it serves a particular workload.
1971–1985: FTP establishes a common file-transfer interface
Abhay Bhushan’s RFC 114, published on April 16, 1971, proposed a common interface for moving files between different computer systems. It predates TCP and describes an early design, rather than the FTP implementation used today.
The later RFC 959, published in 1985, defines the familiar separation between a control connection and data connections. A control session can serve many files. In common stream-mode transfers, however, each file closes its data connection, so moving a folder introduces repeated setup work. That overhead becomes more visible as round-trip time increases.
The 1990s: TCP supports larger amounts of data in flight
A high-bandwidth connection with a long round-trip time needs a correspondingly large window of unacknowledged data. TCP window scaling, introduced in RFC 1323 and updated in RFC 7323, allows receive windows larger than the original 16-bit field could represent. Selective acknowledgements, specified in RFC 2018, help a sender identify missing data during recovery.
TCP is a sliding-window protocol: it can send more data while earlier packets await acknowledgement. Window size, congestion control, packet loss, and endpoint capacity determine the resulting throughput. Its design does not impose a fixed percentage ceiling on long-distance transfers.
The 2000s: several approaches to WAN acceleration
UDT implemented reliable data transfer and congestion control over UDP for high-speed wide-area networks. The project’s technical papers describe the design, and its 2003 project report records a 6.8 Gbps Chicago-to-Amsterdam demonstration. That result belongs to the reported environment, not to every UDP connection.
Aspera FASP developed into a commercial approach to accelerated transfer. IBM describes FASP as using UDP for data movement with its own rate control and recovery behavior. Its value also includes the surrounding delivery, automation, and administration workflows. See the IBM Aspera overview.
GridFTP took a different approach. It extended FTP with features including parallel TCP connections and concurrent file transfers. Globus explains the distinction: parallelism divides data across connections, while concurrency distributes files across transfer processes. GridFTP therefore illustrates why acceleration cannot be reduced to a TCP-versus-UDP choice.
The 2010s: parallel TCP and new congestion controllers
Facebook’s open-source Warp Speed Data Transfer (WDT) uses multiple TCP paths and overlaps disk and network work. Its documentation reports high throughput between well-provisioned servers and explains the storage assumptions behind those results. It is a separate project from WarpSend.
TCP itself also continued to change. Google’s BBR deployment report describes a controller that estimates delivery rate and round-trip propagation time to regulate sending. A tuned TCP connection can perform well over distance; the controller and test conditions matter more than a blanket claim about the protocol.
2021: QUIC becomes an IETF standard
IETF RFC 9000 standardized QUIC as a secure, multiplexed transport over UDP. QUIC supplies reliable streams, flow control, and connection management. Its loss detection and congestion control are specified separately in RFC 9002.
This gives application developers another transport foundation. It does not guarantee that a QUIC-based transfer will beat a tuned TCP application. File enumeration, stream scheduling, encryption, storage, and resume behavior still have to be implemented and measured.
Managed delivery changes who needs to stay online
Cloud staging addresses a different constraint: the sender and recipient may not be available at the same time. A service can store a package after upload and serve later downloads without keeping the sender’s workstation online.
That convenience introduces storage, retention, access-control, and billing decisions. A direct endpoint route and a stored browser link can both be useful within one team, even when they use different transport paths.
Where WarpSend fits
WarpSend combines direct endpoint transfer, browser share links, file requests, and folder sync for supported Windows, macOS, Linux, and Synology devices. WarpDirect uses a direct tunnel when connectivity permits; managed Shuttle routing is available on a paid UDP speed plan after a direct-connectivity failure. WarpShare stages content for later browser downloads.
Compare the current releases using the same files, route, storage, and security settings. Record transfer-phase throughput separately from the time until the recipient has a verified copy. The WarpSend vs FTP benchmark method explains how to run that comparison; an FTP result does not establish performance against SFTP or Aspera.
Try WarpSend with a representative job. UDP endpoint speed plans and WarpShare upload billing are separate; see current pricing for the plan that matches the delivery method.