VMware ESXi and vSphere Cluster Management

User Datagram Protocol (UDP) Explained

Learn how UDP works at OSI Layer 4, its datagram header, ports, limitations, TCP differences, and common uses such as VoIP, DNS, DHCP, and NFS.

User Datagram Protocol (UDP) is a transport-layer protocol in the TCP/IP suite. It delivers application data between hosts with minimal overhead. UDP is defined at OSI Layer 4, the transport layer, which provides host-to-host application delivery and uses port numbers to identify processes.

Unlike TCP, UDP does not establish a connection before sending data. It sends independent units called datagrams. This design is fast and simple, but UDP does not include built-in guarantees that data will arrive, arrive once, or arrive in the original order.

UDP's Place in the Network Stack

An application creates data and passes it to UDP. UDP adds a small transport header, then passes the resulting datagram to IP for delivery across the network.

• Application layer: Creates messages for services such as VoIP, DNS, DHCP, or NFS.
• Transport layer: UDP identifies the sending and receiving applications with port numbers.
• Internet layer: IP provides logical addressing and forwards packets between networks.
• Link and physical layers: Move frames and signals across each local connection.

For example, an incoming UDP datagram might contain destination port 5000. The operating system uses that port to deliver the payload to the application listening on UDP port 5000. The IP address identifies the host; the port identifies the application on that host.

How Connectionless UDP Works

Connectionless means that UDP does not create a session or virtual circuit before transmitting data. There is no connection-establishment exchange comparable to TCP's three-way handshake.

1. An application gives a message to UDP.
2. UDP adds source and destination ports, length, and checksum information.
3. IP carries the UDP datagram toward the destination host.
4. The destination host uses the destination port to pass the payload to the appropriate application.

Each datagram is independent. An application can send one datagram, wait, send another, or send several without first negotiating a transport session. The network may deliver these datagrams in a different order, or may not deliver some of them at all.

UDP Reliability: Best-Effort Delivery

UDP is often described as unreliable or best-effort transport. In this context, unreliable does not mean that every UDP transmission fails. Many UDP datagrams arrive successfully. It means that UDP itself does not guarantee successful, unique, timely, or ordered delivery.

UDP does not provide:

• Acknowledgments: The receiver does not automatically confirm receipt to the sender.
• Retransmissions: UDP does not resend a datagram merely because it was lost.
• Sequencing: UDP does not assign transport-level sequence information.
• Ordered delivery: UDP does not reorder datagrams that arrive out of order.
• Flow control: UDP does not regulate its sending rate to prevent overwhelming a receiver.

A datagram can be lost, duplicated, delayed, or delivered out of order. UDP passes these conditions to the application rather than correcting them. An application that needs reliability can add message identifiers, acknowledgments, retries, buffering, or other recovery logic above UDP.

Example: Out-of-Order Datagrams

Suppose an application sends datagrams numbered 1 and 2. Network paths or queue delays may cause datagram 2 to arrive before datagram 1. UDP delivers each datagram as it arrives; it does not hold datagram 2 and reorder the messages. The application must decide whether to process, buffer, or discard the data.

Why UDP Has Low Overhead

UDP has an 8-byte header and no connection-management exchange. It also avoids transport-level acknowledgments, retransmission tracking, sequencing, ordering, and flow-control windows. These characteristics generally require less processing, memory, and protocol traffic than TCP.

The trade-off is important: UDP can reduce latency and keep communication simple, but the application gives up built-in delivery guarantees. UDP is therefore useful when current information is more valuable than recovering every missing piece of old information.

UDP Datagram and Header Format

A UDP datagram consists of an 8-byte header followed by application data, also called the payload. The header contains four fields, each 16 bits long.

Calculating the UDP Length

The UDP length includes both the fixed header and the application payload:

UDP length = UDP header length + payload length
UDP length = 8 bytes + 32 bytes
UDP length = 40 bytes

