Learning Notes on TCP/IP (6) – UDP Protocol

Brief Introduction to UDP

UDP is a transport layer protocol, sitting in the same layer as the TCP protocol. However, unlike TCP, UDP does not provide features such as timeout retransmission or error retransmission, meaning it is an unreliable protocol.

UDP Protocol Header

UDP Port Number

Many applications require the use of UDP, so it must differentiate between different programs’ data packets using some identifier. The port number serves this purpose. For example, if a UDP program A registers port 3000 in the system, then any incoming UDP packets with a destination port number of 3000 will be delivered to that program. Theoretically, there can be 2^16 such port numbers because its length is 16 bits.

UDP Checksum

This is an optional feature, and not all systems apply checksums to UDP packets (unlike TCP, which requires them). However, the standards in the RFC state that the sender should calculate the checksum.

The UDP checksum covers the UDP protocol header and data, which is different from the IP checksum, which only covers the IP header and not all data. Both UDP and TCP include a pseudo-header, which is used to calculate the checksum. The pseudo-header even contains information like the IP address, which is included in the IP protocol, to allow UDP to check twice whether the data has correctly reached its destination. If the sender does not enable the checksum option, and the receiver computes a checksum error, the UDP data will be silently discarded (no delivery guarantee) without generating any error messages.

UDP Length

UDP can be very long, up to 65535 bytes. However, in practice, networks typically cannot transmit such long packets at once (due to MTU issues), necessitating data fragmentation. This fragmentation is transparent to upper-level protocols like UDP, which does not need to be concerned about how the IP layer fragments the data. The next chapter will briefly discuss some fragmentation strategies.

IP Fragmentation

When IP receives data from the upper layer, it determines which interface to send the data from based on the IP address (through routing) and queries the MTU. If the data size exceeds the MTU, it will fragment the data. Fragmentation is transparent to both upper and lower layers, and the data will be reassembled upon reaching the destination. However, there’s no need to worry, as the IP layer provides sufficient information for data reassembly.

In the IP header, a 16-bit identification number uniquely records the ID of an IP packet. IP fragments with the same ID will be reassembled; a 13-bit fragment offset records the position of a fragment relative to the entire packet; and a 3-bit flag indicates whether there are more fragments following. These three indicators constitute all the information for IP fragmentation, allowing the receiver to reorganize the IP data (even if later fragments arrive before earlier ones, this information is sufficient).

Because fragmentation techniques are frequently used in networks, software and individuals that fabricate IP fragment packets for malicious attacks have emerged.

The Tracert program can be used for simple MTU detection.

Interactive Applications Between UDP and ARP

This is a detail that is often overlooked, particularly in the implementation of some systems. When the ARP cache is still empty, UDP must send an ARP request to obtain the MAC address of the destination host before sending the UDP packet. If this UDP packet is large enough that the IP layer must fragment it, imagine that the first fragment of this UDP packet will issue an ARP query. All fragments will wait for this query to complete before sending. Is this actually the case?

The result is that some systems will send an ARP query for each fragment, all fragments waiting, but upon receiving the first response, the host only sends the last data fragment and discards the others. This is quite perplexing. As a result, because the fragmented data cannot be assembled in time, the receiving host will eventually discard the IP packet that cannot be assembled and send an ICMP message indicating assembly timeout (in fact, many systems do not generate this error) to ensure that the receiving host’s buffer is not filled with fragments that can never be assembled.

ICMP Source Rate Limiting Errors

When the processing speed of the target host cannot keep up with the incoming data, and the IP layer cache of the receiving host is filled, the host will issue an ICMP message indicating “I can’t handle this.””>

UDP Server Design

Some characteristics of the UDP protocol will affect our server program design, summarized as follows:

1. Regarding client IP and address: The server must have the ability to determine the validity of a packet based on the client’s IP address and port number (this seems to be a requirement for every server).

2. Regarding destination address: The server must have the ability to filter broadcast addresses.

3. Regarding data input: Typically, each port number in the server system corresponds to an input buffer. Incoming data waits for server processing based on a first-come-first-served principle, which inevitably leads to buffer overflow issues. In such cases, UDP packets may be discarded, and the application server program itself may not be aware of this issue.

4. The server should restrict local IP addresses, meaning it should be able to bind itself to a specific port on a specific network interface.