DEVBOOK

UDP

7 min read

Edit this pageReport / suggest

UDP (User Datagram Protocol) is a connectionless transport protocol that sends independent datagrams with no delivery guarantees. There is no handshake, no acknowledgment, no retransmission, and no ordering. You reach for it when lower connection-establishment and transport-retransmission overhead matters and the workload can define its own recovery: DNS retries lost queries, critical game or telemetry events add sequencing, acknowledgments, and bounded retries, while stale media or state samples can be dropped.

How It Works

UDP adds a minimal 8-byte header (source port, destination port, length, checksum) to the payload and sends it. The receiver either gets it or doesn’t. No state is maintained between sender and receiver.

sequenceDiagram
  participant Sender
  participant Receiver

  Sender->>Receiver: Datagram 1
  Sender->>Receiver: Datagram 2
  Note over Receiver: Datagram 3 lost — no retransmit
  Sender->>Receiver: Datagram 4

When to Use UDP

Real-time audio/video: a retransmitted audio packet from 200ms ago is useless — the conversation has moved on. Applications implement their own loss concealment (interpolation, FEC) rather than waiting for TCP retransmission.

Online gaming: game state updates (player positions, inputs) are time-sensitive. A missed update is replaced by the next one. Games implement their own reliability for critical events (hit registration) on top of UDP.

DNS: queries are small (fit in one datagram) and fast. If a query is lost, the client retries. The overhead of a TCP connection is not justified.

QUIC (HTTP/3): QUIC is built on UDP and implements its own reliable, ordered, multiplexed streams — getting TCP’s reliability without TCP’s head-of-line blocking.

Multicast / broadcast: UDP can send one datagram to many receivers — broadcast to a whole subnet, or multicast to a group that subscribed to a multicast address (224.0.0.0/4). TCP is strictly point-to-point and cannot do this. It’s used for service discovery (mDNS/Bonjour, SSDP), IPTV, and market-data feeds where one stream fans out to thousands of subscribers without the sender tracking each.

UDP Workloads and Their Recovery Layer

“Uses UDP” says nothing about how a workload handles loss:

WorkloadWhat UDP carriesMissing layer above UDP
Interactive mediaRTP media packets; or QUIC packets carrying reliable media-control/application streamsJitter buffer, sequence numbers, loss concealment/FEC; QUIC supplies ACKs, retransmission, encryption, and congestion control
DNSA query and response, usually with EDNS to advertise a larger UDP payloadClient timeout/retry; servers signal truncation for TCP fallback, and clients must support TCP
Market dataSequenced multicast feed updatesGap detection, duplicate suppression, snapshot/recovery channel; order-entry FIX sessions are separate reliable connections
IoT telemetry/controlSmall device reports or commandsMessage IDs, bounded retry, deduplication, authentication/encryption, and an expiry rule for stale commands

Generic “video streaming uses UDP” is too broad. RTP/WebRTC and QUIC-based delivery do; HLS and DASH segments are commonly fetched over HTTP on reliable transports. The reviewed use-case visual is excluded because it erases that distinction and labels a FIX client path as UDP multicast.

Reliability above UDP

A game can use two logical channels over one UDP socket:

snapshot: seq=104, player=(412,88)       drop if late; interpolate from 103 to 105
event:    id=580, seq=23, hit(target=7)  ACK with receive bitmap; retry before 80 ms deadline
event:    id=580                         duplicate after retry; acknowledge, do not apply twice

Snapshots are unreliable and replaceable. The receiver keeps a small sequence window, rejects packets older than the window, and interpolates through isolated gaps. Critical events are reliable but need not share one global order: sequence numbers expose gaps, selective ACKs report which events arrived, retransmission deadlines stop stale work, and stable event IDs make retries idempotent. If every event must be ordered, delivery pauses behind a missing earlier event—the same head-of-line cost TCP provides.

Reliability does not excuse an unpaced sender. Measure RTT and loss, cap bytes in flight, reduce the sending rate on congestion, and bound retransmissions. Also keep datagrams below the path MTU; IP fragmentation turns one missing fragment into a lost whole datagram. Use QUIC when you need secure, congestion-controlled reliable streams plus independent ordering. Use TCP when one reliable ordered byte stream is enough and UDP traversal or a custom protocol would add complexity without a latency benefit.

C# Example

// Sender
using var udp = new UdpClient();
var bytes = Encoding.UTF8.GetBytes("ping");
await udp.SendAsync(bytes, bytes.Length, "127.0.0.1", 9000);
 
// Receiver
using var server = new UdpClient(9000);
var result = await server.ReceiveAsync();
var message = Encoding.UTF8.GetString(result.Buffer);
Console.WriteLine($"Received: {message} from {result.RemoteEndPoint}");

Pitfalls

No congestion control UDP does not back off under network congestion. A UDP sender that floods the network can starve TCP connections sharing the same link. Applications using UDP for high-throughput transfers should implement their own congestion control (as QUIC does).

Datagram size limits For IPv4 with its minimum 20-byte header, the maximum UDP application payload is 65,507 bytes: the 65,535-byte IPv4 packet limit minus the IP and UDP headers. That number is not universal; IPv6 uses different payload accounting and has an optional jumbogram extension. In practice, keep each datagram below the measured path MTU—often roughly 1,200 to 1,400 bytes on Internet paths—because one lost IP fragment discards the entire datagram.

No built-in security UDP has no authentication or encryption. Use DTLS (Datagram TLS) for encrypted UDP, or build on QUIC which includes TLS 1.3.

Amplification / reflection attacks Because UDP is connectionless, the source address is trivially spoofed — there’s no handshake to prove the sender. An attacker sends a small query with the victim’s IP as the source to a server that returns a large response (DNS, NTP, memcached), and the server unwittingly floods the victim. The amplification factor (response ÷ request size) can be 50× or more, making UDP the basis of the largest DDoS attacks. Mitigations: rate-limit responses, disable open recursion/monlist, and deploy source-address validation (BCP 38) at the network edge.

Questions

References

Graph View

Backlinks