Explainer · 7 min read

What is UDP-accelerated file transfer?

How accelerated transfer protocols use UDP with their own rate control, block retransmission and encryption to move large files over long, lossy links, what they are not, and what to ask a vendor before believing a speed claim.

Author
RIPTON CLOUD team, Product and engineering
Technical review
RIPTON CLOUD engineering
Updated

Key takeaways

  • UDP itself is not faster; it is a blank slate that lets the protocol above it choose how to handle loss and pacing.
  • Accelerated transfer protocols add rate control, sequence tracking, selective retransmission, encryption and resume on top of UDP.
  • The gain is largest on long, lossy paths and near zero on a clean local link.
  • Ask for the test conditions behind any speed claim; a multiple without them is marketing.

UDP is not where the speed comes from

UDP is the minimal transport of the internet: it delivers packets, in any order, with no acknowledgement and no built-in reaction to loss. On its own it is unusable for moving a file. What makes an accelerated transfer product fast is the protocol built on top of it, which reimplements the parts of TCP that matter for bulk data while leaving out the behaviour that hurts on long paths.

What the protocol on top does

  • Paces sending at a controlled rate, usually adapting to measured loss or delay rather than halving on every drop.
  • Numbers every block so the receiver can report exactly what is missing.
  • Retransmits only the missing blocks, in parallel with new data, instead of stalling the stream.
  • Encrypts and authenticates each packet, since UDP has no equivalent of TLS built in.
  • Records progress so an interrupted transfer resumes from where it stopped.

RIPTON's RIPT protocol does all five: a UDP data plane with rate control and block-level negative acknowledgements, AES-256-GCM or ChaCha20-Poly1305 with a forward-secret key per session, per-subflow replay protection, and verified completion. IBM Aspera's FASP, Signiant's transport and FileCatalyst's protocol are other examples in the same family, each proprietary.

When it helps and when it does not

RouteSingle TCP streamAccelerated UDP transfer
Same building, clean linkNear link speedNear link speed; no meaningful gain
Cross-country, low lossA fraction of link speed on one streamClose to link speed
Intercontinental or lossy Wi-FiA few percent of link speedBounded by the link and the disks, not by the loss
Very many small filesPer-file round trips dominateDepends on whether files are packaged; RIPTON bundles directories into one stream

Questions to ask before believing a speed claim

  1. 1Against what baseline, on what path? A multiple is meaningless without the latency, loss and link speed of the test.
  2. 2Is the test reproducible? Ask for the commands and environment. RIPTON CLOUD publishes its EC2 test conditions for that reason.
  3. 3How is encryption handled, and can it be turned off? A protocol that allows plaintext will be run in plaintext somewhere.
  4. 4What happens on interruption? Resume from the last verified block, or restart?
  5. 5What does the other end need? A node, a desktop client, or only a browser?

Related

The only speed number that matters is the one from your path. A two-week proof of concept measures it against your current tool.

Test it on your route