User Datagram Protocol (UDP) Explained

Learn how UDP works at OSI Layer 4, including connectionless delivery, datagram structure, header fields, UDP versus TCP, and common use cases.

What Is UDP?

User Datagram Protocol (UDP) is a connectionless protocol in the TCP/IP suite. It operates at OSI Layer 4, the Transport layer, which provides communication services between applications running on networked hosts. For background, review the OSI Reference Model.

UDP accepts application data, adds a UDP header, and creates an independent unit called a datagram. IP then carries that UDP datagram across the network toward the destination host.

Encapsulation can be summarized as:

Application data → UDP datagram → IP packet → Link-layer frame

The UDP datagram consists of an 8-byte UDP header followed by the application payload.

How Connectionless Operation Works

UDP is connectionless, meaning that the endpoints do not establish a connection or virtual circuit before sending application data. There is no UDP equivalent of TCP's connection-establishment exchange.

A sender can transmit a datagram immediately after obtaining the destination address and port. Each datagram is handled independently, so UDP does not maintain a transport-layer session that tracks every packet sent between the applications.

For example, a client might send a datagram from an ephemeral source port to a server's known destination port:

Client application:  source port 49152 → destination port 5000 → Server application

The destination port helps the receiving host deliver the datagram to the correct application.

Best-Effort and Unreliable Delivery

UDP provides a best-effort service. It does not guarantee that an application datagram will arrive successfully, arrive only once, or arrive in the same order in which it was sent.

UDP itself does not provide:

Acknowledgments
Retransmissions
Sequence numbers for ordered delivery
Guaranteed ordered delivery
Transport-layer flow control
Transport-layer congestion control

Consequently, datagrams can be lost, duplicated, delayed, or received out of order. If two datagrams are sent, the receiver might receive both in the wrong order, receive only one, or receive duplicates. UDP does not correct these conditions.

Why Applications Use UDP

UDP has less protocol overhead than TCP because it provides fewer transport services. Its header is only 8 bytes, and it does not require connection setup, acknowledgments, retransmissions, or connection state for each exchange. This can reduce processing and initial latency.

The trade-off is between timeliness and delivery assurance. An application may prefer a current packet that arrives quickly rather than a missing packet that is retransmitted after it is no longer useful.

Voice over IP Example

Voice over IP (VoIP) commonly values low delay. If an audio packet is lost, waiting for a retransmission may create a late gap in the conversation. The application may conceal the small loss and continue playing newer audio instead.

Application-Managed Recovery

UDP does not prevent an application from adding its own reliability features. An application can add sequence numbers, acknowledgments, retransmission logic, checks for missing data, or other recovery mechanisms above UDP when its requirements justify them.

Network File System (NFS) can illustrate this design approach: an application or higher-level protocol can implement recovery behavior instead of relying on UDP itself to retransmit data.

UDP Header Format

The UDP header is exactly 8 bytes long. It contains four fields, each 16 bits in size.

Field	Size	Purpose
Source Port	16 bits	Identifies the sending application. A client commonly uses an ephemeral port.
Destination Port	16 bits	Identifies the receiving application on the destination host.
Length	16 bits	Specifies the combined size of the UDP header and UDP payload.
Checksum	16 bits	Provides error detection for the UDP header and payload, with requirements that depend on the IP version.

Source and Destination Ports

Port numbers identify application endpoints on a host. The source port identifies the sending application, while the destination port identifies the intended receiving application.

Multiplexing is the process of combining traffic from multiple applications for transmission through the network stack. Demultiplexing is the receiving host's process of examining port information and delivering each datagram to the correct application.

Length Field

The UDP length field counts both the 8-byte UDP header and the payload. It does not describe only the application data.

Checksum Field

The checksum is an error-detection value. It allows the receiving system to detect certain changes to the UDP header and payload that may have occurred during transmission.

Checksum rules differ between IP versions:

In IPv6, the UDP checksum is mandatory.
In IPv4, a checksum value of zero indicates that no UDP checksum was used.

A checksum can detect corruption, but it does not provide retransmission, ordering, or a guarantee that the datagram reached its destination.

