UDP, the User Datagram Protocol, is a connectionless transport protocol that carries independent messages, called datagrams, between applications over IP with only port numbers, a length and a checksum added. Among transport protocols in networking it is the minimal alternative to TCP: it offers no handshake, no acknowledgments, no retransmission and no ordering, and leaves those decisions to the application.
Defined in RFC 768 in 1980, UDP has an 8-byte header and has barely changed since. Its simplicity makes it the foundation for DNS queries, real-time voice and video, online games, network services such as DHCP and NTP, and newer protocols like QUIC, which builds its own reliability on top of UDP.
How UDP carries datagrams
An application hands UDP a message and a destination address and port, and UDP sends it as one datagram in one IP packet, unless IP fragmentation splits it. Each datagram is handled independently, so the protocol keeps no connection state on either side.
| Field | Size | Purpose |
|---|---|---|
| Source port | 16 bits | Port for replies, optional in IPv4 |
| Destination port | 16 bits | Identifies the receiving application |
| Length | 16 bits | Header plus data, minimum 8 bytes |
| Checksum | 16 bits | Covers header, data and IP pseudo-header |
The checksum is optional in IPv4 but mandatory in IPv6, because the IPv6 header has no checksum of its own. A receiver silently discards a datagram with a bad checksum; the sender is never told, which illustrates the best-effort nature of the protocol.
UDP preserves message boundaries. A 300-byte datagram arrives as exactly 300 bytes or not at all, whereas TCP delivers a continuous byte stream that the application must split into messages itself.
UDP compared with TCP and QUIC
The difference from TCP is a trade of reliability for latency and control. TCP guarantees ordered delivery but delays newer data while it recovers lost segments, an effect known as head-of-line blocking, which harms real-time media.
| Property | UDP | TCP | QUIC |
|---|---|---|---|
| Connection setup | None | Three-way handshake | Combined with TLS 1.3, 1 RTT or 0 RTT |
| Reliable delivery | No | Yes | Yes, per stream |
| Ordering | No | Yes, whole connection | Yes, per stream |
| Congestion control | None built in | Yes | Yes |
| Header overhead | 8 bytes | 20-60 bytes | UDP header plus QUIC header |
| Message boundaries | Preserved | Byte stream | Streams and datagrams |
| Multicast and broadcast | Supported | Not supported | Not supported |
QUIC shows why UDP remains relevant: it runs in user space over UDP, so new transport features can ship with applications instead of waiting for operating system kernels and middleboxes to support a new IP protocol number.
Where UDP is used
UDP fits traffic where a late packet is worthless or where requests are small and easy to repeat. In those cases, waiting for TCP retransmission costs more than an occasional loss.
| Protocol | Default port | Why UDP suits it |
|---|---|---|
| DNS | 53 | Short query and answer, client retries on timeout |
| DHCP | 67 and 68 | Client has no address yet, needs broadcast |
| NTP | 123 | Small timestamped exchanges, latency sensitive |
| SNMP | 161 and 162 | Lightweight polling and traps |
| RTP for voice and video | Dynamic range | Late audio frames are useless |
| QUIC and HTTP/3 | 443 | Own reliability above UDP |
| WireGuard VPN | Configurable, often 51820 | Tunnels any inner traffic without double retransmission |
Applications that need some reliability add it selectively, for example with sequence numbers, jitter buffers and forward error correction in media streams, or with timeouts and retries in DNS clients.
Datagram size, fragmentation and MTU
The length field permits datagrams up to 65,507 bytes of payload over IPv4, but large datagrams are fragmented at the IP layer. Losing any single fragment discards the whole datagram, and many firewalls drop fragments, so practical designs keep datagrams below the path MTU.
On a typical Ethernet path with a 1,500-byte MTU, the safe UDP payload is about 1,472 bytes over IPv4 and 1,452 bytes over IPv6. Protocols that cross tunnels and VPNs often stay near 1,200 bytes, which is the value QUIC assumes as a safe minimum.
Risks and common mistakes with UDP
Because UDP has no handshake, the source address is easy to spoof. Attackers exploit this in reflection and amplification attacks, sending small requests with a forged victim address to open services that answer with much larger responses.
| Problem | Cause | Countermeasure |
|---|---|---|
| Amplification attacks | Open resolvers or NTP and memcached servers | Close or rate-limit public UDP services |
| Silent data loss | No acknowledgments by design | Application-level sequence numbers and retries |
| Network congestion | No built-in congestion control | Rate limiting or congestion-aware design |
| Expired NAT mappings | Short UDP timeouts in NAT devices | Keepalive packets every 15-30 seconds |
| Fragment loss | Datagrams larger than the path MTU | Keep payloads near 1,200 bytes |
Another frequent error is treating UDP as reliable on a LAN. Loss is rarer there, but buffer overruns in busy receivers still drop datagrams, so robust applications must handle loss everywhere.
In everyday language
UDP is like sending postcards instead of registered letters. You write the address, drop the card in the mailbox and move on. There is no signature on delivery and no guarantee the cards arrive in order.
That sounds risky, but it is fast and simple, which matters for live calls and games, where an old message is useless anyway. When reliability matters, the program using UDP adds its own checks on top.
Seen in the real world
A company runs video meetings for remote teams. Audio and video travel as RTP packets over UDP, each carrying about 20 milliseconds of sound. When a home connection drops 2 percent of packets, the client hides the gaps with packet loss concealment and forward error correction instead of waiting for missing data.
During a test, the IT team forces the same meeting over TCP through a restrictive firewall. Whenever a packet is lost, the stream stalls until retransmission, and participants hear noticeable freezes. The team opens outbound UDP for the meeting service, and calls return to smooth, low-latency conversation with only occasional, barely audible artifacts.