UDP sends independent datagrams with only a source port, a destination port, a length and a checksum, so it adds an 8-byte header, sets up no connection and never resends a lost packet. It suits short request-and-reply exchanges such as name lookup, broadcasts that TCP cannot do, and real-time audio where a late packet is worthless, and it leaves any reliability to the program. On a link with a 1,500-byte limit a UDP datagram carries at most 1,472 bytes of data, against 1,460 for TCP.
Part of Networking
The connectionless transport protocol: what it provides, where a settlement uses it, how to add the reliability it lacks, and how large a datagram may be.
UDP Is IP With Port Numbers And A Checksum
Protocols states what UDP is: port numbers to pick the receiving program, and a checksum, with no connection setup, no acknowledgment, no retransmission and no ordering. It names DNS queries and real-time voice and video as the standard uses. This article is about using it well.
The header has four fields of 16 bits each. The ports are 16-bit (Network Addressing) and the checksum is named in the article above; the length field is from general knowledge. Four fields of 16 bits is 64 bits, which is 8 bytes. TCP’s header is at least 20 bytes (general knowledge, as in TCP Protocol), so UDP saves 12 bytes on every packet and, more usefully, saves the exchange of packets needed to open and close a connection.
Two jobs only UDP can do: send to a broadcast or multicast address, since Network Addressing shows broadcasts are how address discovery works and a TCP connection needs exactly two ends; and send something where a late answer is worse than no answer.
What You Need
- A reason — if the program needs every byte, in order, use TCP and do not rebuild it
- A port number — Network Addressing explains that ports 1024 to 49151 are registered ranges for applications and the well-known range below that is reserved; choose one and write it in the plan
- A firewall rule for it (Firewalls)
Method: Use UDP Safely
Step 1: Keep every datagram within one packet Fragmentation is expensive and a lost fragment loses the whole datagram (Packet Structure). On a link with a 1,500-byte limit that means 1,500 - 20 - 8 = 1,472 bytes of data at most, using the 20-byte IPv4 header and the 8-byte UDP header.
Step 2: Number your messages A receiver cannot otherwise tell a new message from a duplicate, or notice a gap.
Step 3: Add acknowledgments and timeouts only if the data needs them Acknowledgments describes stop-and-wait, which needs a 1-bit sequence number, and sliding windows. For a sensor reading sent every minute, losing one is harmless and you need none of this.
Step 4: Handle the reply that never comes DNS clients simply send the query again if no answer arrives (Protocols); do the same.
Step 5: Allow the replies through the firewall UDP has no connection, so a firewall can only recognise a reply as belonging to a recent request (general knowledge); see Firewalls.
Worked Example: One Lookup, Two Ways
A name lookup is one question and one answer. Over UDP: 2 packets (query, reply). Over TCP: the three-way handshake alone is 3 packets (Protocols) before the question, then the question and the answer, and the connection must also be closed. That is at least 3 + 2 = 5 packets before closing, against 2. Maximum data per packet at a 1,500-byte limit: UDP 1,500 - 20 - 8 = 1,472; TCP 1,500 - 20 - 20 = 1,460. The difference is 1,472 - 1,460 = 12 bytes, which is 12 / 1,472 = 0.8% of a full datagram, small beside the cost of the handshake for a short exchange.
Common Mistakes
- Assuming delivery — a datagram that is dropped is simply gone, and nobody tells the sender
- Sending large datagrams — they fragment, and one lost fragment loses the lot
- Rebuilding TCP on top of UDP for bulk data — you will reproduce its mechanisms badly; use TCP
- Forgetting the firewall — UDP services fail silently when the filter drops the replies