RFC 768 (UDP) and RFC 1071 (computing the Internet checksum), cross-checked against the transport-layer material in Kurose and Ross, sections 3.1 to 3.3. The checksum example was computed in code and verified by re-adding it at the receiver.
Read the picture and the socket section together; they are one idea. Then do the checksum by hand, on paper, bit by bit. It is a guaranteed style of exam question and it only goes wrong in one place, the wraparound.
The picture: an apartment building's mailroom#
A letter addressed to an apartment building gets the letter to the right building. That is the network layer's job: IP addresses get data to the right host.
But a building has many apartments. Someone in the mailroom reads the apartment number and puts each letter in the right box. That is the transport layer. On a computer, the “apartments” are the programs running on it, called processes, and the apartment number is a port number.
| Layer | Delivers | In the picture | Uses |
|---|---|---|---|
| Network layer | Host to host | The street address of the building | IP address |
| Transport layer | Process to process | The apartment number | Port number |
Transport runs only in the end hosts. Routers in the middle never look at port numbers. They work at the network layer and below.
Vocabulary, before anything uses it#
| Term | What it means |
|---|---|
| Process | A running program, like your browser or a game. |
| Socket | The door between a process and the network. Data goes out and comes in through a socket. |
| Port number | A 16-bit number, 0 to 65,535, that identifies a socket on a host. 0 to 1023 are well-known ports reserved for standard services (HTTP 80, DNS 53). |
| Multiplexing | At the sender: gathering data from many sockets, adding headers with port numbers, and passing the segments down to the network layer. |
| Demultiplexing | At the receiver: reading the port numbers in each arriving segment and delivering it to the right socket. |
| UDP | User Datagram Protocol. A connectionless, “no frills” transport protocol. |
| Connectionless | No handshake before sending. Each segment is sent on its own. |
| Checksum | A number calculated from the data so the receiver can detect if bits were flipped on the way. |
Multiplexing and demultiplexing#
Your laptop may have a browser, a music app and a chat app all using the network at once. At the sender, the transport layer collects data from all their sockets, stamps each chunk with a header, and sends it down. That is multiplexing, many streams into one. At the receiver, the transport layer looks at each arriving segment and hands it to the right socket. That is demultiplexing, one stream back into many.
The key question is: what does the receiver look at to decide? The answer is different for UDP and TCP, and it is one of the most tested points in the chapter.
| Protocol | A socket is identified by | So |
|---|---|---|
| UDP (connectionless) | 2 values: destination IP address and destination port | Datagrams from different senders to the same destination port all go to the same socket. |
| TCP (connection-oriented) | 4 values: source IP, source port, destination IP, destination port | Each connection gets its own socket, even if two clients use the same destination port. |
Example: a web server on port 80 talks to two different clients. Both clients send to port 80. With TCP, the server keeps two separate sockets, because the source IP or source port differs. The four values together are called the 4-tuple.
Why does the UDP receiver still see the source port, if it does not use it to choose a socket? So it can reply. The source port becomes the destination port of the answer.
UDP demultiplexes on 2 values, TCP on 4. A question like “two hosts send UDP segments to the same port on server C: will they reach the same socket?” wants yes. The same question for TCP connections wants no.
UDP: what it does and why anyone uses it#
UDP adds almost nothing on top of IP: port numbers for multiplexing, and a checksum for error detection. It does not promise delivery, order, or any speed control. Segments may be lost or arrive out of order, and UDP will not fix it.
That sounds bad, so why use it? Because “no frills” also means “no delay”:
- No connection setup. No handshake, so no round trip wasted before sending. This is why DNS uses UDP.
- No connection state. The server does not track sequence numbers or buffers per client, so it can serve many more clients.
- Small header. 8 bytes, against at least 20 for TCP.
- No congestion control. The application sends as fast as it wants. Internet phone calls, video calls and many online games would rather skip late data than wait for it.
An application that wants reliability over UDP can build it in itself, at the application layer. HTTP/3 does exactly that, using a protocol called QUIC on top of UDP.
The UDP header: four fields, 8 bytes
0 16 31 (bits)
+---------------+---------------+
| source port | dest port |
+---------------+---------------+
| length | checksum |
+---------------+---------------+
| application data ... |
+-------------------------------+| Field | Size | Purpose |
|---|---|---|
| Source port | 16 bits | Sender's port, so the receiver can reply. |
| Destination port | 16 bits | Which socket at the receiver gets the data. |
| Length | 16 bits | Length of the whole UDP segment in bytes, header included. |
| Checksum | 16 bits | Lets the receiver detect bit errors. |
The length field counts the header too. A segment carrying 100 bytes of data has a length of 108, not 100.
The Internet checksum, step by step#
The checksum is a way to notice damage. Picture counting the coins in a bag before mailing it and writing the total on the label. If the receiver counts a different total, something went wrong. The checksum does the same thing with 16-bit chunks of the segment.
At the sender:
- Treat the segment as a series of 16-bit words. (The real UDP checksum also covers a small “pseudo-header” holding the IP addresses; exam questions leave it out.)
- Add them up. If a sum overflows past 16 bits, take the carry bit off the left and add it back in on the right. This is called wraparound.
- Flip every bit of the final sum: 0 becomes 1 and 1 becomes 0. This is the one's complement. The result is the checksum.
At the receiver: add up all the words including the checksum, with wraparound. If there were no errors, the answer is all 1s (1111111111111111). Any 0 in the result means an error was detected.
Compute the checksum of these three words.
word 1 1011011001011101
word 2 0111000111001010
word 3 0100111100001011
Step 1: Add word 1 and word 2. The result has 17 bits: it overflowed.
1011011001011101
+ 0111000111001010
= 10010100000100111 (17 bits)
Step 2: Wrap around. Take the leading 1 off and add it to the remaining 16 bits.
0010100000100111
+ 1
= 0010100000101000
Step 3: Add word 3. No overflow this time.
0010100000101000
+ 0100111100001011
= 0111011100110011
Step 4: Flip every bit.
sum 0111011100110011
checksum 1000100011001100
Check it like the receiver would. Sum + checksum = 0111011100110011 + 1000100011001100 = 1111111111111111. All 1s, so no error is detected.
Wraparound is not dropping the carry. Throwing the 17th bit away gives a different sum and a wrong checksum. The carry must be added back into the lowest bit.
The checksum detects errors; it cannot fix them. And it cannot catch every error: if two bits flip in a way that cancels out in the sum, the checksum still comes out right.
The transport layer adds port numbers so data reaches the right process; UDP adds only that plus a checksum, and UDP sockets are found by destination IP and port while TCP sockets need all four values.
Practice#
For the checksum question, write every line of binary. An answer with no working cannot earn partial credit.
- What does the transport layer add that the network layer does not provide?
- Define multiplexing and demultiplexing, and say where each happens.
- Hosts A and B each send a UDP segment to port 6789 on host C. Do both segments reach the same socket on C? Why?
- Two clients open TCP connections to a web server on port 80. How many sockets does the server use for them, and what tells them apart?
- Give three reasons an application might choose UDP over TCP.
- A UDP segment carries 512 bytes of data. What value is in its length field?
- Compute the Internet checksum of the two words 1111000011110000 and 0001001000110100.
- At the receiver, what result means no error was detected? Can the checksum miss an error?
- Why does the UDP header carry a source port if UDP demultiplexing does not use it?
Solutions#
Find the first line where your working split from the solution, and redo the problem from that line. Do not just read the answer and nod.
- Process-to-process delivery. The network layer delivers to a host. The transport layer uses port numbers to deliver to the right process on that host.
- Sender and receiver. Multiplexing happens at the sender: gathering data from many sockets and adding headers with port numbers. Demultiplexing happens at the receiver: using the port numbers to deliver each segment to the correct socket.
- Yes. A UDP socket is identified only by destination IP and destination port. Both segments have the same destination IP and port, so they go to the same socket. The source IP and port differ, and the application can read them.
- Two sockets, told apart by the 4-tuple. A TCP socket is identified by source IP, source port, destination IP and destination port. The two clients differ in source IP (or source port), so each connection has its own socket.
- Any three of: no connection setup delay, no connection state at the server (so more clients), a smaller header (8 bytes vs 20), and no congestion control (the application controls its sending rate).
- 520. The length field includes the 8-byte header: 512 + 8 = 520.
- 1111110011011010. Sum: 1111000011110000 + 0001001000110100 = 10000001100100100 (17 bits). Wrap around: 0000001100100100 + 1 = 0000001100100101. Flip every bit: 1111110011011010.
- All 1s; yes, it can. Adding all the words including the checksum should give 1111111111111111. Any 0 means an error. Some errors cancel out in the sum, for example two flips that raise one word and lower another by the same amount, so the checksum can miss them.
- So the receiver can reply. The receiving process uses the source port as the destination port of its answer.
Test-readiness checklist#
- ☐ I can explain the difference between host-to-host and process-to-process delivery.
- ☐ I can define multiplexing and demultiplexing and say where each happens.
- ☐ I can state that UDP sockets use 2 values and TCP sockets use 4, and apply it to a scenario.
- ☐ I can give the reasons applications choose UDP.
- ☐ I can draw the UDP header, name the four fields and give the header size.
- ☐ I can compute a 16-bit checksum with wraparound and one's complement.
- ☐ I can describe the receiver's check and explain why it can miss some errors.
On a checksum question, write out every addition in binary and show the wraparound as its own line. Most marks are for the method, and a single missed carry is easy to spot when the lines are there.
Frequently asked questions#
What is the difference between multiplexing and demultiplexing?
Multiplexing happens at the sender: the transport layer gathers data from many sockets and adds headers with port numbers. Demultiplexing happens at the receiver: the transport layer reads those port numbers and delivers each segment to the correct socket.
How does UDP demultiplexing differ from TCP demultiplexing?
A UDP socket is identified by two values, the destination IP address and destination port, so segments from different senders to the same port share one socket. A TCP socket is identified by four values, source and destination IP and port, so each connection has its own socket.
What fields are in the UDP header?
Four 16-bit fields: source port, destination port, length and checksum, for a header of 8 bytes. The length field counts the header plus the data.
How do you calculate the UDP checksum?
Add the 16-bit words together, and whenever the sum overflows past 16 bits, add the carry back into the lowest bit (wraparound). Then flip every bit of the result (one's complement). The receiver adds all the words plus the checksum and should get all 1s.
Why would an application use UDP instead of TCP?
UDP has no connection setup delay, keeps no connection state, has a smaller 8-byte header, and has no congestion control, so the application decides exactly when and how fast to send. DNS, Internet telephony and games often prefer that.
Something here not clear? A topic you wish we covered? Tell us. We read every message, and a request is the fastest way to get a guide written.
Test yourself on this topic
The free networking practice app has 19 questions on this topic and 500 across the whole course, each with an explanation for every answer. Offline, no ads, no account.
Practise this topic →