UDP Explained: Header, How It Works, Real Uses

Section 01

UDP — The Minimalist of the Transport Layer

📖 Real World Analogy

Shouting Across a Busy Market vs Sending a Registered Letter

Imagine two ways to tell someone across a crowded market that lunch is ready. You could shout it — fast, zero effort, no confirmation, and if they did not hear you, you simply shout again. Or you could write a registered letter with a tracked courier, signed delivery confirmation, and a guaranteed arrival time.

The registered letter is TCP. The shout is UDP. Neither is wrong — they serve completely different situations. The registered letter is absurd for "lunch is ready." The shout is absurd for a legal contract.

Every time you ask Alexa a question, play an online game, make a video call, or your browser resolves a domain name — you are using the shout. UDP carries more Internet traffic than most people realise, precisely because its simplicity is its superpower.

UDP (User Datagram Protocol), defined in RFC 768 (1980), is one of the two main transport-layer protocols alongside TCP. Where TCP provides reliable, ordered, flow-controlled delivery through a complex state machine, UDP provides exactly one thing beyond raw IP: port-based demultiplexing so the OS knows which application to hand the packet to. Everything else — reliability, ordering, retransmission, flow control — is left entirely to the application developer.

📌

The Design Philosophy: Radical Simplicity

Jon Postel designed UDP in just 3 pages. The entire specification is shorter than the TCP error-handling section alone. The premise: if the application knows better than the transport layer what guarantees it needs — get out of the way. A live video stream does not need retransmission — a late frame is worse than a missing one. A DNS query does not need a 3-way handshake — it just needs to ask one question and get one answer. UDP lets applications do exactly what they need, nothing more.

📶 UDP Core Properties at a Glance

Connectionless

No handshake, no state, no setup. Send immediately. The first datagram carries real data — not negotiation overhead.

Unreliable

No acknowledgements, no retransmission, no duplicate detection. Packets may be lost, reordered, or duplicated. The application decides how to handle this.

Unordered

Datagrams may arrive in a different order than they were sent. No sequence numbers. Applications that need ordering must implement it themselves (RTP does this for media streams).

Lightweight

8-byte header vs TCP's 20–60 bytes. No connection state per-flow — a server can handle millions of UDP clients without keeping per-connection memory. Critical at DNS scale.

Broadcast / Multicast

UDP supports sending one packet to all machines on a subnet (broadcast) or a subscribed group (multicast). TCP's point-to-point model makes this structurally impossible. DHCP, routing protocols, and mDNS depend on this.

Low Latency

No round-trip for setup, no wait for ACK before sending next datagram, no head-of-line blocking. Latency is bounded only by the network — not by the protocol. Online gaming requires sub-20ms reaction; TCP's retransmission delays are unacceptable.

Section 02

The UDP Header — Just 8 Bytes, Every Bit Matters

The UDP header is the smallest possible header that still makes a transport protocol functional. At exactly 8 bytes (64 bits), it contains only four fields — each 16 bits wide. Compare this to TCP's 20–60 byte header with 11 fields and a complex options mechanism. That 12-byte difference matters enormously at scale: a DNS server handling 10 million queries per second saves 120 MB/s of header overhead compared to TCP.

📋 UDP Header — Interactive Field Diagram (Click to Explore)

👉 Click any field in the diagram above

UDP has only four fields — each 16 bits wide. Together they are exactly 64 bits (8 bytes). Click each coloured field to understand what it does and why it exists.

💡 The entire UDP header is one 32-bit row repeated twice: Row 1 = Source Port + Destination Port. Row 2 = Length + Checksum. This means the header can be parsed in a single 64-bit read on modern hardware — contributing to UDP's speed.

Field Reference Table

