4.3.7 UDP

Connectionless Transport with UDP

User Datagram Protocol, usually called UDP, is a transport layer protocol that sits alongside TCP. Both share the same basic job, which is to move application data between hosts using ports, but they do this in very different ways. Where TCP focuses on reliability and ordering, UDP focuses on simplicity and speed.

UDP is often described as a connectionless, best effort protocol. It does not establish a session before sending data, it does not track the state of a conversation, and it does not guarantee delivery. Instead, it gives applications a very lightweight way to send small, independent messages called datagrams.

Because many of the general ideas of the transport layer and the comparison with TCP are covered in other chapters, this section concentrates on what is specific to UDP itself: its behavior, its header, and what types of applications use it.

Connectionless and Best Effort Behavior

A key characteristic of UDP is that it does not create or manage a connection. Each UDP packet is treated as a separate unit of data. There is no handshake, no acknowledgment, and no teardown at the transport layer.

When an application sends data with UDP, the operating system wraps that data into a UDP datagram and passes it to the IP layer. The network forwards the datagram toward the destination, but there is no built in mechanism in UDP to confirm that the datagram arrives.

As a result, UDP is called a best effort protocol. The network will try to deliver the packet, but any of these can happen without UDP itself noticing or correcting it:

A datagram may be dropped.
Datagrams may arrive out of order.
The same datagram may be duplicated.
The contents may be delayed.

If an application requires reliability, ordering, or duplicate detection on top of UDP, it must implement these features itself, at the application layer or in a separate library.

UDP Header Structure

Although UDP is simpler than TCP, it still has a defined header. The UDP header has a fixed size of 8 bytes, which is much smaller than the minimum TCP header. This is one of the reasons UDP is attractive for low overhead communication.

A UDP datagram consists of the header followed by user data:

The source and destination port fields identify which application on each host should send or receive the data. The length field contains the size in bytes of the entire UDP segment, header plus data. The minimum value for this length is 8, which corresponds to a datagram with only a header and no payload.

The checksum provides a basic integrity check. It is calculated over the UDP header, the data, and a small pseudo header that is derived from fields in the IP header such as source and destination IP addresses. If the checksum does not match at the receiving end, the UDP datagram is discarded.

Lightweight Operation and Low Overhead

UDP is designed for simplicity. It does not maintain complex state information per connection, and it does not have mechanisms such as sliding windows or sequence numbers at the transport layer. This minimalism brings specific advantages.

First, the smaller header and lack of control traffic reduce overhead. Less bandwidth is spent on control information, which can be valuable for applications that send many small messages, such as queries or position updates.

Second, the absence of connection management means that UDP does not require any setup before sending data. An application can send a single datagram to a server, receive a response, and be done, with no extra packets to open or close a connection.

Third, UDP does not perform congestion control at the transport layer. While this can be dangerous if misused, it also allows some applications to send at a steady rate that they control directly, which is useful for real time traffic like audio and video.

Because UDP is stateless, servers that use UDP can potentially support a very large number of clients without storing per connection state for each one. All the state can remain on the client side or inside the application logic rather than inside the transport layer.

UDP and Ports

Like TCP, UDP uses port numbers to distinguish different application conversations on a host. Port numbers are 16 bit values, so the range is from 0 to 65535. Many well known services have standardized UDP ports, such as DNS on port 53 and DHCP on ports 67 and 68.

A host can have processes listening on UDP ports just as it can have processes listening on TCP ports. However, because UDP is connectionless, the listening process does not accept or maintain per client sessions at the transport layer. Instead, it receives individual datagrams that are addressed to its port and may respond with its own datagrams.

One important effect of this behavior is that multiple clients can communicate with the same UDP server port independently, without the server needing to track a connection object like a TCP socket state for each client. The server application may still track clients at the application layer, but UDP itself treats each datagram separately.

When UDP Is a Good Choice

UDP is not simply a weaker version of TCP. It is a different tool that is better suited for some types of applications. In particular, UDP is often chosen when applications value timeliness and low overhead more than perfect delivery.

Real time applications are a common example. In live voice or video communication, it is often better to skip a late packet than to delay playback while waiting for a retransmission. A small glitch in audio or a brief artifact in video is usually more acceptable than lag. UDP enables the application to send a continuous stream and handle loss in a way that fits the media.

Another use case is simple request response protocols. A client sends a short query and expects a short response. DNS is a classic example. For a typical DNS lookup, there is no need to keep a long lived transport connection. UDP allows the entire interaction to be just a pair of datagrams, one in each direction.

UDP is also widely used in discovery protocols and broadcast or multicast scenarios. Because UDP packets do not require a direct, established connection, they can be sent to many listeners at once using special destination addresses. This is useful for finding services on a local network or distributing the same information to many recipients.

Handling Reliability Outside UDP

Many applications need some degree of reliability even when they use UDP. Since UDP itself does not provide acknowledgments or retransmissions, these must be implemented at a higher layer when required.

A common pattern is for the application to attach its own sequence numbers to messages. When the receiver notices a gap in the sequence, it can infer that one or more messages are missing. The application then decides whether to ignore the loss, request a resend, or adjust its behavior in some other way.

The application can also implement its own timeout and acknowledgment system. Each message can carry an identifier, and the receiver can send back an application level acknowledgment. If the sender does not receive this acknowledgment within a certain time, it may resend the message.

This approach gives applications great flexibility. They can design their own rules about what to retry, when to give up, and how much history to keep. However, it also means that application developers must handle complexity that TCP would otherwise manage automatically.

Packet Size and Fragmentation Concerns

UDP messages are carried by IP, so they are limited by the maximum transmission unit, or MTU, of the underlying network. If a UDP datagram is too large to fit into a single IP packet, the IP layer may fragment it into multiple pieces.

Fragmentation can be risky for UDP applications. If any fragment is lost, the entire datagram becomes unusable. Because UDP has no retransmission mechanism, a single lost fragment means the application will not see the complete message at all.

For this reason, many UDP based protocols intentionally keep their messages small enough to avoid fragmentation on typical networks. They may limit their payload size so that, when added to the 8 byte UDP header and the IP header, the total stays within common MTU values such as 1500 bytes for Ethernet.

Security Considerations with UDP

UDP’s lack of state and control information makes it a flexible tool, but it also introduces certain security concerns.

Because there is no handshake, it is easy to send forged UDP packets with a fake source IP address. Attackers can exploit this behavior in reflection and amplification attacks. For example, they send small UDP requests with a spoofed source address to many servers, and each server replies with a larger response toward the victim’s address.

Some UDP based services are also prone to amplification because a small query can generate a much larger reply. This means that attackers can multiply their outgoing traffic volume through misused public UDP services.

Firewalls and other security devices must pay attention to UDP traffic because there is no built in session management. Devices cannot always rely on the same kind of connection tracking that is commonly used for TCP, so filtering rules need to be carefully designed.

Summary of UDP Characteristics

It is useful to gather the main traits of UDP in one place to reinforce how it differs in behavior from other transport protocols.

UDP is connectionless. There is no handshake or teardown at the transport layer, and each datagram stands alone.

It provides best effort delivery. There are no built in guarantees of delivery, ordering, or duplicate suppression.

The header is small and fixed at 8 bytes. It contains only source port, destination port, length, and checksum.

UDP uses ports to identify applications, but it does not maintain per connection state like TCP.

Applications commonly use UDP when low latency and low overhead are more important than strict reliability, or when they want to manage reliability themselves.

By understanding these properties, you can recognize when UDP is an appropriate choice and how higher layer protocols build on it to implement features that the transport layer intentionally leaves out.