UDP: User Datagram Protocol

What is UDP?

UDP (User Datagram Protocol) is a connectionless transport protocol defined in RFC 768, published in 1980. It is one of the core members of the TCP/IP protocol suite, sitting at the transport layer alongside TCP.

Unlike TCP, UDP provides no guarantees about delivery, ordering, or duplicate protection. It simply takes data from an application, wraps it in a minimal 8-byte header, and sends it over the network. There is no handshake, no connection state, and no acknowledgment. If a packet is lost, UDP does not retransmit it.

This simplicity is exactly what makes UDP valuable. By stripping away the overhead of reliable delivery, UDP achieves the lowest possible latency of any transport protocol. Applications that need speed more than perfect delivery, such as video streaming, online gaming, DNS lookups, and VoIP, rely on UDP as their foundation.

How UDP Works

UDP follows a fire-and-forget model. When an application sends data over UDP, the operating system wraps the payload in a UDP datagram, attaches source and destination port numbers, and hands it off to the IP layer. That is the entire process.

There is no handshake to establish a connection before sending data. There is no connection state maintained on either end. Each datagram is completely independent and may take a different path through the network. Datagrams can arrive out of order, arrive duplicated, or not arrive at all.

Compare this to TCP, which requires a three-way handshake (SYN, SYN-ACK, ACK) before any data can flow, maintains sequence numbers for ordering, and retransmits lost segments. TCP provides reliability, but at the cost of additional round trips, memory for connection state, and higher latency.

The diagram below illustrates the difference. TCP needs six exchanges to send a single piece of data (handshake, data, acknowledgment, teardown), while UDP sends multiple datagrams immediately with no overhead.

UDP Datagram Structure

The UDP header is beautifully simple: just 8 bytes containing four fields. This is one of the smallest headers in all of networking, and it is a deliberate design choice. Every byte of header is overhead that adds latency and consumes bandwidth.

The four fields in the UDP header are:

• Source Port (2 bytes): the port number of the sending application. This field is optional and may be set to zero if no reply is expected.
• Destination Port (2 bytes): the port number of the receiving application. This is how the operating system knows which application should receive the datagram.
• Length (2 bytes): the total length of the UDP datagram (header plus payload) in bytes. The minimum value is 8 (header only, no payload).
• Checksum (2 bytes): an error-detection value computed over the header and payload. This field is optional in IPv4 but mandatory in IPv6.

Compare this to TCP, which has a minimum header of 20 bytes and can expand to 60 bytes with options. TCP headers include sequence numbers, acknowledgment numbers, window size, flags, and more. UDP skips all of that for maximum efficiency.

UDP vs TCP: When to Use Each

Choosing between UDP and TCP depends on what your application values most. If you need guaranteed, ordered delivery, use TCP. If you need the lowest possible latency and can tolerate some data loss, use UDP.

Key Features of UDP

• Minimal overhead: the 8-byte header is 3.5 to 7.5 times smaller than TCP, leaving more room for application data in every packet.
• No connection setup delay: data can be sent immediately without waiting for a handshake, which saves at least one full round trip compared to TCP.
• Broadcast and multicast support: UDP can send a single datagram to multiple recipients simultaneously, which is not possible with TCP.
• Stateless design: the server does not maintain per-client connection state, which allows a single server to handle far more clients than TCP.
• No head-of-line blocking: if one packet is lost, it does not block delivery of subsequent packets. Each datagram is independent.
• Application-controlled reliability:applications can implement exactly the level of reliability they need on top of UDP, rather than accepting TCP's one-size-fits-all approach.

Common Use Cases for UDP

• DNS lookups: DNS queries are small and need fast responses. A single UDP datagram carries the question, and a single datagram carries the answer. No connection setup required.
• Video and audio streaming: latency matters more than perfect delivery. A dropped video frame is invisible, but waiting for a retransmission causes visible stuttering.
• Online gaming: games send real-time state updates dozens of times per second. Stale data is useless, so retransmitting a lost packet wastes time that could be spent sending the latest game state.
• VoIP (Voice over IP): voice calls require consistent low latency. A brief gap in audio is less noticeable than the delay caused by retransmission.
• IoT sensor data:lightweight devices sending frequent measurements benefit from UDP's low overhead and minimal memory requirements.
• DHCP: network configuration uses UDP because the client does not yet have an IP address and cannot establish a TCP connection.
• NTP (time synchronization): accurate timekeeping requires the lowest possible latency. Adding TCP overhead would reduce the precision of time measurements.
• QUIC and HTTP/3:the newest version of HTTP builds a reliable, multiplexed transport layer on top of UDP, combining UDP's speed with custom reliability mechanisms.

Building Reliability on Top of UDP

Some applications need both speed and some degree of reliability. Rather than accepting all of TCP's overhead, these applications build custom reliability layers on top of UDP. This approach allows them to pick exactly the features they need while avoiding the ones they do not.

QUIC, the protocol behind HTTP/3, is the most prominent example. QUIC runs over UDP but implements its own connection management, encryption (TLS 1.3 is built in), congestion control, and multiplexed streams. Unlike TCP, QUIC handles packet loss per-stream rather than per-connection, which eliminates head-of-line blocking.

WebRTC uses UDP for real-time audio and video communication in web browsers. It adds selective retransmission for critical data (like keyframes) while allowing non-critical data to be dropped without delay.

Game netcode commonly implements application-level acknowledgments, sequence numbers, and forward error correction on top of UDP. Each game can tune these mechanisms to its specific requirements: a fast-paced shooter has different needs than a turn-based strategy game.

Frequently Asked Questions About UDP

Is UDP faster than TCP?

Yes. UDP has lower latency because it skips connection setup, does not wait for acknowledgments, and has a smaller header. TCP requires at least one round trip for the handshake before any data can flow. UDP can send data immediately.

Why does DNS use UDP instead of TCP?

DNS queries and responses are typically small enough to fit in a single datagram. Using TCP would add unnecessary overhead from the three-way handshake, which would roughly triple the time for a simple lookup. DNS does fall back to TCP for large responses (over 512 bytes) or zone transfers.

Can UDP packets arrive out of order?

Yes. Each UDP datagram is routed independently and may take a different path through the network. There is no mechanism in UDP to reorder packets. If ordering matters, the application must handle it.

Is UDP secure?

UDP itself provides no encryption or authentication. Data is sent in plaintext and can be intercepted or spoofed. To secure UDP traffic, applications use DTLS (Datagram Transport Layer Security) or build encryption into the application layer, as QUIC does with built-in TLS 1.3.

What is the maximum UDP datagram size?

The theoretical maximum is 65,535 bytes (the largest value the 16-bit Length field can hold), including the 8-byte header. In practice, datagrams larger than the network MTU (typically 1,500 bytes for Ethernet) will be fragmented at the IP layer, which increases the chance of loss. Most applications keep UDP payloads well under 1,472 bytes to avoid fragmentation.

Why does HTTP/3 use UDP instead of TCP?

HTTP/3 uses QUIC, which runs over UDP, to solve TCP's head-of-line blocking problem. In TCP, a single lost packet blocks all streams on that connection. QUIC handles loss per-stream, so one lost packet only affects the stream it belongs to. QUIC also provides faster connection setup with 0-RTT resumption and handles network changes (like switching from WiFi to cellular) without dropping the connection.

Related Protocols

• TCP: connection-oriented transport protocol that provides reliable, ordered delivery
• HTTP: application layer protocol for the web, traditionally built on TCP
• HTTPS: HTTP with TLS encryption for secure web communication
• Modbus TCP: industrial protocol that uses TCP/IP for device communication