UDP
User Datagram Protocol · Transport layer
UDP adds just enough to IP to get data to the right program: a source and destination port, a length, and an optional checksum. It adds no handshake, no retransmission, no ordering and no flow control. Anything an application needs beyond best-effort delivery, it must build itself — which is exactly the trade DNS and video streaming want.
Understand these first
- Why does this protocol exist?
- IP delivers to a machine, not to a program. Some applications need only that one addition and want nothing else — no handshake, no retransmission, no ordering.
- Which problem does it solve?
- Get a datagram to the right program on the right machine, with a checksum, and get out of the way.
- Who participates?
- Two endpoints identified by ports. Usually client and server, but there is no connection, so nothing in the protocol enforces the roles.
- Which layer uses it?
- Transport layer. Carried in IP with protocol number 17.
- What does it depend on?
- IPv4 for delivery. Nothing else — the header is eight bytes.
- What depends on it?
- DNS, DHCP, and QUIC (and therefore HTTP/3). Anything that wants to control its own reliability instead of inheriting TCP's.
- What state does each participant maintain?
- None. No connection exists, so there is nothing to set up, time out, or tear down. Any state belongs to the application above it.
- Which fields matter?
- srcPort / dstPort — The only reason UDP exists over raw IP. They pick the program.
- length — Header plus payload. UDP preserves datagram boundaries, unlike TCP, so this is a real message length.
- checksum — Covers a pseudo-header of the IP addresses too, so a misdelivered datagram is detected. Optional in IPv4, mandatory in IPv6.
- What does normal behaviour look like?
- A datagram out, possibly a datagram back, with nothing in between. Boundaries are preserved: one send is one datagram is one receive.
- What does failure look like?
- Nothing. A lost datagram produces no retransmission, no error, and no notification — the application simply waits and must decide for itself when to retry or give up. A closed port produces ICMP port unreachable, which is the one case UDP does get told about.
- How can I prove the diagnosis from packets?
- Count requests against responses. A repeated identical query with no answer is the application retrying, and that pattern is the evidence of loss — UDP itself will never say so.
- How does it interact with the rest of the stack?
- It is the thinnest useful layer over IP, and that is the value. QUIC was built on UDP rather than on TCP precisely so it could implement its own reliability and congestion control, which is why 'UDP is faster' is a misleading summary of 'UDP gets out of the way'.
Guided course — 4 lessons
Read in order. Every lesson pauses the capture on the packets it is talking about, and every one reads at three levels — so the time below is an estimate from the number of steps, not a measurement of anybody.
- 1UDP-01UDP: What You Don't GetEight bytes of header, and everything else is your problem≈10 min · 8 steps · 4 questions · guided · diagnosis labNot started
- 2UDP-02The Eight-Byte HeaderFour fields, and one of them reaches down a layer≈15 min · 8 steps · 3 questions · guided · after udp-what-you-dont-getNot started
- 3UDP-03What Arrives, and What Does NotThe one guarantee UDP gives, and the five things it does not≈10 min · 7 steps · 3 questions · guided · after udp-the-eight-byte-headerNot started
- 4UDP-04Talking to EverybodyBroadcast, multicast, and why only UDP can do this≈10 min · 7 steps · 3 questions · guided · after udp-what-you-dont-getNot started
Troubleshooting labs — 1
A symptom, a capture, and no answer given. Each one is a lesson from the course above, listed again here because the diagnosis is worth coming back for.
Packet explorer — 7 scenarios, no coaching
No handshake, no setup, no teardown — the very first packet carries the data. Compare this with TCP, where three packets go by before a single byte of yours moves.
Boundaries are preservedThree separate sends produce exactly three datagrams, each delivered whole or not at all. This is the one guarantee UDP makes that TCP does not.
A datagram is lost and nobody noticesThe middle datagram vanishes. There is no acknowledgement to be missing, no timer to fire, no retransmission. The sender's application believes all three were sent — and it is right, they were.
Out-of-order deliveryThe first datagram is delayed past the others, so the application reads them in the wrong order. UDP has no sequence numbers, so it cannot even detect this — let alone fix it.
Nothing is listeningA datagram arrives for a port with no socket. The host does not stay silent: it answers with ICMP port-unreachable, quoting the datagram that caused it.
Broadcast to the whole segmentOne datagram addressed to 255.255.255.255 reaches every host on the wire at once. This is how a machine with no address yet can still ask for one — the mechanism DHCP depends on.
A datagram too big for one packetA 1200-byte datagram is larger than the link can carry, so IP fragments it. UDP itself does nothing — and if one fragment is lost, the whole datagram is discarded.
Reference material
The terms this module introduces, and the specifications behind them. Both lists come from the lessons themselves rather than from a list kept beside them.
That you can say precisely what UDP leaves out, and resist the summary that it is simply 'faster'.