In this example, the Length field contains 40 bytes, not 32 bytes, because it counts the header as well as the payload.

UDP Checksum and IP Version

The checksum helps detect corruption in the UDP header and payload while they are in transit. UDP checksum rules differ by IP version: the checksum is mandatory in IPv6 and optional in IPv4. A packet capture on the sending host can also show apparent checksum errors when the network interface has checksum offloading enabled; the interface may calculate the checksum after the capture point.

UDP Versus TCP

TCP is a connection-oriented transport protocol. It establishes a connection and provides reliable, ordered delivery using mechanisms such as acknowledgments, sequence information, retransmissions, and flow control. UDP is connectionless and leaves these responsibilities to the application, if they are needed.

The choice is based on application requirements, not on the idea that one protocol is always better. A file transfer usually needs complete, ordered data, making TCP or an application-managed reliable design appropriate. A live voice stream may prefer timely delivery, even if an occasional packet is lost.

When UDP Is a Good Fit

VoIP and Real-Time Audio

Voice over IP, or VoIP, is a latency-sensitive example. If one voice datagram is lost, the receiver may produce a brief gap or use audio concealment. Waiting for a retransmission of an old voice packet may cause a noticeable delay, making the conversation less natural. For live audio, continuing with current audio can be more useful than receiving every previous packet.

NFS and Application-Layer Recovery

Network File System (NFS) can use application-layer logic to detect missing responses and retry requests. In this model, recovery is designed by the application rather than supplied automatically by UDP. The application can choose suitable timeouts, request identifiers, and retry behavior.

Other UDP Examples

DNS commonly uses UDP for short request-and-response exchanges because the low overhead is useful. DHCP uses UDP so a host can communicate during configuration before it has a normal IP setup. These protocols have their own message formats and reliability behavior; using UDP does not make every application identical.

Port-Based Delivery Example

Imagine a client sending a DNS query with source port 53000 and destination port 53:

Source IP:        192.0.2.25
Source port:      53000
Destination IP:   198.51.100.53
Destination port: 53
Transport:        UDP

The source port identifies the client-side application endpoint, while destination port 53 identifies the DNS service on the destination host. The response can use port 53000 as its destination so the operating system can deliver it back to the correct client process.

Troubleshooting UDP

Missing or Incomplete Data

Symptom: An application receives incomplete information. Likely cause: One or more datagrams were dropped, and UDP did not retransmit them. Check packet loss along the path and determine whether the application has retry, recovery, or loss-concealment logic.

Data Arrives in the Wrong Order

Symptom: Application output is out of order. Likely cause: UDP does not sequence or reorder datagrams. Check whether the application includes message identifiers, sequence values, or its own ordering mechanism.

UDP Service Receives Nothing

Symptom: A UDP service is not receiving traffic. Verify the destination IP address and port, confirm that the expected process is listening, and check host firewalls, network ACLs, and other filtering devices.

Checksum Errors in a Capture

Symptom: A packet analyzer reports checksum errors. The packet may be corrupt, but checksum offloading can also make a capture taken on the sending host appear invalid. Compare captures at multiple points and account for the network interface's offloading behavior.

Packet Capture Demonstration

A packet capture tool such as Wireshark can display UDP traffic. Use the display filter below:

udp

Inspect the source port, destination port, UDP length, checksum, and payload. Compare the UDP length with the captured header and payload sizes. A host-level socket inspection tool can also show which processes are listening on UDP ports.

Key Takeaways

• UDP is a transport-layer protocol in the TCP/IP suite and operates at OSI Layer 4.
• Port numbers identify the sending and receiving applications.
• UDP sends independent datagrams without connection setup.
• Its 8-byte header contains source port, destination port, length, and checksum fields.
• UDP is best effort: successful delivery is possible, but not guaranteed or corrected by UDP itself.
• UDP is a good fit when low overhead and timeliness matter, or when the application supplies its own recovery.
• TCP is generally preferable when complete, reliable, and ordered delivery is required.