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.

PropertyTCPUDP
Connection setupThree-way handshakeNone
OrderingGuaranteedNot guaranteed
DeliveryRetransmitted until acknowledgedBest effort
DuplicatesRemovedPossible
Message boundariesByte stream, nonePreserved per datagram
Head-of-line blockingYes, within the connectionNone at the transport layer
Header size20 bytes minimum plus options8 bytes
Typical usesHTTP, SSH, file transferDNS, 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

WorkloadTransportReason
REST API, file downloadTCP (HTTP)Ordered, reliable, ubiquitous
Web page with many resourcesQUIC with TCP fallbackStream independence, faster setup
DNS queriesUDP with TCP fallbackOne round trip for the common case
Live voice and videoUDP (RTP) or QUICLate data is worthless; loss is preferable to delay
Real-time gamesUDPCustom reliability per message type
Bulk data replicationTCP with tuned windowsReliability and flow control matter
Metrics and logsUDP or a queueLosing 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.

TCP in depth: handshake, windows and congestion control TLS and HTTPS: certificates and the handshake

Last refreshed 2026-09-18.