Field	Size	Offset	Optional?	Purpose
Source Port	16 bits	Byte 0	Optional (can be 0)	Identifies the sending application. Set to 0 if the sender needs no reply.
Destination Port	16 bits	Byte 2	Required	Routes the datagram to the correct socket on the receiver. The demultiplexing key.
Length	16 bits	Byte 4	Required	Total datagram size in bytes (header + data). Min = 8. Max = 65535.
Checksum	16 bits	Byte 6	Optional IPv4, mandatory IPv6	One's complement error detection. Covers header + data + IP pseudo-header.

Section 03

UDP vs TCP — When to Use Each

📤 UDP — Choose When

Scenario	Why UDP Wins
Live video / VoIP	Late retransmit is worse than a missing frame
DNS queries	One request, one reply — handshake is wasteful
Online gaming	Sub-20ms latency — TCP retransmit kills it
DHCP / BOOTP	Must broadcast — TCP cannot broadcast
IoT telemetry	Fire-and-forget sensor readings, no ACK needed
QUIC / HTTP/3	Builds own reliability in user space over UDP

📥 TCP — Choose When

Scenario	Why TCP Wins
Web browsing (HTTP/1,2)	Every byte of HTML/CSS/JS must arrive
File transfer (FTP/SFTP)	A missing byte corrupts the file
Email (SMTP/IMAP)	Messages must arrive complete and in order
Database queries	Partial result is worse than no result
SSH / remote shell	Every keystroke must arrive in exact order
API calls (REST/gRPC)	Request/response integrity is non-negotiable

Feature	UDP	TCP
Header size	8 bytes (fixed)	20–60 bytes
Connection setup	None (0 RTT)	3-way handshake (1.5 RTT)
Reliability	None (app handles it)	Guaranteed delivery
Ordering	No guarantee	In-order delivery
Flow control	None	Receiver window (rwnd)
Congestion control	None (can flood network)	Slow Start / CUBIC / BBR
Broadcast / Multicast	Supported	Not supported
State per connection	None (stateless)	~1–4 KB per socket
Latency	Network RTT only	RTT + ACK + possible retransmit
Head-of-line blocking	None	Yes (a lost packet blocks all that follow)

Section 04

🏭 Animated: How a UDP Datagram Travels — DNS Example

DNS is the most ubiquitous user of UDP. Every time you type a URL, your device sends a UDP datagram to port 53 of a DNS resolver, and (usually within 1–50ms) receives a UDP datagram back with the answer. No handshake, no state — just one question and one answer. Let's watch it happen.

▶ UDP Datagram Flow — DNS Query (No Handshake, No ACK)

Ready

💡 Notice there is no connection phase. The very first UDP datagram carries the DNS query. Compare this to TCP: HTTPS requires a TCP handshake (1 RTT) + TLS handshake (1–2 RTTs) before the first byte of data is sent — total 2–3 RTTs of setup before your browser even starts downloading.

Section 05

🏭 Animated: UDP Use Cases — VoIP, Gaming, Streaming

Different applications tolerate packet loss in fundamentally different ways. The animation below shows three simultaneous UDP flows — VoIP, online gaming, and live video — and what each does when a packet is lost.

▶ Three UDP Flows — How Each Handles Packet Loss Differently

💡 All three applications use UDP for the same core reason — they prefer a small gap over a late delivery. A VoIP packet retransmitted 200ms late is not speech any more. A game position update retransmitted 100ms late shows a ghost of where the player was. A video frame retransmitted 40ms late freezes the stream. Loss ≠ failure when timeliness matters more than completeness.

Section 06

UDP in Practice — Applications & Well-Known Ports

📌

DNS — Domain Name System

UDP port 53. Every domain resolution starts as a single UDP datagram. The root DNS servers collectively handle over 1 trillion queries per day — UDP's statelessness is the only reason this is possible at that scale. TCP is used only when the response exceeds 512 bytes (zone transfers, DNSSEC), signalled by setting the TC (truncation) bit in the UDP response.

Port 53 | RFC 1035 | ~1 trillion queries/day globally

🔌

DHCP — Dynamic Host Configuration

