Episode 1 — Fundamentals / 1.3 — Internet Protocols
1.3.c — What is UDP and Why Is It Used for Fast Communication?
In one sentence: UDP (User Datagram Protocol) is the transport-layer protocol that sends data as fast as possible with zero connection setup and no delivery guarantees — making it the go-to choice for real-time applications where speed matters more than perfection.
Navigation: ← 1.3.b — TCP Three-Way Handshake · 1.3.d — How UDP Works →
Table of Contents
- 1. What is UDP?
- 2. History
- 3. Why UDP Exists — The Problem It Solves
- 4. Key Characteristics of UDP
- 5. UDP Datagram Structure
- 6. Why UDP is Fast
- 7. Where UDP is Used (Real-World Examples)
- 8. UDP and Modern Protocols (QUIC / HTTP/3)
- 9. Disadvantages of UDP
- 10. Key Takeaways
- 11. Explain-It Challenge
1. What is UDP?
UDP stands for User Datagram Protocol. Like TCP, it operates at Layer 4 (Transport) of the OSI model. Unlike TCP, it is connectionless — it sends data without establishing a connection first and provides no guarantees about delivery, order, or completeness.
| Property | What it means |
|---|---|
| Connectionless | No handshake, no connection setup — just send |
| Unreliable | No acknowledgments, no retransmissions — packets can be lost silently |
| Unordered | Packets may arrive in any order; UDP doesn't reorder them |
| No flow control | Sender can blast data as fast as it wants; no window negotiation |
| No congestion control | UDP doesn't slow down when the network is busy (but the app can!) |
| Lightweight | Minimal header (8 bytes vs TCP's 20+); very low overhead |
| Message-oriented | Each send() = one datagram; boundaries are preserved (unlike TCP's byte stream) |
Mental model: UDP is like dropping a letter in a mailbox with no tracking number. It might arrive, it might not. You'll never know unless the recipient contacts you separately.
2. History
| Year | Event |
|---|---|
| 1980 | David P. Reed defines UDP in RFC 768 — one of the shortest and simplest RFCs ever (3 pages) |
| 1980s | Adopted for DNS queries, NTP, and early network games |
| 2000s | VoIP (Skype, etc.) and online gaming establish UDP as the real-time transport |
| 2012–2021 | Google develops QUIC on top of UDP, eventually becoming HTTP/3 |
| 2022 | HTTP/3 (RFC 9114) standardized — the biggest adoption of UDP for web traffic |
UDP was designed to be the simplest possible transport protocol — a thin wrapper around IP that adds ports (to multiplex applications) and a checksum (to detect corruption). Nothing more.
3. Why UDP Exists — The Problem It Solves
TCP's reliability comes at a cost: latency. For some applications, that cost is unacceptable.
THE PROBLEM UDP SOLVES
Live video call using TCP: Live video call using UDP:
┌──────────────────────────┐ ┌──────────────────────────┐
│ │ │ │
│ Frame 1 ───► ✓ received │ │ Frame 1 ───► ✓ shown │
│ Frame 2 ───► ✗ LOST! │ │ Frame 2 ───► ✗ lost │
│ Frame 3 ───► ✓ received │ │ Frame 3 ───► ✓ shown │
│ Frame 4 ───► ✓ received │ │ Frame 4 ───► ✓ shown │
│ │ │ │
│ TCP: "Wait! I need to │ │ UDP: "Frame 2 is gone. │
│ retransmit Frame 2 │ │ Show Frame 3 now. │
│ before showing 3 and 4" │ │ Nobody wants to see a │
│ │ │ frame from 200ms ago" │
│ Result: VIDEO FREEZES │ │ Result: TINY GLITCH, │
│ while waiting for old │ │ VIDEO KEEPS FLOWING │
│ frame to arrive │ │ │
└──────────────────────────┘ └──────────────────────────┘
Key insight: For real-time applications, a late packet is as useless as a lost packet. Retransmitting frame 2 when frames 3, 4, and 5 are already playing doesn't help — it causes stuttering and freezing. UDP lets the application decide what to do about loss, rather than forcing TCP's "wait and retransmit" behavior.
4. Key Characteristics of UDP
4.1 Connectionless — Fire and forget
No handshake. The sender just sends a datagram to an IP address and port. The receiver may or may not be listening. The sender has no way to know unless the application layer builds its own feedback.
4.2 No delivery guarantee
If a UDP datagram is lost in the network, nobody is notified. No retransmission happens. The application must handle loss itself (or accept it).
4.3 No ordering
UDP datagrams are independent. They might arrive in a different order than they were sent. If order matters, the application must add its own sequence numbers.
4.4 Message boundaries preserved
Unlike TCP's byte stream (where the OS can combine or split messages), each UDP send() maps to exactly one datagram on the network. The receiver gets complete datagrams, one at a time.
4.5 Extremely low overhead
TCP header: 20–60 bytes per segment
UDP header: 8 bytes per datagram
For small messages (like DNS queries), TCP's overhead is 2.5–7.5x more
5. UDP Datagram Structure
The UDP header is remarkably simple — just 8 bytes:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
┌─────────────────────────┬─────────────────────────┐
│ Source Port (16) │ Destination Port (16) │
├─────────────────────────┼─────────────────────────┤
│ Length (16) │ Checksum (16) │
├─────────────────────────┴─────────────────────────┤
│ │
│ DATA │
│ │
└─────────────────────────────────────────────────────┘
| Field | Size | Purpose |
|---|---|---|
| Source Port | 16 bits | Which application sent this (can be 0 if no reply expected) |
| Destination Port | 16 bits | Which application should receive this |
| Length | 16 bits | Total size of header + data (min 8 bytes for header only) |
| Checksum | 16 bits | Error detection (optional in IPv4, mandatory in IPv6) |
That's it. No sequence numbers, no acknowledgment numbers, no flags, no window size. Compare this to TCP's 20+ byte header with all its control machinery.
6. Why UDP is Fast
| TCP overhead | UDP equivalent |
|---|---|
| 3-way handshake (1 RTT before data) | None — send data immediately |
| ACKs for every segment (bandwidth + processing) | None — no feedback mechanism |
| Retransmissions (wait for timeout, resend) | None — lost packets stay lost |
| Head-of-line blocking (later data waits for earlier lost packet) | None — each datagram is independent |
| Congestion control (slow start, reduces speed) | None — sends at whatever rate the app chooses |
| 20+ byte header per segment | 8 byte header per datagram |
The speed advantage in numbers
TCP: New connection to send a small message
────────────────────────────────────────────────
1. SYN → (½ RTT)
2. SYN-ACK ← (½ RTT)
3. ACK + Data → (½ RTT)
4. Response ← (½ RTT)
Total: 2 RTTs minimum
UDP: Same small message
────────────────────────────────────────────────
1. Data → (½ RTT)
2. Response ← (½ RTT)
Total: 1 RTT
UDP is 2x faster for single request-response exchanges
This is exactly why DNS uses UDP for normal queries — a single question and answer shouldn't require three extra packets of handshake overhead.
7. Where UDP is Used (Real-World Examples)
| Application | Why UDP |
|---|---|
| DNS queries | Small request/response; speed matters; app retries if needed |
| Online gaming (game state) | Player positions update 20–60 times/sec; a lost frame is immediately stale |
| Voice over IP (VoIP) | Real-time audio; retransmitting old audio chunks causes echo and delay |
| Video streaming (live) | Live feeds can't wait for retransmissions; slight quality drop > freezing |
| Video conferencing (Zoom, Teams) | Same as VoIP + video; latency is the enemy |
| IoT sensor data | Thousands of sensors sending small readings; some loss is acceptable |
| DHCP | Initial network config; client doesn't have an IP yet — needs simple protocol |
| NTP (time sync) | Small, frequent time packets; occasional loss is fine |
| QUIC / HTTP/3 | Builds reliability on top of UDP; avoids TCP's head-of-line blocking |
| mDNS (local discovery) | Multicast on local network; connectionless fits naturally |
The gaming example in detail
GAME CLIENT (60 FPS) GAME SERVER
Frame 1: Player at (10, 20) ──────────► ✓ Process
Frame 2: Player at (11, 20) ──────────► ✗ Lost!
Frame 3: Player at (12, 21) ──────────► ✓ Process
Frame 4: Player at (13, 21) ──────────► ✓ Process
Server doesn't care about Frame 2.
Frame 3 already has a newer position.
Retransmitting Frame 2 would be WASTEFUL.
8. UDP and Modern Protocols (QUIC / HTTP/3)
One of the most important modern uses of UDP is QUIC, which powers HTTP/3.
Why build on UDP instead of TCP?
The TCP head-of-line blocking problem:
┌──────────────────────────────────────────────────────┐
│ TCP Connection (one stream) │
│ │
│ Stream A: [pkt1] [pkt2] [pkt3] │
│ Stream B: [pkt4] [pkt5] [pkt6] │
│ │
│ If pkt2 is lost, TCP blocks ALL data (including │
│ Stream B's pkt4, pkt5, pkt6) until pkt2 is retransmitted │
└──────────────────────────────────────────────────────┘
QUIC over UDP:
┌──────────────────────────────────────────────────────┐
│ QUIC Connection (multiple independent streams) │
│ │
│ Stream A: [pkt1] [___] [pkt3] ← pkt2 lost; │
│ only Stream A waits│
│ Stream B: [pkt4] [pkt5] [pkt6] ← keeps flowing! │
│ │
│ QUIC adds its own reliability PER STREAM on top │
│ of UDP, avoiding cross-stream blocking │
└──────────────────────────────────────────────────────┘
QUIC uses UDP as a foundation and implements its own:
- Connection establishment (combined with TLS — saves 1 RTT)
- Reliability and retransmission (per stream, not per connection)
- Congestion control
- Connection migration (change Wi-Fi to cellular without reconnecting)
Key point: QUIC proves that UDP's "lack of features" is actually a feature — it gives protocol designers a blank canvas to build exactly the behavior they need.
9. Disadvantages of UDP
| Disadvantage | Explanation |
|---|---|
| No reliability | Lost packets are gone forever unless the app retransmits them |
| No ordering | App must handle out-of-order delivery or accept disorder |
| No congestion control | A UDP app that blasts data can harm the network for everyone |
| Firewall issues | Some corporate firewalls block or throttle UDP traffic (it's harder to track statefully) |
| NAT timeout | UDP NAT mappings expire faster than TCP's (no keep-alive built in); long-lived flows need heartbeats |
| Amplification attacks | UDP's connectionless nature enables DDoS amplification (attacker spoofs source IP, sends small query, victim gets large response) |
UDP amplification attack (brief)
ATTACKER DNS SERVER VICTIM
│ │ │
│ Small DNS query │ │
│ (spoofed source IP │ │
│ = victim's IP) │ │
│ ─────────────────────► │ │
│ │ │
│ │ Large DNS response │
│ │ sent to VICTIM's IP │
│ │ ─────────────────► │
│ │ │ Overwhelmed!
│ │ │
│ Attacker sends 60 bytes │ │
│ Victim receives 4000 │ │
│ bytes → amplification! │ │
This is possible because UDP has no handshake to verify the source IP is real. TCP's handshake prevents this because the SYN-ACK goes to the real IP, which would not complete the handshake.
10. Key Takeaways
- UDP is a connectionless, unreliable, unordered transport protocol — the simplest possible wrapper around IP.
- Its speed comes from skipping everything TCP does: no handshake, no ACKs, no retransmissions, no ordering, no flow/congestion control.
- UDP is ideal for real-time applications where late data is worse than lost data: gaming, VoIP, live video, DNS.
- QUIC/HTTP/3 is the most important modern use of UDP — building custom reliability on top of UDP's speed.
- The trade-off: applications using UDP must handle or accept packet loss, out-of-order delivery, and congestion themselves.
- UDP's connectionless nature makes it vulnerable to amplification attacks (spoofed source IPs).
11. Explain-It Challenge
Without looking back, explain in your own words:
- What does "connectionless" mean, and how is it different from TCP's approach?
- Why would a video call app choose UDP over TCP?
- What is the UDP header made of, and why is it so small?
- How does QUIC solve TCP's head-of-line blocking problem while still being reliable?
- What is a UDP amplification attack and why can't it happen with TCP?
Navigation: ← 1.3.b — TCP Three-Way Handshake · 1.3.d — How UDP Works →