Conceptual UDP Header Diagram

  0                   15 16                  31
 +---------------------+---------------------+
 |     Source Port     |  Destination Port   |
 +---------------------+---------------------+
 |       Length        |      Checksum       |
 +---------------------+---------------------+
 |                 Data (variable)           |
 +-------------------------------------------+

UDP and TCP Comparison

TCP, or Transmission Control Protocol, is a connection-oriented transport protocol. It provides a reliable, ordered byte-stream service. UDP instead sends independent datagrams and leaves optional recovery or ordering features to the application.

Characteristic	UDP	TCP
Connection setup	Connectionless; no setup handshake is required before sending.	Connection-oriented; endpoints establish a connection before exchanging data.
Delivery guarantee	No transport-layer guarantee of delivery.	Provides reliable delivery using acknowledgments and recovery mechanisms.
Ordering	Does not guarantee ordered delivery.	Provides an ordered byte stream to the application.
Retransmission	None provided by UDP.	Retransmits data when necessary.
Header size	8 bytes.	At least 20 bytes, before optional TCP header fields.
Overhead	Lower overhead and less transport-layer state.	Higher overhead because of connection management, reliability, ordering, and control features.
Typical use case	Latency-sensitive traffic or applications that manage delivery themselves.	Applications requiring complete, ordered delivery.

Choose UDP when timely delivery matters more than recovering every lost packet, or when the application has its own delivery logic. Choose TCP when the application requires complete, ordered data and should not have to implement those transport functions itself.

When Is UDP Appropriate?

Application characteristic	Why UDP can fit	Trade-off
Latency-sensitive media	Datagrams can be sent without connection setup or transport retransmission delays.	Lost or delayed media may create gaps or reduced quality.
Tolerates occasional loss	The application can continue operating when individual datagrams are missing.	There is no built-in guarantee that loss remains occasional.
Application provides recovery	The application can implement only the sequencing, acknowledgments, or recovery features it needs.	Those features require additional application design and processing.

UDP Communication Example

Consider a client sending two independent datagrams to a server:

Client application
        ↓
      UDP: source port 49152, destination port 5000
        ↓
      IP network
        ↓
      UDP: destination port 5000
        ↓
Server application listening on UDP port 5000

The sender does not first create a UDP connection. The network may deliver the datagrams in order, out of order, only partially, or not at all. If the application needs to identify missing or reordered data, it must add that capability itself.

Troubleshooting UDP Behavior

Missing or Out-of-Order Data

Symptom: An application using UDP has missing or out-of-order data.

This can be normal UDP behavior because UDP does not sequence datagrams or retransmit losses. Determine whether the application is designed to tolerate loss or provides its own ordering and recovery mechanism.

Gaps in Real-Time Audio

Symptom: A real-time voice application has gaps in audio.

UDP does not restore lost packets, and retransmission may be intentionally avoided to preserve low latency. Investigate packet loss, delay, and network congestion rather than expecting UDP itself to restore audio packets.

Traffic Reaches the Host but Not the Application

Symptom: Traffic reaches a host but not the intended application.

UDP uses the destination port to select the receiving application. Verify the destination UDP port and confirm that the target application is listening on that port.

Key Terms

Datagram: An independent UDP unit containing a UDP header and application payload.
Connectionless: No connection setup or virtual circuit is established before data is sent.
Unreliable delivery: Best-effort delivery with no transport-layer guarantee that data arrives, arrives once, or arrives in order.
Transport layer: OSI Layer 4, responsible for end-to-end communication services between applications.
Multiplexing and demultiplexing: Using port numbers to combine application traffic at the sender and deliver it to the correct application at the receiver.

Summary

UDP is a TCP/IP Transport-layer protocol operating at OSI Layer 4.
It carries application data in independent datagrams over IP.
It is connectionless and requires no connection-establishment handshake.
It has an 8-byte header containing source port, destination port, length, and checksum fields.
It does not provide acknowledgments, retransmissions, ordering, flow control, or congestion control.
Its low overhead and low setup latency suit time-sensitive applications and application-managed reliability.
TCP is generally preferred when complete, reliable, and ordered delivery is required.