UDP ports 67 (server) and 68 (client). DHCP must use UDP because a new device has no IP address yet — it cannot form a TCP connection. It broadcasts a DHCP Discover on 255.255.255.255:67. Without UDP broadcast support, your phone could never automatically get an IP address when joining a Wi-Fi network.

Port 67/68 | RFC 2131 | Requires UDP broadcast

🕑

NTP — Network Time Protocol

UDP port 123. Synchronises clocks across the Internet to within microseconds. NTP sends a single UDP timestamp request and receives a single UDP reply. The round-trip time is used to calculate clock offset. Using TCP would add connection setup latency that corrupts the precision of the measurement itself — a neat catch-22 that makes UDP mandatory.

Port 123 | RFC 5905 | Sub-microsecond accuracy

🎧

VoIP & RTP — Real-Time Media

RTP (Real-time Transport Protocol, RFC 3550) runs over UDP and carries voice, video, and audio streams. VoIP applications (Zoom, Teams, WhatsApp calls) use RTP over UDP with RTCP (control channel) for statistics. A retransmitted voice packet arriving 200ms late is worthless — humans detect audio delays above 150ms. RTP adds sequence numbers and timestamps so receivers can detect gaps and reorder — but never retransmit.

RTP RFC 3550 | Dynamic ports 49152+ | Zoom, Teams, WhatsApp

⚡

QUIC — The New Internet Foundation

QUIC (RFC 9000, 2021) runs entirely over UDP port 443 — the same port as HTTPS. This lets it pass through firewalls that only open web ports. QUIC implements its own reliable delivery, TLS 1.3 encryption, and stream multiplexing — all in user space, without requiring OS or kernel updates. Powers HTTP/3, YouTube, Google Search, and Meta's social networks. As of 2024, ~30% of all Internet traffic uses QUIC.

RFC 9000 | UDP:443 | HTTP/3 | ~30% of Internet traffic

🎮

Online Gaming — Custom UDP Protocols

Games like Fortnite, Call of Duty, and Counter-Strike use custom UDP-based protocols. Position updates, player actions, and game state are broadcast every 20–64ms (16–50 ticks per second). Lost packets are handled by dead reckoning — predicting where players moved based on last known velocity. Games implement their own selective reliability: critical events (kills, pickups) may be retransmitted once; position updates never are.

Custom ports | 50ms RTT target | Dead reckoning on loss

Section 07

The UDP Checksum — Optional but Critical

The UDP checksum is the only error-detection mechanism UDP offers. Understanding it reveals an elegant design choice: the checksum borrows information from the IP layer to create a binding between the transport and network headers — preventing a correctly received but misrouted datagram from being silently accepted by the wrong application.

📋

The Pseudo-Header — Why the Checksum Borrows from IP

The UDP checksum is computed over three things: the 8-byte UDP header, the UDP payload, and a 12-byte pseudo-header constructed from the IP layer:

Pseudo-header fields: Source IP (4B) + Destination IP (4B) + Zero byte (1B) + Protocol=17 (1B) + UDP Length (2B)

Why? Because without this binding, an IP routing bug could deliver a UDP datagram to the correct port on the wrong host — and the UDP checksum alone would pass. By including the IP addresses in the checksum, any IP-level misdelivery is immediately detected. The pseudo-header is never transmitted — it is only used for the checksum calculation.

⚙ Checksum Computation — Step by Step

Step 1

Build pseudo-header: Src IP (32b) + Dst IP (32b) + 0x00 (8b) + Protocol 17 (8b) + UDP Length (16b)

Step 2

Concatenate: pseudo-header + UDP header (with checksum field set to 0x0000) + UDP data (pad with 0x00 if odd length)

Step 3

Sum all 16-bit words using one's complement addition (carry bits are added back into the sum — "end-around carry")

Step 4

Take the one's complement (bitwise NOT) of the sum → this is the checksum. Place it in the Checksum field.

Verify

Receiver repeats the same calculation including the transmitted checksum. If the result is 0xFFFF, the datagram is valid. If not, silently discard.

