VMware ESXi and vSphere Cluster Management

User Datagram Protocol (UDP)

Learn how UDP works at OSI Layer 4, including datagrams, ports, headers, checksums, delivery behavior, TCP differences, use cases, and troubleshooting.

User Datagram Protocol (UDP) is an Internet transport-layer protocol for exchanging data between application processes on different hosts. UDP operates at Layer 4 of the OSI model and at the transport layer of the TCP/IP model.

UDP places application data into an independent datagram. IP then carries that datagram across one or more networks:

Application data
      ↓
UDP header + application data = UDP datagram
      ↓
IP header + UDP datagram = IP packet

The transport layer uses port numbers to deliver received data to the correct application. For a broader overview of this protocol, see User Datagram Protocol (UDP).

How UDP Operates

Connectionless transmission

UDP is connectionless. Before sending data, it does not establish a transport-level connection, perform a handshake, or create a virtual circuit. Each datagram is sent independently, without transport-level session setup.

Connectionless does not mean that an application cannot maintain a session. An application can keep its own login state, conversation identifier, sequence number, timeout, or authentication information. UDP simply does not provide that session behavior itself.

Independent datagrams

UDP preserves message boundaries: one application write commonly becomes one UDP datagram, subject to the application and operating system. Each datagram can follow a different path or experience different delay. UDP does not treat the data as one continuous byte stream.

Delivery Behavior and Reliability

UDP provides best-effort transport. IP and UDP do not provide an end-to-end guarantee that a datagram will reach its destination. UDP does not:

• Guarantee delivery.
• Acknowledge receipt.
• Retransmit lost datagrams.
• Assign transport-level sequence numbers.
• Reorder arriving datagrams.
• Prevent duplicate delivery.

As a result, datagrams can be lost, duplicated, delayed, or delivered out of order. A receiver may get datagram 3 before datagram 2, or may never receive datagram 2 at all.

The UDP checksum can detect some corruption, but it cannot repair corrupted data or recover a missing datagram. An application that needs reliability must implement suitable recovery above UDP.

UDP Efficiency and Trade-offs

UDP has lower protocol overhead than TCP because it does not provide connection establishment, acknowledgments, sequencing, retransmission, or transport-level flow control. This can reduce latency, memory use, and processing work.

UDP is not automatically faster in every situation. Its suitability depends on the application and network conditions. The application may need to implement:

• Loss detection and retransmission.
• Message ordering or duplicate suppression.
• Timeouts and retry limits.
• Pacing and congestion response.
• Authentication, session management, or encryption.

UDP's lack of TCP-style congestion control does not permit an application to send without restraint. UDP applications should measure network conditions and avoid creating excessive congestion.

UDP Datagram and Header Format

Every UDP datagram begins with a fixed 8-byte header. The header contains four fields, each 16 bits wide.

A simplified layout is:

0                   15 16                  31
+---------------------+---------------------+
|     Source port     |  Destination port   |
+---------------------+---------------------+
|       Length        |      Checksum       |
+---------------------+---------------------+
|              Application payload ...      |
+-------------------------------------------+

UDP length calculation

The UDP length field includes both the 8-byte header and the payload. The minimum UDP length is therefore 8 bytes, representing a datagram with no payload.

To calculate payload size:

payload length = UDP length - 8

For example, if the UDP length is 68 bytes, the header occupies 8 bytes and the payload occupies 60 bytes.

UDP Checksum

The checksum detects errors in the UDP header and payload. Its calculation also includes an IP pseudo-header: selected IP addressing and protocol information that helps detect delivery to the wrong endpoints. The pseudo-header is used in the calculation but is not transmitted as part of the UDP header.

If checksum validation fails, the receiving system discards the datagram rather than repairing it. A valid checksum does not prove that the datagram was delivered, delivered only once, delivered in order, or protected from every possible failure.

• In IPv4, the UDP checksum is technically optional, although it is generally used.
• In IPv6, a UDP checksum is required.

IPv6 applications or network stacks that generate an absent or invalid checksum can therefore experience dropped traffic even when the same design appeared to work over IPv4.

Ports and Application Delivery

A port is a transport-layer identifier used to deliver data to an application or service. Ports enable multiplexing: many applications can share one host's network connection. They also enable demultiplexing: the host can direct each incoming datagram to the appropriate application.

The destination port identifies where the datagram should go on the receiving host. The source port identifies the sending application and gives the receiver a port to which it can send a reply.

Port ranges are commonly described as:

• Well-known ports: lower-numbered ports commonly assigned to standard services.
• Registered ports: ports associated with particular applications or services.
• Ephemeral ports: temporary ports usually selected for client-side communication.

For example, a DNS client can send a query from a temporary source port to a DNS server at UDP destination port 53. The server's response is sent back to the client's source port. DNS may retry or use another transport when a response is too large or otherwise unsuitable for UDP.

TCP and UDP both use port numbers, but their port spaces are separate. A TCP service and a UDP service can use the same numeric port without being the same transport endpoint.

When Applications Choose UDP

