UDP header purpose
A TCP segment carries fields for sequence numbers, acknowledgments, flags, flow control, and options. A UDP datagram carries a fixed base header with two ports, a length, and a checksum. The UDP header supplies the information needed to deliver one application message to a destination port.
UDP provides a minimal message transport. Its base header has no sequence number, acknowledgment number, or receive window, so the protocol does not provide ordered delivery, retransmission, or flow control. An application or a protocol layered above UDP can add those functions when it needs them.
The base header is 8 bytes, so each datagram carries little transport control information. That reduces header processing and bandwidth compared with a transport that includes connection state, but it does not guarantee a faster path or lower queueing delay. The four fields cover ports, length, and error detection.
UDP header structure
The base UDP header is always 8 bytes (64 bits) long. It contains four fields, each 2 bytes (16 bits) wide. Unlike TCP, UDP has no variable-length base header. A standardized UDP Options extension places optional transport options in a trailer area after the user data, while the base header remains 8 bytes.
The complete message sent by UDP is called a UDP datagram. Its base form consists of the 8-byte UDP header followed by application data, or .
The multi-octet fields use network byte order, with the most significant byte first. The Length field covers the base header and UDP user data, so the receiver can separate the datagram from the surrounding IP packet. With the standardized UDP Options extension, a shorter Length value marks the surplus area after user data, where options are carried.
UDP header fields
The four fields have distinct roles in UDP processing.
1. Source Port (16 bits)
Purpose: The Source Port field identifies the port of the sending process when that information is meaningful. A receiver can use it as the destination port for a reply, unless the application uses another reply mechanism.
Usage: In a client-server exchange such as a DNS query, the client usually selects an ephemeral source port. The server copies that value into the Destination Port of its reply, allowing the operating system to deliver the response to the requesting socket.
Optional nature: The UDP specification permits a sender that does not use a source port to transmit zero in this field. Applications that expect replies normally choose a source port so the receiver can identify the return endpoint. Middleboxes can apply their own policies to packets with unusual port values.
A UDP endpoint is commonly selected by combining a local address with a local port, and a connected socket can also record the remote address and port. This lets one host serve several peers while the destination port still selects the application service.
2. Destination Port (16 bits)
Purpose: This field identifies the destination port in the context of the destination address. The operating system uses it when it selects the receiving socket.
Usage: When a UDP datagram arrives, the transport layer combines the destination address and port with the local socket bindings to demultiplex the datagram. For example, a DNS query is normally sent to destination port on the 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 is 8, representing a header with no user data. An application can use such a datagram as a heartbeat, although the meaning comes from the application. The 16-bit field gives a theoretical maximum datagram length of bytes, including the header. The maximum UDP payload is 65,507 bytes for an IPv4 packet with a minimum header and 65,527 bytes for IPv6 without a jumbogram. Large datagrams can require IP fragmentation, which reduces efficiency and increases the effect of a lost fragment.
UDP checksum and pseudo-header
The Checksum field is 16 bits wide and provides error detection for the UDP header and data. The calculation also covers selected IP-layer values, which lets the receiver detect some misdelivery cases. It does not correct errors or provide confidentiality.
The Purpose of the Checksum
The UDP checksum is an error-detecting code. The receiver recomputes the one's-complement checksum and verifies the result. A failed check causes the datagram to be discarded by the receiving implementation; UDP does not define a retransmission or an error response to the sender.
The calculation uses the same arithmetic as the TCP/IP checksum.
The role of the pseudo-header
The checksum covers the UDP header and its payload, together with a conceptual UDP pseudo-header. The pseudo-header is not transmitted as part of the UDP datagram. The sender builds it for calculation, and the receiver reconstructs it for verification.
The IPv4 pseudo-header contains:
- Source IP Address (32 bits)
- Destination IP Address (32 bits)
- An 8-bit field set to zero
- The 8-bit IP protocol number, which is 17 for UDP
- The 16-bit UDP length copied from the UDP header
Purpose: When a checksum is present, including the source and destination addresses binds it to the IP endpoints in the packet. If an intermediary or damaged IP header changes an endpoint address, the receiver reconstructs a different pseudo-header and can discard the datagram. IPv6 uses 128-bit addresses and a pseudo-header containing the source and destination addresses, the upper-layer length, and the next-header value.
The calculation adds 16-bit words with end-around carry and then complements the sum. If the calculated result is zero, the transmitted checksum uses all ones. In IPv4, a transmitted zero means that the sender omitted the checksum. These details matter when a packet capture is compared with an implementation or when a receiver validates a fragment after reassembly.
Checksum requirements by IP version
IPv4 and IPv6 have different checksum requirements:
- IPv4: A sender may omit the UDP checksum by transmitting this field as zero. A nonzero value enables the end-to-end check; a link-layer check does not replace it across multiple links.
- IPv6: Ordinary UDP over IPv6 requires a nonzero checksum. Specific standards define limited exceptions for controlled tunnel deployments, so the general rule should not be read as a universal rule for every encapsulation.
UDP and TCP header comparison
The field sets expose the different services supplied by the two transports.
| 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 | 8-byte base header; UDP Options use a defined trailer extension | Yes (variable-length Options field) |
The UDP base header provides ports, length, and a checksum for one datagram. Delivery, ordering, retransmission, flow control, and congestion control come from the application or a protocol layered above UDP. A standardized UDP Options extension adds a trailer area for optional transport options without changing the 8-byte base header.