Transport layer I: ports, UDP, the TCP segment and the handshake

The network layer carries a packet from one host to another. But on that host the browser, Spotify and SSH are all running at the same time. It is the transport layer that decides which program the packet goes to. This week you will see two protocols: UDP, which is fast but makes no promises, and TCP, which is reliable but heavier. The most frequent exam questions are checksum calculation and seq/ack numbers. Golden rules:

1. The port selects the process. The IP address finds the host, the port number finds the socket on that host.
2. A UDP socket is identified by 2 values, a TCP socket by 4 values.
3. Checksum: add, wrap the carry around, flip. The sum at the receiver must come out as 0xFFFF.
4. ack = the next expected byte. That is seq + length.
5. SYN and FIN each take one number. Even though they carry no data.

What does the transport layer do?

The application layer produces the message. The transport layer splits it into segments, adds a header and hands it to the network layer. On the other side, it looks at the header and delivers the data to the right socket. IP is a “best effort” service: packets can be lost, corrupted or reordered. The transport layer chooses how much assurance to put on top of this.

Neither gives a guarantee of delay or bandwidth. This is a classic “which is not true” option on the exam.

Multiplexing and demultiplexing

Collecting data from many sockets on the sending side and writing the port into the header is called multiplexing. Looking at the port in the header on the receiving side and distributing the data to the right socket is called demultiplexing.

The port number is 16 bits, so there are $2^{16} = 65536$ values. Ports 0-1023 are the well-known ports. The client side usually uses an ephemeral port given by the operating system.

• UDP: the socket is found by (destination IP, destination port). Datagrams from different clients arriving at the same port land in the same socket. The source information is used only as the reply address.
• TCP: the socket is found by (source IP, source port, destination IP, destination port). A web server listens on 80 but opens a separate socket for each client connection.

PITFALL · “same destination port = same socket” is true only for UDP. In TCP, even if two different clients connect to the same server port, there are two separate sockets because the source IP or source port differs.

UDP and the checksum

The UDP header has four fields, each 16 bits: source port, destination port, length (in bytes, including the header), checksum. In total 8 bytes. A datagram carrying 120 bytes of data has a length field of 128. The largest UDP data over IPv4 is 65535 − 20 − 8 = 65507 bytes.

The checksum is meant to catch bit corruption in transit. The UDP checksum covers the header, the data, and a pseudo-header containing the IP addresses. The calculation method:

1. Split the data into 16-bit words and add them.
2. If the sum exceeds 16 bits, the overflowing carry is added to the lowest bit (wraparound).
3. Take the one’s complement of the result: flip every bit.

Worked example: words 0xB4A2, 0x6C3F, 0x1E90.

0xB4A2                         1011 0100 1010 0010
+ 0x6C3F  = 0x120E1  (17 bits, there is a carry)
            0x20E1 + 1 = 0x20E2   0010 0000 1110 0010
+ 0x1E90  = 0x3F72   (no carry)   0011 1111 0111 0010
sum       = 0x3F72
checksum  = flip               1100 0000 1000 1101  = 0xC08D

The receiver adds all the words together with the checksum: 0x3F72 + 0xC08D = 0xFFFF. If all bits are 1, no error was seen. If there is even a single 0, the packet is corrupted.

TIP · flipping in hex. One’s complement = 0xFFFF − x. For 0x3F72: F−3=C, F−F=0, F−7=8, F−2=D → 0xC08D. You don’t need to write it bit by bit.

PITFALL · the checksum doesn’t catch every error. If in two words, at the same bit position, one flips 0→1 and the other 1→0, the sum doesn’t change and the error is invisible. The checksum detects, it does not correct.

The idea of reliable data transfer (rdt)

TCP’s reliability comes from a model built up step by step. You can summarize the rdt versions in the textbook like this:

rdt3.0 is a stop-and-wait protocol. Because its efficiency is low, TCP uses pipelining: it sends several segments without waiting for an ACK. You saw the details of Go-Back-N and Selective Repeat in week 3.

The TCP segment

 0                   16                  31
+---------------------+--------------------+
|   source port       |   destination port |
+---------------------+--------------------+
|              sequence number             |
+------------------------------------------+
|          acknowledgment number           |
+------+------+-------+--------------------+
|offset| rsv  | flags |  receive window    |
+------+------+-------+--------------------+
|     checksum        |  urgent pointer    |
+---------------------+--------------------+
|        options (variable)                |
+------------------------------------------+
|        data                              |

• Sequence number: the number of the first byte in the segment. TCP numbers bytes, not segments.
• Acknowledgment number: the next byte the receiver expects. It is cumulative: it means “everything up to this has arrived”.
• Data offset (header length): the header size, in 4-byte words. If 5 it is 20 bytes, if 8 it is 32 bytes (12 bytes of options).
• Flags: SYN (open the connection), ACK (the ack field is valid), FIN (close), RST (reset), PSH, URG.
• Receive window: the receiver’s free buffer space, for flow control (week 8).

Worked example: a client with ISN 7200 sends three segments of 1000, 1000 and 600 bytes.

segment   seq     length    ACK for this segment
1         7201    1000      8201
2         8201    1000      9201
3         9201     600      9801

Three-way handshake and teardown

Before sending data, TCP has the two sides share their initial sequence numbers (ISN). Let the client ISN = 4000 and the server ISN = 9000:

1) client → server   SYN=1          seq=4000
2) server → client   SYN=1, ACK=1   seq=9000   ack=4001
3) client → server   ACK=1          seq=4001   ack=9001   (may carry data)
4) client 500 bytes  seq=4001  → server's reply ack=4501

Why three steps and not two? With two steps the server can’t know that the client received its own ISN. A connection could be opened pointlessly because of an old delayed SYN.

At teardown each direction is closed separately. The client sends a FIN (seq 5501), and the server acknowledges it with ack 5502. When the server finishes its work, it sends its own FIN (seq 12001), the client returns ack 12002 and waits for a while in the TIME_WAIT state. This way, if the last ACK is lost, it can resend it.

PITFALL · SYN flood. If the server allocates resources for every SYN and holds half-open connections, an attacker can fill the table with SYNs with forged source addresses. That is why SYN cookies exist. You will see it again in the DoS topic in week 10.

Cumulative ACK and loss

Four segments of 50 bytes each, numbered 100, 150, 200, 250, were sent, and 150 was lost:

arrives   receiver's ACK
100       150
150       (lost)
200       150   (duplicate ACK)
250       150   (duplicate ACK)

The receiver can buffer out-of-order segments, but the ACK number is always the first missing byte. When 150 arrives again, the ACK jumps straight to 300.

Common mistakes