Why is the UDP header only 8 bytes long?

The two transport protocols, UDP and TCP, are core members of the IP protocol cluster. The RFC 768, published in 1980, defines the UDP protocol, which allows us to pass data across a network of multiple computer connections. The common DNS protocol can use the UDP protocol to obtain the results of domain name resolution

UDP is the simplest protocol that can transmit data, and its protocol header (also called protocol header) is only 8 bytes. Many people, especially fresh graduates, can temporarily memorize the contents of the UDP protocol header by rote, but knowing the contents of the header does not mean we really understand the reason behind it. This article will analyze why only 8 bytes of the UDP protocol can transmit data, and I believe this article will help you better understand the role of the fields in the UDP protocol header.

The UDP protocol header contains only 4 fields, source port, destination port, length, and checksum, each of which occupies 16 bits, or 2 bytes, and these 4 fields serve the following purposes.

• Source port is an optional field that indicates the port number of the sender’s process, which the receiver can use (not necessarily exactly) to send information to the sender.
• Destination Port is the port number of the recipient of the datagram, which is meaningful only under the IP address of the destination.
• Length is the sum of the protocol header and the length of the data in the datagram, indicating the size of the entire datagram.
• Checksum is calculated using the IP header, the UDP header and the data in the datagram. The receiver can verify the accuracy of the data through the checksum and find problems in the transmission process.

Packet capture by Wireshark to see the value of the UDP protocol initials in actual use. When we execute the dig baidu.com command, a DNS query is sent locally to the DNS server, and the following is an example of the UDP initials in a DNS query.

1

0000 ff 7c 00 35 00 23 c2 6e

The values of the four fields in the UDP prefix above correspond to the following.

Since the DNS protocol uses port 534, the destination port in the UDP prefix above is 53. The source port is the port on which the DNS request is made locally and which is also used to receive the DNS response.

The RFC 768 document defining the UDP protocol is only three pages long, and since the UDP protocol requires neither guaranteed delivery nor guaranteed order, it is not as complex as the TCP protocol. Mechanisms such as the three handshakes5 , congestion control algorithms, and retransmission policies in the TCP protocol are all necessary to provide reliability, but the UDP protocol does not require these policies; it only tries to ensure that datagrams are delivered.

Today we will analyze why the UDP protocol, with a first 8 bytes, is able to transmit data to its destination and have it received and processed by a specific service. We can divide the application-to-application transfer process into two parts: host-to-host data transfer and host-to-application data forwarding.

• The Internet Protocol (IP) underlying the UDP protocol will be responsible for the transmission of packets between hosts.
• The port number at the beginning of the UDP protocol is used to locate the specific process that handles the data and forwards it.

We all say that UDP protocol is a transport layer protocol, but it is the IP protocol that really does the work of ‘data transfer’ between hosts, and UDP protocol only serves to locate the specific process.

Data Transfer

RFC768 introduces the UDP protocol by emphasizing that the UDP protocol assumes that the underlying layer will use the IP protocol, which is a core member of the TCP/IP stack and does not guarantee end-to-end data reliability or order, nor does it contain mechanisms such as flow control, whose role is to transfer packets from source to destination. In this article, we only need to know that the IP protocol header contains the source IP and the destination IP, so we will not go into the specific implementation of the IP protocol. Interested readers can read RFC791 and related documents for more details.

The phrase “the UDP protocol can only try to deliver data” is “inherited” from the lower layer of UDP, the IP protocol. The UDP protocol, which contains only two port numbers, cannot provide routing and addressing functions by itself; it still needs a lower layer protocol to solve this problem.

The above-mentioned design of each of these layers stems from the hierarchical structure of network communication protocols. Abstraction is a fundamental concept in computer science, and by defining good interfaces and building abstraction layers, we can reduce the number of simultaneous concerns and allow each layer to focus on the problem that needs to be addressed. the TCP/IP protocol cluster divides the communication process into four abstraction layers: Link, Internet, Transport and the application layer (Application)

Different abstraction layers have completely different functions, so let’s look at the responsibilities of the network layer and the transport layer. the main role of transport layer protocols such as TCP and UDP is to establish the basic data pipeline for applications and provide data transfer capabilities for specific tasks, while the main role of network layer protocols such as IP is addressing and routing, which helps us send data to the target host.

To briefly summarize, the IP protocol under the UDP protocol implements the transmission of data packets, and although UDP is a transport layer protocol, it does not provide host-to-host data transfer capability on its own.

Process location

At the software level, a port is a logical concept used to represent a specific process or a specific type of network service. The concept of a port is also found in computer hardware, but the port in this case is not physical. When a host receives an IP packet, it is given to a different module for processing based on the protocol number, and the TCP and UDP protocols determine the corresponding process based on the port number.

Although both TCP and UDP protocols have the concept of port numbers, because they are not under the same namespace (TCP and UDP are two sets of namespaces), TCP and UDP can both use the same port number, e.g., 53/TCP and 53/UDP, and the services behind these two port numbers both handle DNS requests. From this point of view, the only way to locate a specific service on the network is by IP address, transport layer protocol, and port number; it is not feasible to rely on IP address and port number alone.

The two port numbers in the UDP protocol account for half of the overhead of the UDP protocol header, which illustrates the importance of port numbers in the UDP protocol and the primary function of the UDP protocol. The host receiving the IP packet can use the destination port number to find a specific process, and that process can use the source port number in the packet to reply to the sender.

TCP and UDP port numbers are an intermediate layer between the host and the process. Processes and port numbers can have either a one-to-one or a one-to-many relationship, and the introduction of port numbers allows multiple processes on the same host to provide services externally, or one process to provide multiple services externally. With port numbers, requests to access a host service also do not require the use of process identifiers, for example, to locate the specific process providing the service.

Summary

To briefly answer the question posed in this article: the UDP protocol uses the underlying IP protocol to provide basic data transfer capabilities, and its role is to introduce the concept of port numbers to allow the same host to provide multiple external services at the same time, with the protocol itself taking up only 8 bytes since reliability is not guaranteed.

Ideally, we could build a new transport layer protocol on top of the IP protocol to achieve specific needs, but in practice, due to the protocol number limitation, the new transport layer protocol cannot be recognized and supported by a large number of deployed Network address translation (NAT) devices, so building a new transport layer protocol in this way is difficult to implement in practice.

The protocol number is a field in the IP header that indicates the protocol used for the current message data area; the most common protocol numbers for TCP and UDP protocols are 6 and 17, respectively.

The SCTP protocol is a transport layer protocol in the RFC standard, but compatibility issues with NAT devices can cause SCTP messages to be discarded

Because the UDP protocol is so simple, many new transport layer protocols will be implemented based on UDP, e.g., Google’s QUIC protocol. Finally, let’s look at some of the more open-ended questions that interested readers can ponder.

• Can the length and checksum be omitted from the UDP protocol? Why?
• Do other IP-based transport layer protocols besides UDP and TCP have the concept of port numbers?