Nmap online course

User Datagram Protocol (UDP): Concepts, Header Fields, and Use Cases

Learn how UDP works at OSI Layer 4, including connectionless delivery, ports, the 8-byte header, checksum, reliability trade-offs, and UDP versus TCP.

What Is UDP?

User Datagram Protocol (UDP) is a lightweight transport-layer protocol in the TCP/IP suite. It is commonly mapped to OSI Layer 4, the transport layer. This layer supports communication between applications running on different networked hosts.

UDP carries application data in independent units called datagrams. A datagram contains a UDP header and application payload. Unlike TCP, UDP does not try to create a reliable, ordered byte stream. Its smaller feature set makes it useful when an application values low delay, low overhead, or direct control over recovery behavior.

UDP is used with IP. IP provides network-layer addressing and packet forwarding, while UDP identifies application endpoints with port numbers and adds a small amount of transport-layer information.

For background on the protocol stack, see the OSI model and the TCP/IP suite of protocols.

Connectionless Operation

UDP is connectionless. This means that the sender does not first establish a session or virtual circuit with the receiver before transmitting data. Each datagram is sent independently.

There is no TCP-style connection establishment before UDP data transmission. A sender can create a datagram, identify the destination IP address and port, and pass it to the network immediately. The receiving host can process the datagram if a suitable application is listening on the destination port.

This design reduces setup overhead and the amount of transport state that hosts must maintain. UDP does not need to track a connection's establishment, sequence window, acknowledgments, or retransmission queue. The trade-off is that UDP itself provides fewer delivery guarantees.

What Connectionless Does Not Mean

Connectionless does not mean that the network is unable to identify the sender or receiver. The IP header still contains network addresses, and the UDP header contains source and destination ports. It means that UDP does not negotiate a transport session before sending each datagram.

UDP Delivery and Reliability Behavior

UDP is often described as an unreliable transport. In this context, unreliable means that UDP does not guarantee successful arrival, correct ordering, or retransmission of lost data. It does not mean that every UDP datagram is normally damaged or lost.

• No delivery guarantee: A datagram may be lost before reaching the destination.
• No automatic retransmission: UDP does not resend a datagram when it is lost.
• No sequencing: UDP does not assign transport-level sequence numbers for the purpose of ordering application data.
• No automatic reordering: Datagrams that arrive out of order are presented without UDP correcting their order.
• No duplicate suppression: UDP itself does not provide a TCP-like mechanism for detecting and removing duplicate application data.
• Variable delay: A datagram may be delayed, and UDP does not decide whether a late datagram is still useful.

UDP does include a checksum. The checksum helps detect corruption in the UDP header and data. Detecting corruption is different from guaranteeing delivery: a valid checksum shows that received bits passed the integrity check, but it does not show that every datagram was delivered or that datagrams arrived in the original order.

If an application needs reliability, it can implement features above UDP. Application-layer logic may add acknowledgments, timeouts, sequence numbers, retransmission, duplicate detection, reordering, or recovery from missing data. This lets the application choose behavior appropriate to its data rather than automatically applying the same recovery policy to every datagram.

Resource and Performance Characteristics

UDP generally has less protocol overhead than TCP for several related reasons:

• Its header is a fixed 8 bytes.
• It does not require connection establishment.
• It does not maintain transport-level acknowledgment and retransmission state.
• It does not provide a transport-level ordered byte stream.

Less overhead can reduce processing, memory use, and setup delay on hosts. It can also make UDP suitable for applications that send small, independent messages or need to transmit data without waiting for a connection handshake.

The efficiency is a trade-off, not a guarantee of faster application performance in every situation. Applications must handle any reliability, ordering, congestion response, or timing behavior they require. A simple UDP design may be efficient, while a UDP application that recreates many TCP features can become more complex.

UDP Header Structure

Every UDP datagram begins with an 8-byte header. The header contains four fields, each 16 bits long, followed by the application payload.

Source Port

The source port identifies the sending application's endpoint. It gives the receiver a port to which a response can normally be directed when the application uses a return endpoint. Some UDP exchanges can use a source port selected dynamically by the operating system.

Destination Port

The destination port identifies the receiving service or application endpoint. When a host receives a UDP datagram, its operating system uses the destination port, along with other packet information, to deliver the datagram to the appropriate socket or listening service.

Length

The UDP length field represents the combined size of the UDP header and payload. It does not represent only the application data.

The relationship is:

UDP length = UDP header length + UDP payload length

For example, the fixed header is 8 bytes. If the application payload is 120 bytes, the UDP length field represents 128 bytes:

