UDP for streaming, DNS and games
The comparison article laid out what UDP gives up: no handshake, no retransmission, no ordering, no flow control. Framed like that, it sounds like a worse protocol. It isn't — it's a protocol for a different job, and there's a whole category of software for which every one of those "missing" features would actually make things worse, not better. This article works through that category: DNS, live media, and real-time games, plus a couple of less obvious places UDP shows up, and what each one is actually trading away in exchange for speed.
DNS: a query that doesn't need a conversation
Start with the example the previous article already used, because it's the cleanest illustration of connectionless design paying off. A DNS lookup is a single question and a single answer: "what's the address for example.com?" — "here it is." There's nothing conversational about it. Setting up a TCP connection for that exchange would mean a full three-way handshake just to send one small request, then a four-step teardown just to close it — more round trips spent on connection bookkeeping than on the actual answer.
UDP fits because the entire interaction is one datagram out, one datagram back, as RFC 1035 specifies: UDP is the recommended transport for ordinary queries, with responses capped at 512 bytes before the resolver has to fall back to TCP. If a reply doesn't arrive — the datagram was dropped, or the server was overloaded — the resolver just asks again, either the same server or a different one from its list. Retrying a stateless query costs nothing extra; there's no connection state to clean up first.
The reliability trade-off here is genuinely cheap: DNS answers are small, mostly cached, and retried automatically by every stub resolver, so the rare dropped packet is invisible to a user. That calculation changes completely for anything larger or less tolerant of a retry, which is exactly why zone transfers between DNS servers use TCP instead — moving an entire zone file is a bulk transfer, not a single query, and losing part of it silently would be a real problem.
Live media: correctness is optional, timing isn't
Video calls, live streaming, and voice traffic share a property that makes UDP the right default: a piece of data that arrives late is often worse than a piece of data that never arrives at all.
Think about what a lost video frame actually costs. The decoder on the receiving end either repeats the previous frame briefly or applies concealment to approximate what the missing frame probably looked like. Either way, the call keeps moving, and most people never consciously notice a single dropped frame in a busy conversation. Now consider the alternative: if that frame had to be retransmitted, correctly, in order, before anything after it could play — the entire call would freeze for the length of a round trip while the retransmission arrived. Do that every time a packet is lost on a slightly congested Wi-Fi network, and the "reliable" version of the call is unwatchable, while the "unreliable" one just has an occasional soft glitch.
This is why real-time voice and video protocols build directly on UDP. WebRTC, the browser-native protocol for peer-to-peer audio, video, and data, negotiates a UDP path between peers and carries media over it using RTP (Real-time Transport Protocol), which stamps every packet with its own sequence number and timestamp purely so the receiver can detect loss and jitter — never to trigger a blocking retransmission. WebRTC secures that stream with SRTP, the encrypted form of RTP, but the sequencing and timing fields themselves are RTP's job, not something encryption adds. The application decides what to do about a gap; the transport itself won't ever stall waiting for one packet to catch up.
Streaming platforms that serve pre-recorded video, by contrast, mostly run over TCP today (usually HTTP-based delivery), because a few seconds of client-side buffering hides network jitter entirely and a stalled transfer just means the buffer drains a little before refilling — there's no live deadline to miss. The UDP case is specifically for traffic where "live" is the whole point: a delayed frame in a video call is not simply late, it's useless, because the moment it was meant to be seen has already passed.
Multiplayer games: every millisecond is visible
Real-time multiplayer games push the same logic further. A first-person shooter or a fast-paced competitive game sends a continuous stream of state updates — player positions, actions, hit detection — often dozens of times per second. Each update supersedes the one before it. If update #402 (a player's position half a second ago) arrives late, after update #403 has already been processed, it's not just unhelpful, it's actively wrong: applying it would move a player backward in time.
TCP's insistence on in-order delivery is precisely the wrong behavior here. If packet #402 is lost, TCP would hold #403 and everything after it in a buffer, refusing to hand any of it to the application until #402 is retransmitted and arrives — even though the game has no use for #402 anymore. This is the same head-of-line blocking problem that shows up in HTTP over TCP, just easier to see in a context with no ambiguity about which packet actually matters. Game engines built on UDP instead tag each update with a sequence number, accept whichever updates arrive, discard anything older than the newest one already processed, and let the application-level game state simply move forward with whatever data it has. A late update isn't retransmitted — it's dropped on arrival, because a position update from half a second ago has nothing useful left to say.
Studios that need some guarantees — a chat message, an inventory change, anything that truly cannot be silently dropped — typically run a second, separate UDP-based channel with their own lightweight acknowledgment and retry logic for just those messages, while leaving high-frequency position updates on the unacknowledged fast path. That split, "reliable channel for what must arrive, unreliable channel for what's already stale by the time it would be retransmitted," is the general pattern UDP-based real-time systems converge on.
Where UDP quietly shows up elsewhere
A few other places UDP does the work without most people noticing:
- DHCP, which assigns an IP address to a device before that device has any address of its own to receive a TCP reply at — a connectionless broadcast-friendly protocol is the only kind that can work at that stage.
- NTP (Network Time Protocol), for the same reason DNS uses it: single small request, single small reply, and a dropped packet just means try again a few seconds later.
- VPN tunnels built on protocols like WireGuard or OpenVPN's UDP mode, which deliberately avoid stacking a reliable transport inside another reliable transport. Tunneling TCP application traffic inside a TCP-based VPN connection creates a well-documented failure mode sometimes called "TCP meltdown": the inner TCP session and the outer VPN's TCP session each run their own independent retransmission and congestion control, and under packet loss the two layers can fight each other — the outer connection retransmitting a segment that already contains an inner retransmission, compounding delay instead of recovering from it. Running the VPN tunnel itself over UDP sidesteps the problem, since UDP does no retransmission of its own for the outer layer to conflict with.
Practical scenario: one-way audio on a VoIP call
A company deploys a SIP-based VoIP softphone for its support team. Calls connect, and agents can hear customers clearly — but customers report they can't hear the agent at all. Text chat and screen sharing on the same machines work fine.
The signaling (SIP, which negotiates the call) is fine, since the call connects. The problem is on the media path, which for this deployment runs UDP in the range 10000–20000, negotiated per call. A read-only check on the softphone host shows what's actually happening:
The socket is open and listening for the return audio stream, but no data is arriving on it. The next check is whether outbound UDP in that range is actually leaving the network at all:
14:41:02.100442 IP 10.0.5.12.14022 > 203.0.113.40.16482: UDP, length 172
14:41:02.120901 IP 10.0.5.12.14022 > 203.0.113.40.16482: UDP, length 172
14:41:02.141330 IP 10.0.5.12.14022 > 203.0.113.40.16482: UDP, length 172
Outbound packets are leaving steadily — the agent's audio is being sent — but nothing is coming back in the capture. That asymmetry points at the network edge rather than the softphone itself: a stateful firewall or NAT device is very likely permitting outbound UDP in this range (since the softphone initiated it) but has no rule allowing the return traffic in, or its NAT mapping for this session has expired because the UDP "connection" it's tracking has no real teardown to signal when it should stay open.
Don't experiment with firewall or NAT rules on a production voice gateway without a rollback plan
A media-path firewall misconfiguration on a live call system affects every ongoing and future call the moment it's applied. Test the fix on a single lab extension first, confirm the specific port range and direction with sudo iptables -L -n -v (or the equivalent for the firewall in use) before changing anything, and keep the previous rule set saved so it can be restored immediately if the change makes things worse rather than better.
The fix is almost always a firewall or NAT rule permitting the full negotiated UDP media range in both directions, or — more robustly — configuring the softphone infrastructure to use a narrower, explicitly allow-listed port range rather than a wide default one. The underlying lesson generalizes past VoIP: whenever "outbound works, inbound doesn't, and it's UDP," a stateful edge device not tracking a connectionless protocol's session correctly is the first thing worth checking, well before assuming the application itself is broken.
The cost of UDP's openness: reflection and amplification
UDP's connectionless design has a security consequence worth understanding, not just tolerating. Because a UDP server will process a datagram from any source without first confirming a connection, and because the source IP address in that datagram is not verified by the protocol itself, an attacker can send a request with a forged source address — one belonging to a victim, not the attacker. The server's reply goes to the forged address instead of back to the real sender.
This becomes a DNS amplification attack when the request is small but the reply is large: an attacker sends a compact DNS query with the victim's spoofed IP as the source, and every resolver that answers sends a much larger response toward the victim, multiplying the attacker's outbound traffic into a far larger flood aimed at someone else entirely. The same pattern works against NTP, memcached, and any other UDP-based service that returns a response larger than the request. TCP is comparatively resistant to this specific abuse because the handshake requires the responder to receive a valid ACK from the claimed source before any application data flows — an attacker spoofing a TCP source address gets the SYN-ACK sent to the victim, not back to itself, and the connection never completes, so no useful amplified reply reaches the attacker or the victim from the server's actual response. It's a good example of a protocol's design surviving into its threat model: UDP's speed and DNS amplification abuse are the same design decision, viewed from two different sides.
Practice exercises
- Capture a DNS query yourself with
sudo tcpdump -i any -n port 53 -c 4and identify the query and response in the output. Then force a TCP DNS query withdig +tcp example.comand capture it separately — compare how many packets each conversation actually took. - A multiplayer game client logs a "rubber-banding" bug: characters briefly snap backward before correcting. Using this article's explanation of stale position updates, explain what's likely happening and why simply switching that update channel to TCP would make the visible symptom worse, not better.
- Explain, in your own words, why DHCP could not have been designed on top of TCP — what does a device requesting an address not yet have, that a TCP handshake would require?
- A colleague proposes running a company's internal metrics-collection agents over UDP to "save overhead," sending one datagram per metric every second. List at least two concrete failure modes this design should account for, given that UDP guarantees neither delivery nor order.