What does UDP leave out that TCP provides, and what does an application actually see when a datagram is lost, duplicated or reordered?
answer
- almost a null protocol
- ports plus a checksum
- silence, not an error
- copies and wrong order reach the app
- RFC 8085 section 3.3
basics
~20 sUDP adds only port multiplexing and a checksum to IP: no delivery guarantee, retransmission, ordering, duplicate suppression, flow control or congestion control. A lost datagram simply never arrives; duplicates and reordered datagrams reach the application as they come.
solid answer
~40 sRFC 768 says it outright: delivery and duplicate protection are not guaranteed. UDP gives an application two things over IP — port numbers to reach the right process and a checksum — and nothing else. So a lost datagram produces no error on either side; it is simply absent. A datagram the network duplicates is delivered twice, and datagrams that take different paths can arrive in a different order than they were sent. A datagram whose non-zero checksum fails is silently discarded, so corruption also looks like loss. RFC 8085 puts the burden where it lands: an application that needs reliable or ordered delivery MUST build it itself, and it SHOULD handle duplicates gracefully — or it should use a transport that already provides these.
go deeper
Recall what UDP omits: delivery, retransmission, ordering, duplicate protection, flow control and congestion control. Say plainly that loss is silent.
Explain what each omission looks like at the receiver, including checksum failures surfacing as loss and duplicates coming from a retried request.
Show you design for it: sequence numbers, idempotent handlers, timeouts, and tolerance for datagrams arriving up to minutes late, as RFC 8085 recommends.
Treat the omissions as a contract: the application chooses which guarantees to pay for, and every one rebuilt in-house is code, latency and congestion responsibility the team now owns.
## What UDP actually is The **User Datagram Protocol** (RFC 768) lets an application send a message — a **datagram** — to a process on another host "with a minimum of protocol mechanism". The same page states the limit plainly: *delivery and duplicate protection are not guaranteed*, and applications that need ordered, reliable delivery of a stream should use TCP. RFC 1122 §4.1.1 calls UDP "almost a null protocol": the only services it adds to IP are **checksumming** of data and **multiplexing by port number**. Everything else a connection-oriented transport does — retransmission, reassembly into order, flow control, congestion avoidance — is left to the application "when these are required". ## The guarantees it leaves out | Property | TCP | UDP | Who handles it on UDP | |---|---|---|---| | Delivery | retransmits until acknowledged or the connection fails | none | the application, if it needs it | | Ordering | in-order byte stream | none | the application re-orders | | Duplicate protection | sequence numbers discard repeats | none | the application detects repeats | | Flow control | receiver advertises a window | none | the application paces or tolerates drops | | Congestion control | built in (RFC 5681 and successors) | none | the application (RFC 8085 §3.1) | | Integrity | checksum | checksum (optional over IPv4) | the transport | | Message boundaries | none — a byte stream | preserved | the transport | The last two rows matter: UDP is not "TCP with everything removed". It keeps each datagram whole, which TCP does not. ## What the application actually observes The key point interviewers look for is that UDP's failures are **silent**. Nothing in the protocol reports them. - **Loss.** A datagram dropped by a congested router, a full receive buffer or a bad link simply never arrives. The sender's send operation already succeeded, because success only meant the datagram left the local stack. The receiver has no way to know it was ever sent. - **Corruption.** RFC 1122 §4.1.3.4: a datagram whose checksum is non-zero and invalid MUST be silently discarded. So corruption surfaces as loss, never as a damaged message. - **Duplication.** The network can deliver two copies of one packet, and UDP has no sequence numbers to notice. RFC 8085 §3.3 warns that duplicates can arrive "potentially much later than the first". Just as often the "duplicate" is the application's own retry of a request whose original was only slow. - **Reordering.** Routing transients, mobility and load balancing across equal-cost paths can deliver datagrams in a different order than they were sent. UDP hands them up in arrival order. - **Nobody listening.** The one case with a signal: RFC 1122 §4.1.3.1 says a host SHOULD answer a datagram for a port with no listener with an **ICMP Port Unreachable**, and §4.1.3.3 says UDP MUST pass ICMP errors up to the application. That error arrives asynchronously and can be filtered on the way, so its absence proves nothing. ## How late is "late"? There is no protocol bound on how long a datagram can be delayed or when a duplicate can still show up. RFC 8085 §3.3 notes that no RFC defines a maximum lifetime for IP or UDP, and recommends borrowing TCP's **Maximum Segment Lifetime** of 2 minutes (RFC 9293): applications SHOULD be robust to delayed or duplicate datagrams received within that interval. In practice most arrive in milliseconds, but a design that assumes "late means lost" will eventually be surprised. ## What this means when you design on UDP RFC 8085 §3.3 turns the omissions into obligations: 1. An application that requires reliable delivery **MUST** implement an appropriate mechanism itself — typically sequence numbers, acknowledgements and timeouts. 2. An application that requires ordered delivery **MUST** re-establish ordering itself. 3. Applications **SHOULD** handle duplicates gracefully, and may need duplicate detection even when the operations are idempotent, simply to shed load. 4. Any retransmission is traffic too, so it falls under the application's congestion control. The same section adds the pragmatic advice: an application that needs reliable, ordered delivery SHOULD, where possible, choose an IETF transport that already provides it. Many UDP applications need none of this: a lost sample in a live stream or a stale position update is better skipped than waited for. The skill being tested is knowing precisely which guarantees are absent, what each absence looks like at the receiver, and that none of them announces itself.
- If UDP never reports loss, how can a UDP application learn that datagrams are going missing?Only through its own protocol. Numbering datagrams lets the receiver spot gaps and repeats; replies or acknowledgements let the sender time out and retry. The one transport-level signal is an ICMP error such as Port Unreachable when nothing listens. It arrives asynchronously, may be filtered, and never reports a datagram dropped by a congested router or a full receive buffer.
- Where do duplicate UDP datagrams come from if the sender sent each one once?The network can deliver a packet twice — during a routing transient, for example — and UDP has no sequence numbers to spot the second copy. More often the duplicate is the application's own retry of a request whose original was merely slow. RFC 8085 §3.3 warns that duplicates may arrive much later than the first copy, so dedupe windows need slack.
saying these in an interview costs you the question
- The sender gets an error back when a UDP datagram is lost in the network.
- UDP retransmits a few times before giving up, just fewer than TCP.
- Datagrams from one sender to one receiver always arrive in send order.
- Duplicates cannot happen over UDP because the sender sent each datagram once.
- A UDP datagram with a bad checksum is delivered to the application flagged as damaged.