What Are Common UDP Use Cases?

Explore common UDP use cases like DNS, live streaming, and gaming, why low latency beats guaranteed delivery, and how QUIC builds on UDP.

easyQ184 of 224 in Computer Networks Est. time: 5 minsLast updated: July 2026

Open Code Lab

Expected Interview Answer

UDP is best used where low latency and minimal overhead matter more than guaranteed delivery, such as DNS lookups, live video/voice streaming, online multiplayer gaming, and IoT telemetry — cases where an application can tolerate occasional packet loss or implement its own lightweight reliability rather than pay TCP’s connection setup and retransmission cost.

UDP sends independent datagrams with no handshake, no ordering guarantee, and no automatic retransmission, which keeps per-packet overhead tiny and avoids head-of-line blocking, where TCP would stall an entire stream waiting for one lost packet to be retransmitted. DNS uses UDP for the common case because a query and response fit in a single small round trip, and the resolver simply retries on timeout rather than paying for a full TCP handshake. Real-time voice and video (VoIP, WebRTC, live streaming) prefer UDP because a slightly glitchy but current frame is more useful than a perfectly ordered but stale one — retransmitting an old video frame after the moment has passed is pointless. Online multiplayer games send frequent position/state updates over UDP for the same reason: a dropped update is quickly superseded by the next one, so waiting to retransmit it would only add lag. Modern protocols like QUIC (used by HTTP/3) build reliability, ordering, and congestion control on top of UDP in user space, getting UDP’s low latency while still providing many of TCP’s guarantees where needed.

No handshake or connection setup, minimizing latency
Avoids head-of-line blocking that can stall an entire TCP stream
Lets applications implement only the reliability they actually need
Well suited to DNS, real-time media, gaming, and telemetry

AI Mentor Explanation

UDP is like a scoreboard operator shouting the current score to the crowd every ball, without waiting for confirmation that every single spectator heard the last shout. If one shout is missed because someone was looking away, the operator does not stop and repeat it — the next ball’s shout will carry the updated score anyway, so nothing is lost that matters. This is exactly why UDP suits live score updates: a missed intermediate value is harmless because a fresher one is already on its way. Waiting to retransmit an old score, like TCP would, would only make the crowd fall behind the live game.

Step-by-Step Explanation

Step 1
No handshake
A UDP sender transmits a datagram immediately, with no connection setup or negotiation.
Step 2
Best-effort delivery
The network may drop, duplicate, or reorder the datagram; UDP itself does not retry or reorder.
Step 3
Application-level reliability (if needed)
The application layers on its own acknowledgment, retry, or ordering logic only where it actually matters (e.g., QUIC).
Step 4
Low-latency delivery
For time-sensitive data (voice, video, game state), the freshest datagram matters more than resending a stale one.

What Interviewer Expects

Names concrete UDP use cases (DNS, VoIP/streaming, gaming, telemetry)
Explains why low latency and no head-of-line blocking outweigh guaranteed delivery in those cases
Understands UDP itself provides no ordering/retransmission — that is left to the application
Can mention QUIC/HTTP-3 as a modern example of building reliability atop UDP

Common Mistakes

Claiming UDP is always unreliable and therefore never usable for anything important
Not knowing DNS commonly uses UDP for standard queries
Confusing “connectionless” with “no application-level reliability is possible”
Failing to explain why real-time media prefers fresh data over retransmitted old data

Best Answer (HR Friendly)

“UDP is a faster, no-frills way to send data where speed matters more than perfection — think live video calls, online games, or quick DNS lookups. Instead of double-checking every single packet arrived like TCP does, UDP just fires the data off, which is perfect when a missed video frame or one dropped update is not a big deal because a fresher one is already on its way.”

Code Example

Minimal UDP sender and receiver in Python

import socket

# Receiver: bind and listen for UDP datagrams
def run_receiver():
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.bind(("0.0.0.0", 9999))
    while True:
        data, addr = sock.recvfrom(1024)
        print(f"Received {data!r} from {addr}")

# Sender: fire-and-forget, no handshake required
def send_update(host: str, port: int, payload: bytes) -> None:
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.sendto(payload, (host, port))
    sock.close()

send_update("127.0.0.1", 9999, b"player_x=120,player_y=88")

Follow-up Questions

Why does DNS use UDP for most queries but fall back to TCP for large responses?
How does QUIC build reliability and congestion control on top of UDP?
What is head-of-line blocking, and why does UDP avoid it?
How would you add basic reliability to a UDP-based protocol without turning it into TCP?

MCQ Practice

1. Which of these is a typical UDP use case?

2. Why do online multiplayer games commonly use UDP for state updates?

3. What modern protocol builds reliability and congestion control on top of UDP?

Flash Cards

1 / 4

What Are Common UDP Use Cases?

Expected Interview Answer

AI Mentor Explanation

Step-by-Step Explanation

No handshake

Best-effort delivery

Application-level reliability (if needed)

Low-latency delivery