UDP Header Format
Understanding length, source/destination ports, checksum, and pseudo-header usage.
Introduction: The Simple Postcard-s Label
If a TCP segment is like a registered package with a detailed, multi-page shipping manifest, then a UDP datagram is the equivalent of a simple postcard. The TCP header is that long manifest, filled with tracking numbers, acknowledgments, and flow control information. In stark contrast, the UDP header is the small, minimalist label you stick on a postcard.
The UDP header is a perfect reflection of the protocol-s design philosophy: do the absolute minimum required to get a message from an application on one computer to an application on another. It contains no fields for sequencing, acknowledgments, or windowing. Its purpose is stripped down to the bare essentials of transport-layer communication.
This simplicity is not a weakness; it is a feature. The small, fixed-size header means there is very little overhead. Less data needs to be processed by both the sender and receiver, and less bandwidth is consumed by control information, which translates directly to higher speed and lower latency. Every single field in the UDP header has a clear, essential purpose for addressing and basic error checking. Let us explore the elegant simplicity of its four components.
The Overall Structure of the UDP Header
The UDP header is remarkably small and consistent. It is always 8 bytes (64 bits) in length. This fixed size simplifies processing, as devices do not need to parse a variable-length header as they do with TCP. The header is composed of four fields, each taking up 2 bytes (16 bits).
The entire package sent by UDP is called a UDP datagram. It consists of two parts: the lean 8-byte UDP header followed by the application data, or .
Detailed Breakdown of the UDP Header Fields
Let us analyze each of the four fields and its critical role in the UDP protocol.
1. Source Port (16 bits)
Purpose: The Source Port field identifies the port number of the sending application on the source host. Its main function is to tell the receiving machine where to send any potential replies.
Usage: For a client-server interaction like a DNS query, this field is essential. The DNS client sends a query from an ephemeral source port. When the DNS server receives the query, it looks at the Source Port field to learn the correct port number to use as the Destination Port in its reply datagram. Without it, the reply would have nowhere to go.
Optional Nature: In the UDP specification, this field is technically optional. An application that does not expect a reply can set this field to zero. However, in modern practice, this is very rare. Most network firewalls and Network Address Translation (NAT) devices rely on the source port to track communication sessions, and a datagram with a zeroed source port is likely to be dropped.
2. Destination Port (16 bits)
Purpose: This is a mandatory field that specifies the port number of the application on the destination host for which the data is intended. This is the "apartment number" in our postcard analogy.
Usage: This field is the key to the demultiplexing process. When a UDP datagram arrives at a host, the operating system-s transport layer inspects this 16-bit number. It uses this number to find the corresponding application socket that is listening on that port and delivers the payload to it. For example, a DNS query would be sent to the destination port on a DNS server.
3. Length (16 bits)
Purpose: This field specifies the total length of the entire UDP datagram in bytes. This includes the 8-byte header and the variable-length data payload.
Values: The minimum value for this field is 8, which corresponds to a UDP datagram that has a header but no data payload. While a datagram with no data seems useless, it can sometimes be used as a simple form of keep-alive or heartbeat packet by an application. Since the field is 16 bits long, the theoretical maximum size of a UDP datagram is bytes. However, this is further limited by the maximum size of the underlying IP packet. In reality, large datagrams are often avoided as they are more likely to be fragmented at the IP layer, which increases the probability of loss.
Deep Dive: The UDP Checksum and the Pseudo-Header
The Checksum field (16 bits) is the only form of integrity protection offered by UDP. While simple, its implementation includes a clever mechanism to protect against more than just random bit flips.
The Purpose of the Checksum
The UDP checksum is an error-detecting code, not an error-correcting one. Its goal is to allow the receiver to determine if the datagram was corrupted during transit. If the receiver calculates a checksum that does not match the value in the header, it silently discards the datagram. No error message is sent back to the sender; the data is simply dropped.
The calculation uses the same arithmetic as the TCP/IP checksum.
The Critical Role of the Pseudo-Header
The checksum calculation does not just cover the UDP header and its payload. To add an extra layer of protection, the calculation also includes a conceptual data structure known as the UDP Pseudo-Header. This pseudo-header is not part of the actual UDP datagram and is not transmitted over the network; it is constructed temporarily by both the sender (for calculation) and the receiver (for verification).
The pseudo-header for IPv4 consists of:
- Source IP Address (32 bits)
- Destination IP Address (32 bits)
- A field of all zeros (8 bits)
- The Protocol Number (8 bits - its value is 17 for UDP)
- The UDP Length (16 bits - copied from the UDP header)
Why is this important? By including the source and destination IP addresses in the checksum calculation, UDP protects against misdelivery. Imagine a router malfunction causes an IP packet to be delivered to the wrong computer. If the checksum were calculated only on the UDP header and data, the incorrect recipient might find the checksum to be valid and mistakenly pass corrupted data to one of its applications. Since the wrong host will have a different IP address, its checksum calculation (which includes the IP addresses from the pseudo-header) will fail, and it will correctly discard the misdelivered datagram. For IPv6, the pseudo-header is similar but uses the 128-bit IPv6 addresses.
Optional vs. Mandatory Usage
An important distinction exists in how the checksum is used between IPv4 and IPv6:
- In IPv4, the UDP checksum is optional. A sender can choose not to calculate a checksum by setting this field to all zeros. This was historically done to save a few processor cycles on slow devices, with the assumption that the link layer (e.g., Ethernet with its CRC) would catch most errors anyway.
- In IPv6, the UDP checksum is mandatory. This policy was changed because experience showed that data corruption can happen at any layer, including within routers where link-layer checks do not apply. Forcing its use provides essential end-to-end data integrity.
UDP vs. TCP Header: A Final Comparison
The contrast between the UDP and TCP headers encapsulates the core philosophies of the two protocols.
| Feature | UDP Header (8 bytes) | TCP Header (20-60 bytes) |
|---|---|---|
| Addressing | Source & Destination Ports | Source & Destination Ports |
| Data Ordering | No mechanism (No Sequence Number field) | Yes (32-bit Sequence Number field) |
| Reliability | No mechanism (No Acknowledgment Number) | Yes (32-bit Acknowledgment Number field, ACK flag) |
| Connection State | None (No SYN, FIN, RST flags) | Full state management (SYN, FIN, RST flags) |
| Flow Control | None (No Window Size field) | Yes (16-bit Window Size field) |
| Error Detection | Optional (in IPv4) 16-bit Checksum | Mandatory 16-bit Checksum |
| Extensibility | None (fixed header) | Yes (variable-length Options field) |
Ultimately, the UDP header provides just enough information to get a self-contained datagram to the correct application and to perform a basic check for corruption. All other complexities are intentionally left to the application, making UDP a simple, fast, and highly flexible foundation for specific types of network communication.