8 bytes of header + 120 bytes of payload = 128 bytes

Checksum

The checksum is used to detect corruption in the UDP header and payload while the datagram is being transferred. If the integrity check fails, the receiving protocol stack can discard the damaged datagram rather than pass known-corrupt data to the application.

A checksum cannot repair damaged data and cannot recover a missing datagram. It is an integrity check, not a reliability protocol.

Ports and Application Multiplexing

A host may run many network applications at the same time. Port numbers allow the transport layer to distinguish these application endpoints. This process is called multiplexing when data from multiple applications is combined for transmission, and demultiplexing when received data is delivered to the correct application.

For example, a host might receive UDP datagrams for several destination ports. The operating system examines each destination port and passes the datagram to the matching local service or socket. If no suitable service is bound to the port, the datagram may be rejected or handled according to the host's networking behavior.

The source and destination port fields are both 16 bits. UDP and TCP use separate transport protocols and maintain separate transport endpoint spaces, even though both use port numbers to identify applications. Learn more in TCP and UDP ports.

Why Applications Choose UDP

UDP is a suitable choice when an application values simplicity or timely delivery and can tolerate some loss, or when it is prepared to implement recovery above the transport layer.

Real-Time Voice Traffic

VoIP, or Voice over IP, is a common example of traffic that can favor timely delivery. If one voice datagram is lost, the result may be a brief audio gap. Resending that datagram may cause it to arrive after the moment when the audio should have been played.

For time-sensitive media, an on-time stream with an occasional small gap can be more useful than a complete stream that pauses while waiting for old data. Voice applications can use techniques such as jitter handling, loss concealment, and adaptive media behavior above UDP.

Network File System

NFS, or Network File System, demonstrates that an application can use UDP while still implementing recovery mechanisms. An NFS client can detect a missing response, wait for a timeout, and issue a retry according to its own protocol logic.

This does not turn UDP into TCP. It means that reliability is being provided by the application layer, where the application can define appropriate timeouts, request identifiers, retries, and response handling.

UDP Compared with TCP

TCP, or Transmission Control Protocol, is connection-oriented. It establishes a connection before transferring application data and provides reliable, ordered byte-stream delivery through mechanisms such as acknowledgments and retransmission.

Choose UDP when low delay, independent messages, and application-managed behavior are more important than automatic delivery and ordering. Choose TCP when the application needs a reliable, ordered stream and does not want to implement those transport features itself.

For a deeper comparison, read Transmission Control Protocol (TCP).

Common UDP Troubleshooting Situations

Missing Datagrams Are Not Resent

Symptom: An application expects a dropped datagram to arrive later, but it never does.

Explanation: UDP does not provide TCP-style acknowledgments or retransmissions.

Resolution: Add application-level acknowledgments, timeouts, retries, or another recovery method if the data must be delivered.

Datagrams Arrive Out of Order

Symptom: The application receives data in an unexpected sequence.

Explanation: UDP does not reorder datagrams before presenting them to the application.

Resolution: Include sequence information in the application protocol. The application can reorder, discard, or tolerate late datagrams according to its requirements.

A Real-Time Stream Has Gaps

Symptom: Audio or another time-sensitive stream contains brief missing segments.

Explanation: Individual UDP datagrams can be lost, and late retransmission may be less useful than continuing playback.

Resolution: Use application-level jitter handling, loss concealment, or adaptive media techniques rather than expecting UDP to retransmit data.

The Expected Service Does Not Receive a Datagram

Symptom: A UDP datagram appears to be sent, but the intended application does not receive it.

Explanation: UDP demultiplexing depends on the destination port and a matching local service.

Resolution: Verify that the sender targets the intended destination port and that the receiving application is bound to that port. In Nmap, UDP service checks can be explored with the UDP scan topic.

Key Points

• UDP is a transport-layer protocol commonly mapped to OSI Layer 4.
• It carries application data in independent datagrams.
• UDP is connectionless and does not establish a virtual circuit before sending.
• Its 8-byte header contains source port, destination port, length, and checksum fields.
• The length field includes both the UDP header and payload.
• The checksum detects corruption but does not guarantee delivery.
• UDP does not automatically retransmit, reorder, or remove duplicate datagrams.
• Applications can add their own acknowledgments, sequencing, retries, and recovery.
• VoIP may prefer timely delivery over retransmission of late voice data.
• NFS illustrates application-level recovery above UDP.
• TCP provides connection management, reliable delivery, and ordering, but with greater protocol overhead.