1st Principles
Menu

Networking · 30 min read

UDP

A minimal transport: multiplex apps with ports, deliver datagrams, and leave reliability, ordering, and congestion response to the application when that is the right tradeoff.

Why this exists

Not every application wants a reliable ordered byte stream. Some need low latency, custom recovery, message boundaries, or the ability to innovate above a simple datagram primitive.

UDP provides just enough transport to name applications (ports) and send datagrams over IP, without pretending the network is a perfect pipe.

The modern twist: major new transports (QUIC) ride over UDP to survive middleboxes that ossified around TCP. UDP is both a simple tool and an escape hatch.

Axioms & primitives

  1. 01UDP is connectionless: no handshake required before sending.
  2. 02A UDP datagram is a message with length; it may arrive once, never, duplicated, or reordered relative to others.
  3. 03Ports multiplex many applications on one host.
  4. 04UDP does not provide congestion control; responsible apps or upper protocols must.
  5. 05Checksums catch some corruption; they do not create reliability.
  6. 06Message boundaries are preserved for datagrams that arrive intact; TCP does not offer that.

Learning objectives

After this lesson you should be able to:

  • Contrast UDP's guarantees with TCP's in a short table of properties.
  • Explain why DNS and many realtime media systems use UDP.
  • Describe a situation where 'faster because UDP' is a misleading slogan.
  • Sketch how an application might add sequence numbers and retransmission on top of UDP.
  • State why QUIC's choice to run over UDP is strategic, not accidental.

Progressive depth

Read the layers in order for a full explanation. Or open the layer you need.

01

Intuition

TCP is a careful phone call. UDP is a stack of postcards. If you need 'did you get it?' you write that into your own protocol or accept silence.

That sounds worse until you watch a video call: a frame that arrives late is trash. Skipping beats freezing the whole conversation for a retransmission.

DNS historically chose UDP for small queries because the cost of a handshake and stream machinery was silly for a tiny question that can simply be retried.

02

Formal shape

UDP header: source port, destination port, length, checksum. No sequence numbers, no window, no congestion state in the base protocol.

Demultiplexing uses the destination port (and often the 4-tuple with IPs). ICMP messages may report unreachable destinations; many networks filter them.

Upper protocols add structure: DNS queries/responses, QUIC packets, RTP media timestamps, custom game protocols. Each must decide about loss, reorder, duplication, and pacing.

Size matters: keep datagrams modest to avoid IP fragmentation. IPv6 makes fragmentation even less pleasant for senders who ignore PMTUD.

03

Worked examples

DNS resolvers traditionally send UDP queries first (with TCP fallback for large responses or truncation). A lost query is simply retried, sometimes to another resolver.

QUIC runs a full modern transport (streams, crypto, congestion control) over UDP to navigate middleboxes that allow UDP but ossify TCP.

A naive UDP file transfer that never backs off can harm the network; good designs mimic or borrow congestion control (or use a library that already does).

Realtime: encode media with timestamps; prefer latest frame over perfect archival integrity; optionally retransmit only critical keyframes.

04

Edge cases

UDP hole punching interacts with NAT mappings. Symmetric NATs may force TURN relays.

Checksum optional quirks in IPv4 history matter less today; IPv6 requires UDP checksums.

Broadcast/multicast patterns appear more naturally with datagram models than with TCP streams, with their own operational hazards.

Amplification: a 60-byte spoofed query that triggers a 3KB response is a weapon. Services must authenticate, rate-limit, or keep responses small.

Mental models

  • Postcard

    Cheap, no delivery confirmation, order not guaranteed. Write carefully; accept loss.

  • Fire hose with labels

    You can spray messages quickly with port labels. You are responsible for not flooding the city and for noticing missing drops.

  • Toolbox, not product

    UDP is a primitive. QUIC, RTP, and DNS build products on top.

  • Escape hatch past ossification

    Middleboxes that only understand old TCP still forward UDP. Innovators hide new transports inside.

Common misconceptions

  • Myth

    UDP is always faster than TCP.

    Reality

    UDP avoids TCP's machinery, but loss, overload, and application-level retransmission can make a UDP design slower or unfair. Speed depends on the whole design.

  • Myth

    UDP is unreliable, so it is useless.

    Reality

    Unreliable means 'no built-in repair.' That is a feature when repair would hurt (late video frames) or when the app has a better repair strategy.

  • Myth

    UDP has no security implications.

    Reality

    Amplification attacks abuse UDP services that respond more bytes than they receive. Design and operators must rate-limit and authenticate.

  • Myth

    If I use UDP, I can ignore congestion.

    Reality

    The network still has finite queues. Unpaced UDP can harm everyone including yourself; good designs share the path fairly.

Exercises

Work these without looking up answers first. Check yourself against the intent notes.

  1. Exercise 01

    Would you choose UDP or TCP for (a) bank transfers, (b) live voice, (c) a one-shot 'is this host alive' probe? Justify each.

    What good looks like

    a TCP (or app reliability), b UDP/realtime, c often UDP/ICMP-like probes.

  2. Exercise 02

    An app sends 100 UDP datagrams; 97 arrive, two are duplicated, one is reordered. What must the app do if it needs an exact once-ordered file?

    What good looks like

    Detect dupes, reorder with sequence numbers, request or retransmit missing pieces; essentially rebuild reliability.

  3. Exercise 03

    Why might a game company prefer QUIC or a custom UDP protocol over raw TCP for realtime state, even if they still need some reliability?

    What good looks like

    Avoid head-of-line blocking across independent messages; control which losses are repaired; manage latency explicitly.

Sources & further reading

External references. Prefer primary documents and clear explainers.

Go deeper on your own

These picks go past the foundation in this lesson. Use them when you want a primary spec, official docs, or a longer walkthrough.