skip to content

A team wants to move a bulk file-sync service from TCP to UDP because "UDP is faster". What does that claim miss, and what must the UDP design rebuild?

level: seniorimportance: should knowfreq 34%

answer

  1. same links, same bytes
  2. one round trip, paid once
  3. everything TCP did, now yours
  4. RFC 8085 on bulk senders

basics

~20 s

UDP is not faster per byte; it only skips the handshake and the wait for retransmissions, which barely matter for bulk transfer. A reliable UDP file sync must rebuild sequencing, acknowledgement, retransmission, duplicate handling, flow control, congestion control and message sizing.

solid answer

~40 s

Both protocols use the same links; UDP saves a one-time handshake round trip and TCP's in-order waiting, neither of which matters much for a long transfer, where RFC 8085 notes TCP's capacity probing quickly compensates for setup delay. A file must arrive complete, so the UDP design needs chunk numbering and reordering, acknowledgements and retransmission with RTT estimation and backoff, duplicate detection, receiver flow control, and datagrams sized under the path MTU. RFC 8085 makes reliability and ordering the application's job (MUST, when it needs them) and says bulk senders SHOULD implement TFRC or TCP-like congestion control. A prototype that looks faster usually just ignores congestion. RFC 8085 recommends using an IETF transport such as TCP instead; UDP pays off when TCP's contract is wrong, such as partial reliability or independent streams.

go deeper

for a junior

Remember that UDP is not faster per byte; it only skips the handshake and retransmission waits, which a big file transfer barely notices.

for a middle

List what a reliable UDP protocol must add: sequence numbers, acknowledgements, retransmission timers, duplicate handling and flow control.

for a senior

Cite RFC 8085's congestion-control and message-sizing guidance, and diagnose a benchmark where an unresponsive UDP sender only appears to win.

for a principal

Judge whether owning a custom transport is ever worth it for the organisation, compared with TCP or QUIC, given review, tuning and fairness obligations over years.

## What "faster" actually means UDP does not move bytes faster. Both protocols put packets on the same links, and UDP's header is 8 bytes against TCP's 20-byte minimum. What UDP removes is: - the **handshake round trip** before data is delivered, - **waiting** for a retransmission before later data is released, - **congestion control** slowing the sender. The first matters for tiny exchanges; the second for real-time data. For a bulk file sync neither helps much: the handshake costs one round trip once, and RFC 8085 notes that TCP's capacity probing and PMTU awareness "quickly compensates for the initial connection setup delay" for transfers of more than a few segments. Throughput on a long transfer is set by the path's capacity and by congestion control. The third item is the dangerous one: a UDP sender that looks faster because it never backs off is taking capacity from every other flow on the path. ## What a file-sync protocol on UDP must rebuild A file must arrive complete and correct, so the design has to recreate most of TCP: 1. **Sequencing.** Number every chunk so the receiver can reassemble and find gaps. RFC 8085 section 3.3: applications that require ordered delivery "MUST reestablish datagram ordering themselves". 2. **Acknowledgement and retransmission.** "Applications that do require reliable message delivery MUST implement an appropriate mechanism themselves." 3. **RTT estimation and timer backoff.** RFC 8085 recommends an initial latency estimate of 1 second, as RFC 6298 does for TCP, and backing off retransmission timers after loss. 4. **Duplicate handling.** UDP has no duplicate protection. RFC 8085 says applications SHOULD be robust to delayed or duplicate datagrams arriving within 2 minutes, TCP's Maximum Segment Lifetime. 5. **Flow control.** The receiver's buffer must not be overrun by a fast sender. 6. **Congestion control.** RFC 8085 section 3.1.2: bulk-transfer applications SHOULD implement TFRC, window-based TCP-like congestion control, or a scheme that competes fairly with TCP within an order of magnitude. Retransmissions count too: "Any application that uses retransmission is responsible for congestion control of its retransmissions." 7. **Message sizing.** Datagrams SHOULD NOT produce IP packets larger than the path MTU. Without path MTU discovery, packets stay within the default effective MTU for sending (the smaller of 576 bytes and the first-hop MTU for IPv4; 1280 bytes for IPv6), and the payload is that size minus the IP header and the 8-byte UDP header. How IP fragments an oversize packet belongs to the fragmentation topic. Each item is well understood, and each is easy to get subtly wrong. RFC 8085 says so itself: these mechanisms "are difficult to implement correctly". ## RFC 8085's own recommendation RFC 8085, the UDP Usage Guidelines (Best Current Practice, BCP 145), states that the **RECOMMENDED** alternative to building these mechanisms on UDP is an IETF transport such as TCP, SCTP or DCCP, and that full-featured transports "are not as 'heavyweight' as often claimed". Note the requirement levels: the reliability and ordering rules are MUST for applications that need those properties; the congestion-control rules for bulk transfer are SHOULD. For a design reviewer that SHOULD is not optional in practice: an unresponsive bulk sender can drive a shared path toward congestion collapse, and RFC 8085 says uncontrolled modes SHOULD NOT be enabled by default. ## When the rebuild is worth it | Reason | Example | Why TCP's contract does not fit | |---|---|---| | Partial reliability | Voice, game state | Some data should be dropped, not retransmitted | | Independent streams | QUIC (RFC 9000) | One loss on a TCP connection blocks everything behind it | | Broadcast or multicast | Local discovery | TCP supports unicast only | | Tiny request and response | DNS | The handshake doubles the latency | There is also a deployment reason: RFC 8085 notes that a protocol with a new IP protocol number meets middleboxes that only support TCP and UDP, which is why new transports are built on UDP rather than beside it. A bulk file sync fits none of these rows. That is the core of the answer. ## Reading a "UDP won the benchmark" result If a UDP prototype beats TCP in a test, ask first whether it has congestion control. A sender that ignores loss can win on an idle lab link and then hurt every other flow on a shared production path. Then ask whether it actually delivered every byte, and what it did with duplicates and reordering. Most such results measure a protocol that has not yet rebuilt what TCP does.

  • When is building on UDP the right call despite all that work?
    When TCP's single reliable in-order stream is the wrong contract: real-time media and game state that should drop late data, many independent streams that must not block each other on one loss (QUIC, RFC 9000), broadcast or multicast, or a one-round-trip lookup. RFC 8085 also notes that new IP protocol numbers meet middleboxes that only pass TCP and UDP, so new transports are layered on UDP.
  • How large should each datagram in the UDP design be?
    RFC 8085 says applications SHOULD NOT send datagrams whose IP packets exceed the path MTU. It recommends path MTU discovery; without it, stay within the default effective MTU for sending, the smaller of 576 bytes and the first-hop MTU for IPv4, or 1280 bytes for IPv6, after subtracting the IP header and the 8-byte UDP header. Oversize datagrams otherwise depend on IP fragmentation, which RFC 8085 says should be avoided.

saying these in an interview costs you the question

  • UDP moves bytes faster because its header is smaller
  • A UDP sender needs no congestion control because UDP has none
  • The UDP checksum stops duplicate datagrams reaching the application
  • Large datagrams are fine because IP fragmentation handles them reliably
  • A UDP prototype that beats TCP in the lab proves the design is better