UDP is often appropriate when an application can tolerate some loss, values timely data more than late data, needs message boundaries, or implements recovery at the application layer.

Real-time voice and VoIP

In real-time voice, a delayed audio packet may arrive after the conversation has moved on. Continuing with newer audio can be better than waiting for a retransmission. A voice application may conceal a small loss, use an audio codec's recovery features, or adapt its quality.

Games and real-time state updates

An online game may send frequent position or state updates. If an older update is missing, the application may discard it because a newer update makes it obsolete. The application can add sequence numbers and timestamps when it needs to detect stale, missing, or out-of-order updates.

NFS and application-managed recovery

Network File System (NFS) illustrates that reliability can be handled by a higher-layer protocol. An NFS implementation can identify an unanswered operation, wait, and retry or recover according to its own rules. This is different from UDP providing reliable delivery.

Other examples

• DNS queries and responses.
• DHCP messages.
• Online gaming traffic.
• Streaming and real-time media.
• Some monitoring, discovery, and service-management protocols.

Actual transport choices can vary by protocol version, implementation, message size, security requirements, and network environment.

UDP Compared with TCP

The key choice is not simply “fast versus slow.” TCP supplies substantial coordination and recovery. UDP supplies a small transport mechanism and lets the application decide which behavior is necessary.

Size, Fragmentation, Firewalls, and NAT

Datagram size and fragmentation

UDP payload size is constrained by the IP packet size and by the characteristics of the network path. If an IP packet is too large for a link's maximum transmission unit, it may be fragmented. Losing any one fragment can prevent the receiver from reassembling the complete IP packet and therefore the complete UDP datagram.

Keep datagrams appropriately sized when possible. Avoiding fragmentation reduces the chance that one lost fragment will discard an otherwise useful message. Path MTU behavior, headers, tunnels, and network configuration all affect the practical maximum size.

Firewalls and NAT

Firewalls, security groups, and network address translation devices may require explicit UDP rules or state handling. Because UDP has no handshake that universally confirms a session, a device may create temporary state when an outbound datagram is observed, or may reject unsolicited inbound traffic.

A UDP service that is unreachable may produce an ICMP error, or the client may simply time out. UDP itself does not establish connection state that proves a service is listening.

Practical UDP Lab

Observe UDP traffic

With authorization and on a controlled system, capture UDP traffic using:

tcpdump -n -i <interface> udp

In Wireshark, use this display filter:

udp

Inspect the source port, destination port, UDP length, payload, and checksum status. A packet analyzer may report that a checksum is invalid because of checksum offloading; compare captures from an appropriate location before concluding that packets are corrupt.

Send a local UDP message

On systems whose netcat syntax supports these options, start a listener:

nc -u -l 9999

From another terminal, send a message:

printf 'hello\n' | nc -u 127.0.0.1 9999

Netcat options differ across operating systems. This example demonstrates that a sender can transmit a UDP datagram without a TCP-style connection handshake.

Inspect local UDP listeners

ss -uln
# Alternative on systems that provide it:
netstat -uln

These commands show local UDP sockets or ports that are listening. Availability and output vary by operating system.

Troubleshooting UDP

No reply from a UDP application

Possible causes include:

• No service is listening on the destination UDP port.
• A host firewall, network firewall, or security group blocks the traffic.
• The destination address or port is incorrect.
• The response was lost; UDP does not retransmit it.
• NAT state or return-path rules prevent the reply.

Check the destination address and port, confirm that the server has a UDP socket listening, and capture traffic on both sides when authorized. Check firewall rules in both directions. Applications should use appropriate timeouts, retries, and response identifiers when their use case requires them.

Missing, duplicate, or out-of-order messages

This can be normal UDP behavior. Congestion and queue drops can cause loss, while path variation can cause reordering. Fragmentation can also cause loss when one fragment does not arrive.

Add application message sequence numbers and timestamps to measure loss and reordering. Reduce datagram size where practical, and implement application-level recovery only when the application needs it.

Works over IPv4 but not IPv6

Check for an invalid or absent UDP checksum: IPv4 permits an optional UDP checksum, while IPv6 requires one. Also compare IPv4 and IPv6 firewall policies, addressing, and routing. A packet analyzer can help inspect checksum status.

Exam-Relevant Summary

• UDP is a Layer 4 transport protocol in the OSI model.
• It carries application data between processes using port numbers.
• UDP is connectionless and sends independent datagrams.
• UDP does not guarantee delivery, ordering, duplicate prevention, acknowledgment, or retransmission.
• The UDP header is fixed at 8 bytes and has four 16-bit fields: source port, destination port, length, and checksum.
• The length field includes the header and payload; payload length equals UDP length minus 8.
• The checksum detects errors but does not provide recovery or delivery assurance.
• UDP checksums are optional in IPv4 but required in IPv6.
• UDP can reduce overhead and latency, but applications must supply any required reliability, ordering, pacing, and recovery.
• UDP and TCP use separate port spaces. TCP has a minimum 20-byte header and provides reliable ordered byte-stream delivery, flow control, and congestion control.
• Large UDP datagrams may be fragmented; losing one fragment can lose the entire datagram.