My IP Help

UDP

Also known as: User Datagram Protocol

User Datagram Protocol — a lightweight, connectionless transport protocol that delivers packets with minimum overhead but no reliability guarantees.

Last updated:

What is UDP?

UDP (User Datagram Protocol) is a connectionless, unreliable transport protocol defined in RFC 768 in 1980. Unlike TCP, UDP does not establish a connection before sending data, does not retransmit lost packets, does not enforce ordering, and does not check for duplicates. A UDP packet (called a datagram) is sent and forgotten. If the application needs reliability, it has to implement it on top.

That minimal design is exactly why UDP is preferred when latency, simplicity, or broadcast/multicast semantics matter more than guaranteed delivery.

What UDP is good at

  • DNS queries — the round-trip cost of a TCP handshake would double or triple DNS latency for queries that fit in one packet
  • Real-time media — a retransmitted video frame that arrives after its playback slot is worse than just dropping it
  • Voice calls and video conferencing (VoIP, WebRTC) — where older data is useless
  • Games — where the most recent position update matters far more than yesterday's
  • Broadcast / multicast — TCP cannot do either; UDP can
  • QUIC and HTTP/3 — Google's modern transport sits on UDP so it can implement its own improved congestion control and connection migration, bypassing ossified TCP behavior in middleboxes

UDP packet structure

A UDP datagram has an 8-byte header on top of the IP header:

| Field | Size | Purpose | |----------------|--------|---------| | Source Port | 2 bytes | Sender's port | | Destination Port | 2 bytes | Receiver's port | | Length | 2 bytes | Length of header + data | | Checksum | 2 bytes | Optional integrity check |

Compare that to TCP's 20+ byte header with sequence numbers, ACK numbers, flags, and window size. That's the overhead difference.

When TCP is the right choice instead

Use TCP when correctness matters — file transfer, web traffic, email, SSH. Use UDP when latency or simplicity matters more. HTTP/3 (QUIC) is an interesting middle ground: UDP transport, with TCP-equivalent reliability features built into the application layer.

Frequently Asked Questions

UDP itself does not retransmit lost packets, enforce ordering, or check for duplicates — so by the strict transport definition, yes, it is unreliable. But that does not mean applications using UDP are unreliable. DNS, QUIC, WireGuard, and many real-time protocols build their own reliability layers on top of UDP exactly because they want fine-grained control over which packets matter and which can be dropped.
Most DNS responses fit in a single packet, so the connection overhead of TCP (a three-way handshake before any data flows) would double or triple the latency for what is essentially a one-shot query/response. DNS still falls back to TCP for large responses (over 512 bytes traditionally, more with EDNS) and for zone transfers — but the everyday A/AAAA lookups happen over UDP port 53.
QUIC needed a transport that could implement its own connection state, encryption, congestion control, and connection migration without being mangled by middleboxes that have ossified TCP behavior over decades. UDP gave Google a clean slate — every router treats it as a generic packet and forwards it, leaving QUIC to define everything above. The result is faster handshakes (1-RTT or 0-RTT for resumed connections) and seamless connection migration when a phone switches Wi-Fi to cellular.
Yes — and unlike TCP, UDP does not detect or retransmit them. A lost UDP packet is simply gone. Applications that care must either tolerate the loss (a missing video frame is dropped from playback) or implement their own retransmission (DNS retries with a new query ID, QUIC retransmits with new packet numbers). On a healthy link inside a datacenter, UDP loss is near zero; over the open internet under congestion, it can spike to single-digit percentages.
For latency-sensitive single packets, yes — UDP avoids TCP's handshake (~1 round trip) and has a smaller 8-byte header vs. TCP's 20+. For bulk throughput, the answer flips — TCP's congestion control reaches near-line-rate, while naive UDP applications either underuse the link or overload it. Modern UDP-based protocols like QUIC run their own congestion control to match TCP's throughput while keeping UDP's lower per-packet overhead.
Back to glossary