UDP does almost nothing. It adds port numbers and an error check to what the network layer already gives you, and for a surprising number of applications that is exactly the right amount.
Words you will meet
- UDP — User Datagram Protocol: the Internet’s bare transport protocol.
- Connectionless — no handshake; the first segment carries data.
- Internet checksum — a small number sent with a segment so the receiver can tell whether the bits changed.
- Ones-complement sum — adding binary numbers, then adding any carry from the top back in at the bottom.
- End-end principle — a job that only the two ends can finish properly should be done by the two ends.
Why this matters
Suppose you had to design a no-frills, bare-bones transport protocol. What is the least you could get away with?
You might start with nothing at all: take the message from the application and hand it straight to the network layer. But section 3.2 showed why that fails — the receiving host would have no way of knowing which process the data is for. So you have to do a little more than nothing.
UDP (User Datagram Protocol) User Datagram Protocol A simple transport protocol with no reliability, no flow control and no congestion control. introduced in ch. 1 is what “a little more than nothing” looks like, and studying it tells you which parts of TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 are essential and which are optional. Everything in TCP that UDP lacks is something section 3.4 will have to build from scratch.
What UDP adds to the network layer
UDP user datagram protocol Simple The Internet’s bare transport protocol: addressing and an error check, nothing else. Precise UDP, defined in RFC 768. It adds almost nothing to IP: source and destination port numbers for multiplexing and demultiplexing, a length, and a checksum, in an 8-byte header. There is no handshake, no connection state, no retransmission, no flow control and no congestion control, so an application using UDP keeps full control of what it sends and when. introduced in ch. 3 — open in glossary is defined in RFC (Request For Comments) Request For Comments The name of an IETF standards document. There are currently nearly 9000 of them. introduced in ch. 1 768, and it does about as little as a transport protocol can. What little it adds, it adds on top of IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 . Aside from multiplexing and demultiplexing and some light error checking, it adds nothing to IP (Internet Protocol) Internet Protocol The network-layer protocol that defines the datagram format and addressing every Internet device must use. introduced in ch. 1 . If a developer chooses UDP instead of TCP (Transmission Control Protocol) Transmission Control Protocol The Internet transport protocol that delivers data reliably and in order, with flow control and congestion control. introduced in ch. 1 , the application is almost talking directly to IP.
Its whole behaviour is this. Take the message from the application process, attach the source and destination port fields, add two other small fields, and pass the segment to the network layer. The network layer wraps it in a datagram and makes a best-effort attempt to deliver it. If it arrives, UDP uses the destination port to hand the data to the right process.
Notice what is missing. There is no handshaking between the two transport layers before a segment is sent. For that reason UDP is called connectionless.
The example that made UDP famous
When the DNS (Domain Name System) Domain Name System Translates a human-friendly name such as www.ietf.org into a network address. introduced in ch. 1 application on a host wants to make a query, it builds the query message and passes it to UDP. Without performing any handshaking with the UDP entity on the destination machine, the sending host adds the header fields and passes the segment down. The network layer wraps it and sends it to a name server.
Then the DNS application waits. Perhaps the query was lost, or the reply was. If no reply comes, it can resend the query, send it to a different name server, or tell the calling application it could not get an answer.
That is worth dwelling on. DNS handles loss itself, in the application. It does not need a reliable transport protocol; it needs a fast one, and it deals with the consequences.
Why would anyone choose it?
The obvious question: isn’t TCP always preferable, since it provides reliable data transfer and UDP does not? The answer is no, and there are four reasons.
| What TCP does instead | Who cares | |
|---|---|---|
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
None of these is about speed once data is flowing — both protocols hand their segments to the same IP. Click a cell for the detail.
In plain words
None of the four is about raw speed once data is flowing. Both protocols hand their segments to the same IP underneath, and IP moves them at the same rate.
What UDP really sells is control and immediacy. Your data goes now, at the rate you chose, and nothing is held back to be resent later. For some applications a late packet is worthless. In a live voice call a syllable that arrives half a second late may as well be lost, so that is not a small thing.
| Application-layer protocol | ||
|---|---|---|
Cells marked ⓘ have an explanation — click to read it. Sortable columns have a ↕ in the heading.
Sort by the transport column. The pattern is clear once you do: everything that must not lose a byte uses TCP.
As you would expect, e-mail, remote terminal access and file transfer all run over TCP: they need reliable delivery. But plenty of important applications do not.
The book is over-broad about HTTP (HyperText Transfer Protocol) HyperText Transfer Protocol The application-layer protocol that requests and transfers Web documents. introduced in ch. 1 here
The text of this section says that early versions of HTTP ran over TCP “but that more recent versions of HTTP run over UDP”.
Read as written that is not right, and Figure 3.6 on the facing page gets it correct. HTTP/2 runs over TCP. Only HTTP/3 runs over UDP, using QUIC (Quick UDP Internet Connections) Quick UDP Internet Connections A transport-like protocol built in the application layer over UDP, carrying HTTP/3. The IETF now treats QUIC as a name rather than an abbreviation. introduced in ch. 2 to rebuild reliability above it — which is section 3.8. Follow the figure, not the sentence.
UDP with no congestion control is antisocial
Running multimedia over UDP is common, and it needs care, because UDP has no congestion control. Congestion control is what stops the network from entering a state where very little useful work is done.
Suppose everybody started streaming high-bit-rate video with no congestion control at all. There would be so much overflow at routers that very few UDP packets would get across the path. The uncontrolled senders would be hurting themselves.
And they would be hurting everybody else too. The high loss rates would cause TCP senders — which do decrease their rates in the face of congestion — to slow down dramatically. So the lack of congestion control in UDP produces two results at once: high loss between UDP senders and receivers, and the crowding out of TCP sessions.
Many researchers have proposed mechanisms to force all sources, UDP included, to perform adaptive congestion control [Mahdavi 1997; Floyd 2000; Kohler 2006: RFC 4340]. Section 3.7 returns to the fairness question.
You can have reliability over UDP — you just have to build it
It is possible for an application to have reliable data transfer while using UDP. You build the reliability into the application itself, by adding acknowledgement and retransmission mechanisms — precisely the ones section 3.4 is about to develop.
QUIC does exactly this. But the book is honest about the price: it is a nontrivial task that would keep an application developer busy debugging for a long time.
The reward is having your cake and eating it. Application processes can communicate reliably without being subject to the transmission-rate constraints TCP’s congestion control imposes.
The UDP segment structure
Click any box to read what that part of the message is for.
Every field, as text
- Source port # — 16 bits — the return address (example: 51873)
- Dest. port # — 16 bits — which socket on the receiving host (example: 53)
- Length — 16 bits — bytes in the whole segment, header included (example: 46)
- Checksum — 16 bits — did any bit change on the way here? (example: 0x2b4f)
Four fields, two bytes each, eight bytes in total. Compare it with the TCP header in section 3.5.2, which has eleven fields and takes twenty bytes.
The header has only four fields, each of two bytes — eight bytes in total. The port numbers do the demultiplexing job of section 3.2. The length field gives the number of bytes in the whole segment, header plus data. An explicit length is needed because the data field’s size differs from one segment to the next. The checksum lets the receiving host check whether errors have been introduced.
The UDP checksum
The checksum internet checksum Simple A small number sent with a packet so the receiver can tell whether the bits changed. Precise The error-detection field used by UDP and TCP. The sender treats the segment as a sequence of 16-bit words, adds them with any overflow carried around and added back in, and stores the ones complement of that sum. The receiver adds every 16-bit word including the checksum; if nothing was damaged the result is all ones. It detects errors but cannot correct them, and some multi-bit errors escape it. introduced in ch. 3 — open in glossary determines whether bits within the segment have been altered as it moved from source to destination. Bits change because of noise on a link, for example, or while the segment sits in a router’s memory.
The rule is short. The sender takes the ones complement of the sum ones-complement sum Simple Adding binary numbers, then adding any carry from the top back into the bottom. Precise The addition rule used by the Internet checksum: 16-bit words are added, and any carry out of the most significant bit is wrapped around and added to the least significant bit. The ones complement of a value is that value with every 0 turned into a 1 and every 1 into a 0. introduced in ch. 3 — open in glossary of all the 16-bit words in the segment, wrapping around any overflow encountered along the way. That result goes in the checksum field.
These are the book’s own three 16-bit words. Step through the additions, watch the carry wrap on the second one, then click any bit to damage the segment in flight.
In plain words
Add the words up. Whenever the total is too big to fit in 16 bits, take the bit that fell off the top and add it back in at the bottom. Then flip every bit.
The receiver adds up everything, including the checksum. If nothing was damaged, the answer is 16 ones. If any bit is a 0, something changed on the way.
It detects, and then it gives up
UDP provides error checking, but it does nothing to recover from an error. Some implementations simply discard the damaged segment. Others pass it up to the application with a warning.
That is the whole service. There is no retransmission, no notification to the sender, and no repair. Try the lab above: flip a bit, watch the check fail, and notice that nothing happens next.
You can also try to fool it. The check is not perfect — flip one bit in the same column of two different words and the two changes cancel out, leaving the sum unchanged. Detecting many errors is not the same as detecting all of them.
Why check at all, when Ethernet already does?
Many link-layer protocols, including Ethernet, provide error checking of their own — and Ethernet’s check is considerably stronger than this one. So why does UDP bother?
Two reasons. First, there is no guarantee that every link between source and destination provides error checking; one of them may use a link-layer protocol that does not. Second, bit errors can be introduced while a segment is stored in a router’s memory, even when every link carried it perfectly. That is between links, where no link-layer check applies.
Neither link-by-link reliability nor in-memory error detection is guaranteed. So if the end-to-end data transfer service is to have error detection at all, UDP must provide it at the transport layer, on an end-to-end basis.
This has a name: the end-end principle
The argument above is an instance of a celebrated idea in system design [Saltzer 1984], the end-end principle end-end principle Simple A job that only the two ends can finish properly should be done by the two ends. Precise A design rule in layered systems [Saltzer 1984]: functions placed at lower layers may be redundant, or of little value, compared with the cost of providing them at the higher layer. UDP checksums the segment end to end even though Ethernet already checks each link, because there is no guarantee that every link on the path checks anything, and because bits can be corrupted inside a router’s memory between two links. introduced in ch. 3 — open in glossary :
functions placed at the lower levels may be redundant or of little value when compared to the cost of providing them at the higher level.
Read it carefully, because it is easy to take the wrong lesson. It does not say lower layers should never check. Ethernet’s check is genuinely useful — it catches damage early and cheaply, on the link where it happened.
It says that a check at a lower layer cannot substitute for the one at the top, because the lower layer does not cover the whole journey. IP is meant to run over just about any layer-2 protocol, so nothing about any particular link can be assumed. The end-to-end check is the only one that covers everything.
You will meet this principle again and again — it is one of the few genuinely architectural ideas in this book.
What we have, and what is missing
That wraps up UDP. It is worth naming exactly where it leaves us.
| What UDP gives you | What it does not | |
|---|---|---|
| Reaching the right process | ||
| Knowing the data is undamaged | ||
| Knowing the data arrived | ||
| Getting it there eventually | ||
| Reading it in the right order |
Cells marked ⓘ have a reason behind them — click to read it.
The right-hand column is section 3.4’s task list.
TCP offers all of the right-hand column, and is naturally far more complex than UDP because of it. Before looking at how TCP works, section 3.4 steps back and asks the general question: given an unreliable channel, how would you build reliable transfer over it at all?
Check yourself
Check yourself
0 of 6 answered1.Why does DNS run over UDP rather than TCP?
Count the messages in a typical DNS exchange, then count what TCP would charge you before the first one.
2.predictIn the checksum lab, adding the third word overflows. What happens to the carry?
3.predictYou flip one bit in the lab and the receiver's total is no longer all ones. What does UDP do about it?
4.Ethernet already checks every frame for errors. Why does UDP check as well?
5.A video service decides to stream over UDP with no congestion control of its own. What is the risk if everybody does the same?
6.Which is NOT one of the four reasons an application developer might pick UDP?
What to remember
- UDP adds almost nothing to IP: port numbers, a length, and a checksum. Eight bytes of header against TCP’s twenty.
- The four reasons to choose it: finer control over what is sent and when, no connection establishment, no connection state, and a smaller header.
- The checksum exists despite Ethernet’s because not every link checks, and because bits can be corrupted inside a router’s memory. That is the end-end principle.