⚠️

Checksum = 0 Means "Disabled" in IPv4 — Not Zero!

In IPv4, a UDP checksum of 0x0000 means the sender did not compute a checksum. This is how a sender signals "I am not using checksums — accept this without verification." If the actual checksum computation happens to produce all-zero bits, the sender transmits 0xFFFF instead (one's complement of zero). This is the only value that means "valid zero checksum." In IPv6, the checksum is mandatory — the value 0x0000 is not legal and must be replaced with 0xFFFF.

Section 08

UDP Security — Amplification Attacks & Source Spoofing

UDP's connectionless, stateless nature is a double-edged sword. The same properties that make it fast for DNS and gaming make it a favoured vector for DDoS attacks. Unlike TCP (which requires a 3-way handshake to verify the source IP), UDP allows an attacker to spoof the source IP address trivially.

💥

UDP Amplification Attack

Attacker sends a small UDP request to a server with the victim's IP as the source address. The server sends a large UDP response to the victim. DNS amplification: a 60-byte ANY query produces a 3000-byte response (50× amplification). NTP amplification (monlist): a 234-byte request produces 46,000 bytes of response (197× amplification). The 2013 Spamhaus attack (300 Gbps) and the 2018 GitHub attack (1.35 Tbps via Memcached — 51,000× amplification) both used UDP. UDP has no mechanism to prevent this — it is a fundamental consequence of statelessness. Source: Cloudflare Blog, Arbor Networks annual DDoS report 2018.

DNS 50× | NTP 197× | Memcached 51,000× amplification

🔐

Defences Against UDP Abuse

BCP38 / Source Address Validation: ISPs should drop packets with spoofed source IPs at their network edge — preventing the attack at its source. Widely recommended since 2000 (RFC 2827) but not universally deployed.

Response Rate Limiting (RRL): DNS servers limit the rate of responses to a single source IP.

QUIC's Address Validation: QUIC requires servers to validate the client address before sending large responses — eliminating amplification even over UDP.

Anycast + Scrubbing Centres: Cloudflare, Akamai, and others absorb UDP floods by distributing the attack across hundreds of PoPs globally.

BCP38 | RRL | QUIC validation | Anycast scrubbing

🔥

2018 — GitHub 1.35 Tbps Memcached Attack

On 28 February 2018, GitHub was hit by the largest DDoS attack in history at that time: 1.35 terabits per second. Attackers used misconfigured Memcached servers (which use UDP port 11211) to amplify traffic 51,000×. A 203-byte request produced 100MB of UDP responses directed at GitHub. GitHub mitigated it using Akamai's Prolexic scrubbing service within 10 minutes — but not before the service was completely unreachable. Source: GitHub Engineering Blog, March 2018; Wired Magazine "GitHub Survived the Biggest DDoS Attack Ever Recorded."

Protocol: UDP Memcached | 1.35 Tbps | 51,000× amplification

Section 09

QUIC — Reimagining TCP on Top of UDP

QUIC is the most important evolution in transport protocols since TCP itself. It runs over UDP — inheriting its speed and deployability — while adding everything TCP provides and more, implemented entirely in user space.

⚡

0-RTT Connection Setup

vs TCP's 1.5 RTT + TLS

First connection: 1 RTT (crypto handshake combined with connection setup). Resuming a known server: 0 RTT — the first datagram already carries encrypted application data. TCP requires 1 RTT handshake + 1 RTT TLS = 2 RTTs before data. QUIC halves or eliminates this delay.

🔄

No Head-of-Line Blocking

TCP's fatal flaw — solved

TCP delivers all data in order — a lost packet stalls ALL streams behind it. QUIC multiplexes independent streams: a lost datagram only stalls its own stream. Loading 20 page assets simultaneously, one loss does not block the other 19. Chrome measured 15% faster page loads on lossy mobile links.

🔑

Integrated TLS 1.3

Encryption by default

QUIC encrypts everything — not just data but also most headers. Middleboxes cannot tamper with sequence numbers, ACKs, or stream IDs. This also means QUIC can evolve without middlebox interference. TCP's header fields are unencrypted and have been "ossified" — changing them breaks millions of firewalls.

💡

Why QUIC Is Built on UDP (Not a New Protocol Number)

Google originally designed QUIC in 2012. They tried to deploy it as a new IP protocol number (like TCP=6, UDP=17). But enterprise firewalls block everything except TCP and UDP. By running over UDP port 443 (HTTPS), QUIC passes through any firewall that allows web traffic — which is essentially every firewall everywhere. This is why UDP is not being replaced — it is the deployment vehicle for the next generation of the Internet.

Section 10

Golden Rules — UDP in Production

📌 Non-Negotiable Rules When Working with UDP

Always enable UDP checksum in IPv4 unless you have a specific reason not to. Leaving checksum at 0x0000 means corrupted datagrams are silently accepted. While hardware CRC catches most physical-layer errors, in-memory bit flips (rowhammer, cosmic ray events) on routers are real and go undetected without the checksum. In IPv6, the checksum is mandatory — no option.

Keep UDP payloads under 1472 bytes to avoid IP fragmentation. MTU on Ethernet is 1500 bytes. IP header = 20 bytes, UDP header = 8 bytes. Maximum safe payload = 1500 − 28 = 1472 bytes. Larger payloads are fragmented at the IP layer — and if any fragment is lost, the entire datagram is lost. DNS over UDP is limited to 512 bytes (RFC 1035) specifically because of this — EDNS0 extends it to 4096 bytes but at the risk of fragmentation.

Implement your own rate limiting if using UDP for server-to-client pushes. UDP has no congestion control — a UDP sender can flood the network without any backoff signal. The DCCP protocol and LEDBAT algorithm exist for this reason. If building a game server or media server, implement token bucket rate limiting or use BBR-inspired pacing to be a "good citizen" to other flows.

Close exposed UDP services or apply strict rate limiting — amplification is real. Never expose NTP monlist, Memcached UDP, SSDP, or CharGen to the public Internet. These are the top amplification attack vectors. Use: iptables -A INPUT -p udp --dport 11211 -j DROP for Memcached, and restrict NTP to known clients with restrict default noquery.

Use QUIC/HTTP/3 for new application protocols instead of raw UDP. QUIC gives you reliable streams, 0-RTT, TLS 1.3, and congestion control — without reinventing any of it. Only build on raw UDP if you have a genuine real-time constraint that QUIC's reliability model breaks (e.g. sub-5ms gaming position updates where any queuing is intolerable).

Don't block ICMP Port Unreachable (Type 3 Code 3) for UDP services. When a UDP datagram arrives at a closed port, the host sends ICMP Port Unreachable back to the sender. Blocking this causes the sender to wait for a timeout (usually several seconds) instead of detecting failure immediately. This silently breaks UDP applications and makes debugging extremely difficult.

Handle out-of-order and duplicate datagrams explicitly in your UDP application. If your application requires ordering, include a sequence number in your payload. If it requires exactly-once delivery, include a message ID and keep a short deduplication window. RTP (RFC 3550) is the gold standard for doing this in real-time media — study its design before building your own.

🎓

The Complete Picture

UDP is not a broken TCP. It is a deliberate design choice that says: "The application knows what it needs — here is the minimum viable transport." Its 8-byte header is a masterpiece of restraint: source port, destination port, length, and checksum. Nothing more.

It powers the resolution of every domain name on the Internet, the synchronisation of every clock, the automatic assignment of every IP address, every VoIP call, every video stream, every online game, and — through QUIC — 30% of all web traffic. Far from being the "unreliable" protocol to avoid, UDP is the foundation that modern high-performance applications are built on.

Understanding UDP's trade-offs — and building the right application-layer mechanisms on top of it — is what separates network-aware engineers from those who reach for TCP as a default and wonder why their real-time applications lag.