UDP (User Datagram Protocol)

Table of Contents
1. Introduction
2. Features of UDP protocol
3. Why UDP is required
4. UDP Header Format
5. Checksum and Error Detection
6. Ports and Port Ranges
7. Applications of UDP
8. Comparison with TCP
9. Multiplexing and Demultiplexing (Sockets, Control Blocks)
View more

Introduction

UDP stands for User Datagram Protocol. It was developed by David P. Reed in 1980 and is specified in RFC 768. UDP is a transport-layer protocol in the Internet protocol suite (commonly referred to as TCP/IP). It enables applications on different hosts to exchange messages in the form of datagrams over an IP network.

UDP is an alternative to the Transmission Control Protocol (TCP). Both UDP and TCP carry data over IP, but they differ in the services they provide. UDP is a simple, connectionless, best-effort transport protocol that provides process-to-process communication using port numbers. It does not set up a virtual connection before sending data. TCP, in contrast, is connection-oriented and provides reliable, ordered delivery, flow control and congestion control.

Features of UDP protocol

The following are the main features of UDP:

• Transport-layer protocol: UDP is a transport-layer protocol with minimal mechanisms. It is classed as an unreliable, best-effort delivery service because it provides no built-in acknowledgements, retransmission, or flow control.
• Connectionless: UDP does not establish a connection (no handshaking). Each datagram is sent independently and may follow different paths to the destination.
• No guaranteed ordering: Datagram delivery order is not guaranteed; packets can arrive out of order or be lost, duplicated, or delayed.
• Ports and process-to-process communication: UDP uses 16-bit source and destination port numbers to identify application services on hosts. Port numbers range from 0 to 65535. The well-known port range is 0-1023; dynamic (ephemeral) ports are typically assigned from higher ranges.
• Low overhead and faster transmission: Due to its small header and the absence of connection management, UDP has lower overhead and can be faster for latency-sensitive applications.
• No acknowledgement or flow control: There is no built-in acknowledgement or flow control mechanism in UDP; applications must implement any required reliability or ordering themselves.
• Independent datagrams: Each UDP datagram is processed independently; the protocol and network do not tie datagrams together into a stream.
• Stateless: UDP is stateless at the transport level-the protocol itself does not maintain per-connection state.
• Supports broadcast and multicast: UDP can be used with IP broadcast and multicast addresses, making it suitable for group communication.

Why UDP is required

Although UDP is an unreliable protocol, it remains essential in many scenarios where low latency, low overhead, or support for broadcast/multicast is more important than guaranteed delivery. Typical reasons to use UDP include:

• Low latency requirements: Real-time applications such as voice over IP (VoIP), video conferencing, and interactive online gaming prefer UDP because retransmission delays would harm user experience.
• High packet rate or many small messages: Services like Domain Name System (DNS) and DHCP exchange many short messages where the overhead of connection setup and teardown would be wasteful.
• Application-level reliability: Some applications implement their own lightweight reliability, retransmission, or error concealment mechanisms tailored to the application's needs.
• Multicast/broadcast communication: Streaming or service discovery often uses multicast/broadcast, which UDP supports directly.
• Simple request/response: Protocols such as Trivial File Transfer Protocol (TFTP) or certain discovery protocols use a simple request/response model that maps well to UDP.

UDP Header Format

The UDP header is 8 bytes (64 bits) long. The UDP length field is a 16-bit value that gives the length of the UDP header plus UDP data (the UDP datagram). The UDP length field and the IP total-length field are both 16-bit values, so the maximum size of an IP datagram is 65,535 bytes (including the IP header). For IPv4 with no IP options (IP header length 20 bytes):

• Maximum UDP datagram (header + data): 65,535 - 20 = 65,515 bytes.
• Maximum UDP data (payload): 65,515 - 8 = 65,507 bytes.

The UDP header contains four fields (each 16 bits) in this order:

• Source port number: Identifies the sending application process on the source host. This is optional in some cases (source port 0 indicates no port).
• Destination port number: Identifies the receiving application process on the destination host; it enables process-to-process delivery.
• Length: The length of the UDP header and data in bytes (minimum value 8, the header size).
• Checksum: A 16-bit checksum for error detection calculated over a pseudo-header (derived from the IP header), the UDP header, and the UDP data. In IPv4 the UDP checksum is optional (a value of zero indicates no checksum). In IPv6 the UDP checksum is mandatory.

Checksum and Error Detection

The UDP checksum helps detect accidental corruption of the header and data. The checksum covers:

• IP pseudo-header: Source IP address, destination IP address, protocol number, and UDP length (these fields are used to protect against misdelivery between hosts).
• UDP header: All 8 bytes of the UDP header with the checksum field set to zero during computation.
• UDP data (payload): The entire UDP payload; if the payload length is odd, padding is used for checksum calculation only.

