📡 02-03: UDP & Connectionless Protocols¶
📌 What Is UDP?¶
UDP (User Datagram Protocol) is the other major transport-layer protocol alongside TCP. Where TCP is built around careful, verified, ordered delivery, UDP takes the opposite philosophy: send it and move on. It provides essentially no guarantees beyond basic addressing.
UDP is connectionless — there's no handshake, no negotiated session, no persistent state kept about "the conversation." Each UDP message (called a datagram) is sent independently, with no relationship enforced to any datagram sent before or after it.
🧾 The UDP Header¶
UDP's header is dramatically simpler than TCP's — just four fields:
| Field | Size | Purpose |
|---|---|---|
| Source Port | 16 bits | Port the datagram was sent from |
| Destination Port | 16 bits | Port the datagram is addressed to |
| Length | 16 bits | Total length of the UDP header + data |
| Checksum | 16 bits | Basic error-detection for corruption (optional in IPv4, mandatory in IPv6) |
💡 Compare this to TCP's header, which additionally carries sequence numbers, acknowledgment numbers, control flags, window size, and more. UDP simply doesn't track any of that — there's no concept of "the next expected byte" because UDP doesn't treat data as a continuous stream at all; each datagram stands alone.
⚖️ Connectionless vs. Connection-Oriented: The Tradeoffs¶
| Aspect | TCP (Connection-Oriented) | UDP (Connectionless) |
|---|---|---|
| Setup | Requires a 3-way handshake before sending data | None — just send |
| Reliability | Guaranteed delivery via retransmission | No guarantee — lost datagrams simply vanish |
| Ordering | Guaranteed in-order delivery | No ordering — datagrams may arrive in any order, or not at all |
| Overhead | Higher (headers, handshake, ACKs, retransmission logic) | Minimal (small header, no handshake, no retransmission) |
| Speed | Slower to start, and reliability mechanisms add latency | Fast — no setup delay, no waiting for ACKs |
| Use case fit | Correctness matters more than speed (file transfer, web pages) | Speed/timeliness matters more than perfect correctness (real-time media) |
💡 Neither protocol is "better" — they're built for opposite priorities. Choosing between them is an application design decision based on what matters more: never losing data or never falling behind real-time.
🎯 Why UDP Is Used for DNS, VoIP, Video, and Gaming¶
DNS¶
A DNS query (Module 06) is a single small question and a single small answer. Setting up a full TCP handshake for a one-shot exchange this tiny would roughly triple the number of round trips needed just to get an answer. UDP lets a DNS query complete in a single round trip: ask, get an answer. (DNS does fall back to TCP for larger responses, like zone transfers — but the common case is UDP.)
VoIP (Voice over IP) and Video Calls¶
If a single audio packet is lost during a phone call, the fix is not to pause the entire call and wait for a retransmission — by the time a retransmitted packet arrived, the conversation would have moved on and the delayed audio would be useless. It's far better to briefly drop or interpolate over a missing fraction of a second of audio and keep the conversation moving in real time. TCP's retransmission and strict ordering would make the call feel laggy and stuttery; UDP tolerates the loss gracefully.
Live Video Streaming and Online Gaming¶
Same principle: a gamer's position update from half a second ago is stale the instant a newer one exists — retransmitting old data is pointless. Real-time applications almost universally choose UDP (sometimes layering their own lightweight, application-specific reliability on top only for the specific data that truly can't be dropped, like a game's "player picked up an item" event).
⚠️ Security Implication: UDP Is Easier to Spoof¶
Because UDP has no handshake, there is no equivalent moment where both sides prove they can reach each other in both directions (recall from 02-01 that TCP's 3-way handshake exists specifically to confirm bidirectional reachability before real data flows).
This has serious consequences:
- Trivial source spoofing: An attacker can send a UDP datagram with a completely forged source IP address, and the receiving application has no built-in way to detect this — there was never a "connection" to validate against in the first place. TCP, by contrast, requires an attacker to correctly guess sequence numbers to inject data into an already-established connection — a much higher bar.
- Amplification attacks: Many UDP-based services (DNS, NTP, memcached) will respond to a small query with a much larger response. An attacker spoofs the source IP address to be the victim's IP, sends a small forged query to many such servers, and each server obligingly sends its large response to the victim — a DDoS amplification attack. This entire technique depends on UDP's lack of any handshake to verify the source address is real.
- No built-in retransmission awareness: Since applications using UDP must implement their own reliability if they need any, security-relevant errors (like a dropped or forged packet) may go completely unnoticed unless the application layer explicitly checks for it.
💡 This is precisely why 02-06: IP Spoofing Fundamentals and the DNS attack modules (06-04 onward) lean so heavily on UDP-based protocols — the lack of a handshake is the single biggest reason spoofing UDP traffic is so much easier than spoofing an established TCP session.
📌 Key Takeaways¶
- UDP is connectionless — no handshake, no persistent session state, each datagram is independent.
- The UDP header has only 4 simple fields: source port, destination port, length, and checksum — dramatically lighter than TCP's header.
- UDP trades reliability and ordering for speed and low overhead; TCP trades speed for guaranteed, ordered delivery.
- DNS, VoIP, video streaming, and gaming all favor UDP because stale or lost data is often worse than no data at all, and retransmission would defeat the purpose of real-time communication.
- UDP's lack of a handshake means there's no built-in step to verify that a claimed source address is genuine, making source IP spoofing dramatically easier than with TCP.
- UDP-based amplification attacks (DNS, NTP, memcached) exploit this exact weakness: small spoofed queries trigger large responses directed at a forged victim address.
- Choosing TCP vs. UDP is fundamentally a tradeoff between correctness/reliability and speed/timeliness — and that same tradeoff directly shapes each protocol's attack surface.