UDP

UDP is the lightweight counterpart to TCP. Where TCP establishes a connection and tracks every byte, UDP just sends. No handshake, no acknowledgement, no retransmit. Each datagram is independent — it may arrive, arrive out of order, or not arrive at all. Applications that can tolerate loss — or that have their own recovery logic — choose UDP to avoid TCP's overhead.

UDP vs TCP core differences

UDP header structure

The UDP header is just 8 bytes — the minimum possible overhead for a transport protocol. It contains exactly four 16-bit fields:

• Source port (16 bits) — the sending application's port number, used by the receiver to send replies
• Destination port (16 bits) — the port of the receiving application (e.g., 53 for DNS, 67/68 for DHCP)
• Length (16 bits) — total length of the UDP header plus payload in bytes
• Checksum (16 bits) — covers the header and data for error detection; optional in IPv4, mandatory in IPv6

By comparison, a TCP header is 20 bytes minimum and up to 60 bytes with options — it must carry sequence numbers, acknowledgement numbers, window size, flags, and optional fields for features like timestamps and selective acknowledgement. UDP's 8-byte header imposes negligible overhead even at high packet rates.

Why real-time apps prefer UDP

In a video call, a voice packet that arrives 200 ms late is useless — silence is better than a garbled echo. In a game, the position update from 150 ms ago is stale. UDP lets these applications discard late packets and move on rather than waiting for TCP retransmits to arrive in order. The application layer decides how to handle loss — usually by interpolating missing frames or simply skipping them.

How applications compensate for UDP's lack of reliability

UDP's unreliability is a starting point, not an endpoint. Applications layer their own recovery on top:

• VoIP and audio — codecs like Opus use Forward Error Correction (FEC): redundant data is embedded so a lost packet can be reconstructed from adjacent ones without retransmission. A jitter buffer absorbs variation in packet arrival timing, smoothing playback at the cost of a small fixed delay (typically 20–100 ms).
• Online games — movement and position updates are sent at high frequency (20–128 packets/sec) and loss of a single update is covered by the next. Inputs and important game events use application-level sequence numbers and acknowledgement so they can be selectively retransmitted.
• Video streaming — RTP (Real-time Transport Protocol) adds sequence numbers and timestamps on top of UDP so receivers can detect gaps and reorder packets, but does not retransmit — it uses redundant streams and error concealment instead.

UDP amplification in DDoS attacks

UDP's connectionless nature makes it a common vector for amplification DDoS attacks. The attacker sends a small UDP request to a public server (DNS, NTP, SSDP, Memcached) with the source IP spoofed to the victim's address. The server sends a much larger response to the victim — amplification factors range from 28x for DNS to over 50,000x for Memcached. The victim is flooded with unsolicited high-volume traffic without the attacker ever interacting with them directly. Mitigation involves source IP validation (BCP38), rate limiting on UDP reflectors, and upstream scrubbing by the ISP or DDoS protection service.

QUIC: UDP with reliability

QUIC (the protocol under HTTP/3) runs on top of UDP and reimplements reliability, encryption, and stream multiplexing at the application layer. This lets it avoid TCP's head-of-line blocking — where a single lost packet stalls all streams — while still delivering data reliably. QUIC also combines the TLS handshake with the connection setup, reducing latency by one round trip. Because QUIC runs over UDP, it works on networks where TCP might be modified or throttled by middleboxes, and connection migration allows a session to survive a change of IP address (e.g., moving from Wi-Fi to mobile data) without reconnecting.

UDP checksum and when it is disabled

The UDP checksum covers the header, payload, and a pseudo-header derived from the IP header. In IPv4, the checksum is optional — a value of 0x0000 means "no checksum computed." Some high-performance local network applications disabled the checksum to reduce CPU overhead when the physical network's own CRC was considered sufficient. In IPv6, the UDP checksum is mandatory because IPv6 removed the IP header checksum, so UDP's checksum is the only end-to-end integrity check. In practice, nearly all modern implementations compute the UDP checksum even over IPv4.

Broadcast and multicast

Only UDP supports broadcast and multicast — TCP cannot because it is a point-to-point connection protocol. UDP broadcast (destination 255.255.255.255 or the subnet broadcast address) sends a single packet to all devices on a network segment. UDP multicast (239.x.x.x for local scope) delivers to a group of subscribed receivers. These properties make UDP the only option for protocols like DHCP (broadcast discovery), mDNS (multicast local name resolution), SSDP (multicast device discovery), and IPTV multicast streams.

Frequently Asked Questions

Is UDP reliable?

No — deliberately. UDP sends packets with no acknowledgement and no retransmit. Packets can be lost, duplicated, or arrive out of order. Applications that need reliability must add it themselves, as QUIC does.

Why do games use UDP instead of TCP?

In fast-paced games, a retransmitted packet from 100 ms ago is worse than no packet — the game state has moved on. UDP lets the game engine decide what to do with missing data, keeping round-trip latency as low as possible.

What is QUIC and how does it relate to UDP?

QUIC is the transport layer under HTTP/3 — it runs on UDP and adds its own reliability, encryption, and stream multiplexing. It avoids TCP's head-of-line blocking and reduces connection setup to a single round trip by combining the transport and TLS handshakes.