Calculation steps (conceptual):

• Form the pseudo-header from fields in the IP header.
• Concatenate the pseudo-header, UDP header (with checksum set to zero), and UDP data.
• Compute the 16-bit one's-complement sum of the concatenated block and take the one's-complement of the result to obtain the checksum.

Note: Because the checksum is optional in IPv4, some applications may choose not to compute it, but doing so improves detection of corrupted datagrams. IPv6 requires the checksum, improving reliability of error detection at the transport layer.

Ports and Port Ranges

Port numbers are 16 bits and thus range from 0 to 65535. Common ranges are:

• Well-known ports: 0-1023 (reserved for system or well-known services).
• Registered ports: 1024-49151 (assigned for particular services by IANA).
• Dynamic/ephemeral ports: 49152-65535 (commonly used for temporary client ports).

Applications of UDP

UDP is widely used where low overhead or low latency is more important than guaranteed delivery. Typical applications include:

• DNS (Domain Name System): Most DNS queries use UDP (port 53) for speed; TCP is used for zone transfers or large responses.
• DHCP (Dynamic Host Configuration Protocol): Uses UDP ports 67 (server) and 68 (client).
• RTP (Real-time Transport Protocol) / VoIP: Carried over UDP to meet strict timing requirements.
• Streaming media and live video: UDP reduces latency and avoids retransmission delays.
• TFTP (Trivial File Transfer Protocol): Uses UDP (port 69) for simple file transfers.
• SNMP (Simple Network Management Protocol): Typically uses UDP for lightweight management messages.
• Online gaming and real-time interactive applications: Prefer UDP for responsiveness.

Comparison with TCP

• Connection model: UDP is connectionless; TCP is connection-oriented (three-way handshake).
• Reliability: UDP offers best-effort delivery with no retransmission; TCP provides reliable delivery with acknowledgements and retransmission.
• Ordering: UDP does not guarantee ordering; TCP preserves byte order.
• Flow and congestion control: UDP has no flow/congestion control; TCP implements both to be network-friendly.
• Overhead: UDP has lower header and protocol overhead; TCP has higher overhead for reliability and control.
• Use cases: UDP is preferred for low-latency or multicast applications; TCP is preferred for reliable data transfer (files, web pages, email).

Multiplexing and Demultiplexing (Sockets, Control Blocks)

UDP provides process-to-process communication by mapping datagrams to sockets identified by IP address and port number pairs. Typical kernel components involved in UDP receive/send processing include:

• Input queue: Each UDP socket (process) may have an input queue where arriving datagrams for that socket are enqueued until the application reads them.
• Input module: The kernel receives IP datagrams, identifies UDP payloads, locates the matching socket entry (control block) by destination port (and optional IP/port tuple), and enqueues the datagram to the socket's input queue.
• Control block module and control block table: The kernel maintains a table of open UDP control blocks (socket descriptors) that record the local port, remote address/port (if bound to a peer), and socket state. The input module consults this table to demultiplex incoming datagrams.
• Output module: When an application sends a UDP datagram, the output module forms the UDP header, optionally computes the checksum, hands the UDP datagram to IP for encapsulation, and transmits it.

Multiple processes can use UDP on the same host through proper use of ports; the kernel's demultiplexing logic ensures datagrams reach the correct socket. If no matching socket exists for a received datagram, it is typically discarded and, for certain protocols, an ICMP "port unreachable" may be generated.

Limitations

• No guaranteed delivery: Datagrams may be lost, duplicated, delayed, or delivered out of order.
• No congestion control: UDP does not respond to network congestion; applications must implement responsible rate control when needed.
• No built-in reliability: UDP does not provide acknowledgements, retransmission, or flow control-applications must handle these if required.
• Security: As with other protocols, UDP is susceptible to spoofing and amplification attacks (for example, reflected DDoS attacks) if not properly protected.

Advantages

• Minimal overhead: Small header (8 bytes) and no connection management reduce protocol overhead.
• Low latency: Ideal for time-sensitive or real-time applications where retransmission delays are undesirable.
• Simplicity: Simple protocol design makes implementation and debugging easier for certain application classes.
• Supports multicast and broadcast: Useful for group communication and service discovery.

Summary

UDP is a lightweight, connectionless transport protocol defined in RFC 768 and designed for cases where simplicity, low overhead, and low latency are more important than guaranteed delivery. It uses 8-byte headers, 16-bit port numbers, and an optional checksum in IPv4 (mandatory in IPv6). UDP is widely used for DNS, DHCP, VoIP/RTP, streaming, gaming, and other applications that either tolerate some packet loss or implement application-level recovery. Because it provides only basic process-to-process delivery, application designers must choose UDP when its characteristics match the requirements and must add reliability or congestion control at the application layer if needed.