UDP, QUIC and choosing reliability
What UDP does and does not promise, why DNS and real-time media use it, how QUIC builds reliability on top of datagrams, and when TCP is the wrong tool.
A datagram is a postcard
UDP adds ports and a checksum to IP and nothing else. There is no handshake, no ordering, no retransmission and no delivery guarantee — each datagram either arrives or does not, and the application decides what to do about it.
| Property | TCP | UDP |
|---|---|---|
| Connection setup | Three-way handshake | None |
| Ordering | Guaranteed | Not guaranteed |
| Delivery | Retransmitted until acknowledged | Best effort |
| Duplicates | Removed | Possible |
| Message boundaries | Byte stream, none | Preserved per datagram |
| Head-of-line blocking | Yes, within the connection | None at the transport layer |
| Header size | 20 bytes minimum plus options | 8 bytes |
| Typical uses | HTTP, SSH, file transfer | DNS, media, games, QUIC |
import socket
srv = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
srv.bind(("0.0.0.0", 9999))
data, addr = srv.recvfrom(2048) # one datagram, no connection
srv.sendto(b"ack", addr) # a reply is just another datagram
# a large datagram is fragmented by IP and lost entirely if any fragment is lost
# keep payloads well under the path MTU, or implement your own chunking- A datagram larger than the path MTU is fragmented, and losing one fragment loses the whole datagram with no partial delivery.
- UDP has no congestion control, so a naive sender can starve the network. A well-behaved application implements its own.
- Because there is no handshake, a spoofed source address is trivial, which is why UDP is the substrate for reflection attacks.
- DNS falls back to TCP when a response exceeds 512 bytes without EDNS, or for zone transfers.
QUIC is TCP-like reliability in user space
QUIC runs over UDP, but implements streams, reliability, congestion control and TLS 1.3 inside the protocol. Because it is a user-space library, it can evolve without waiting for the operating system.
HTTP/2 over TCP HTTP/3 over QUIC
one ordered byte stream many independent streams
one lost packet blocks a lost packet blocks only
all streams the stream it belongs to
TLS handshake after TCP TLS 1.3 integrated in the handshake
(2 RTT, or 1 with resume) (1 RTT, or 0 on resumption)
connection identified by connection identified by a
four-tuple connection id, so it survives
a change of address- Stream independence removes transport-level head-of-line blocking between requests.
- The connection id lets a session survive a change of IP address, which matters on mobile networks.
- The handshake integrates encryption, so the first round trip can already carry application data on resumption.
- Some networks block or shape UDP, so clients fall back to HTTP/2 over TCP; measure before assuming QUIC is in use.
Choosing a transport
| Workload | Transport | Reason |
|---|---|---|
| REST API, file download | TCP (HTTP) | Ordered, reliable, ubiquitous |
| Web page with many resources | QUIC with TCP fallback | Stream independence, faster setup |
| DNS queries | UDP with TCP fallback | One round trip for the common case |
| Live voice and video | UDP (RTP) or QUIC | Late data is worthless; loss is preferable to delay |
| Real-time games | UDP | Custom reliability per message type |
| Bulk data replication | TCP with tuned windows | Reliability and flow control matter |
| Metrics and logs | UDP or a queue | Losing a sample is acceptable; blocking is not |
⚠️
Do not implement reliability from scratch without congestion control. A UDP sender that retransmits aggressively and ignores the network state will cause packet loss for everyone sharing the link, and no amount of application logic fixes that.
FAQ
Is UDP faster than TCP?
It has less overhead and no handshake, so the first byte can leave sooner. Sustained throughput can be worse without congestion control, because a naive sender overruns the path.
Does QUIC replace TLS?
It incorporates TLS 1.3 as its handshake rather than running it as a separate layer, so the two are tightly coupled even though the cryptography is standard TLS.
Related
TCP in depth: handshake, windows and congestion control TLS and HTTPS: certificates and the handshake
Last refreshed 2026-09-18.