UDP and when to use it

Why it matters

TCP is the right default, but some of the most important traffic on the internet is not TCP: every DNS lookup, every video call, most online games, and, through QUIC, a large and growing share of web traffic. Knowing what UDP gives up and what that buys lets you recognise when TCP's guarantees are the problem rather than the solution, and what you take on when you step away from them.

The idea

UDP sends independent datagrams: each one is addressed to a port, carries a checksum, and is delivered whole or not at all. That is the entire service. No handshake, no connection state, no acknowledgements, no retransmission, no ordering, no flow control, no congestion control. Its 8-byte header holds source port, destination port, length and checksum.

When UDP is the right choice

1. 1

   Tiny request-reply

   DNS asks one question in one datagram and gets one answer. A TCP handshake would triple the cost; a lost query is simply retried by the client after a short timeout.
2. 2

   Real-time media and games

   For a video call or a game, data that arrives late is worthless. Retransmitting a lost audio frame and stalling everything behind it (TCP's behaviour) is worse than skipping it. Protocols like RTP over UDP tolerate loss and conceal it.
3. 3

   Building a better transport

   QUIC implements reliability, per-stream ordering, congestion control and encryption in user space over UDP, so it can evolve without waiting for operating system kernels and middleboxes. HTTP/3 runs on it.
4. 4

   Broadcast and multicast

   Service discovery and some market-data feeds send one datagram to many receivers, which a connection-oriented protocol cannot do.
5. 5

   High-rate telemetry where loss is acceptable

   Metrics such as StatsD send fire-and-forget counters, accepting occasional loss in exchange for zero blocking in the application.

What you must build yourself

Anything beyond best-effort delivery is the application's job: timeouts and retries for request-reply, sequence numbers to detect loss and reorder, forward error correction or concealment for media, and above all pacing. A UDP sender that ignores congestion will happily flood a link and harm every other flow on it; well-behaved UDP protocols (QUIC, WebRTC) include congestion control for exactly this reason. Datagram size matters too: keep payloads under about 1,200 to 1,400 bytes so they fit the path MTU without fragmentation, which is unreliable for UDP.

Operational traps

UDP has no back-pressure, so a receiver that cannot keep up drops datagrams silently in its socket buffer; check the kernel's receive-error counters. Stateful middleboxes (NATs, firewalls) expire UDP mappings quickly, often in 30 seconds, so long-lived UDP flows need keepalives. And because UDP needs no handshake, source addresses can be spoofed: open UDP services that send large replies to small requests (old DNS resolvers, memcached, NTP) have been abused for amplification attacks, reflecting enormous floods at a victim. Never expose such services to the internet without rate limits and source validation.

Trade-offs

UDP buys minimal latency, no head-of-line blocking, message boundaries and freedom to design your own reliability, at the cost of implementing everything you need yourself, being responsible for not congesting the network, and handling silent loss, NAT timeouts and abuse. Most applications should use TCP, or QUIC through an HTTP/3 library, rather than raw UDP.

In an interview

Choose by tolerance for late data: "Voice and video go over WebRTC, which runs on UDP, because a late frame is useless and retransmission would add lag; the client conceals loss and the stack adapts bitrate to congestion. Everything transactional stays on TCP or HTTP/3." If asked why HTTP/3 uses UDP, say it is to escape TCP's head-of-line blocking and ossified kernels and middleboxes, not because reliability is unwanted.