Transport Layer: UDP and TCP Basics

IP delivers datagrams between hosts, unreliably. The transport layer turns this into communication between processes, identified by 16-bit port numbers, and optionally adds reliability. The Internet has two main transport protocols:

Both protocols are described by what they carry and by how a TCP connection is opened, used and closed: headers, sequence and acknowledgement numbers, the three-way handshake, connection release, the state machine and the retransmission timer. Flow control and congestion control have their own notes.

Well-known server ports: 20 and 21 FTP, 22 SSH, 23 Telnet, 25 SMTP, 53 DNS, 80 HTTP, 443 HTTPS.

The checksum is the Internet checksum over a pseudo-header (source IP, destination IP, a zero byte, protocol 17, UDP length), the UDP header (with checksum 0) and the data, padded with a zero byte if odd. Including the IP addresses guards against delivery to the wrong host. Over IPv4 the checksum is optional: a transmitted value of 0 means "not computed", so a computed result of 0 is sent as 0xFFFF.

Three messages are the minimum that let both sides learn that the other has received their ISN. A two-way exchange would leave the server unable to tell a fresh SYN from a delayed duplicate of an old one.

Each direction is closed separately (a half-close): the side that has finished sends FIN, the other acknowledges it, and may keep sending until it sends its own FIN. The usual exchange is four segments, FIN, ACK, FIN, ACK, or three when the second FIN rides on the first ACK. The side that closes first waits in TIME-WAIT for $2 \times \text{MSL}$ (maximum segment lifetime; RFC 9293 takes MSL as 2 minutes) before forgetting the connection, so that its last ACK can be resent if lost and old duplicates die out.

Eleven states. The active closer passes through FIN-WAIT-1, FIN-WAIT-2 (or CLOSING on a simultaneous close) and TIME-WAIT; the passive closer through CLOSE-WAIT and LAST-ACK. SYN-SENT to SYN-RECEIVED is the simultaneous open, where both sides send SYNs at once.

TCP retransmits a segment if its acknowledgement does not arrive within the retransmission timeout (RTO), estimated from measured round-trip times $R$ (RFC 6298):

Karn's algorithm: do not take RTT samples from retransmitted segments (the ACK could belong to either copy), and double the RTO after each timeout until a new sample is taken. The original TCP specification (RFC 793) used only a weighted average, $\text{SRTT} \leftarrow \alpha\,\text{SRTT} + (1 - \alpha) R$ with $\alpha$ about 0.8 to 0.9, and $\text{RTO} = \beta \times \text{SRTT}$ with $\beta$ about 1.3 to 2.0 (within fixed bounds); a problem must state which rule and which constants it uses.

For a connection with client ISN $x$ and server ISN $y$, after the client has sent $D_c$ data bytes and the server $D_s$:

and the client's FIN carries seq $x + 1 + D_c$ and is acknowledged with $x + 2 + D_c$. The $+1$ terms are the SYN and the FIN.

Header overheads. With no options, a TCP segment over IPv4 carries 40 bytes of headers (20 IP + 20 TCP), a UDP datagram 28 (20 + 8). The maximum segment size advertised over Ethernet is usually $1500 - 40 = 1460$ bytes.

Client ISN 2000, server ISN 7000 (Figure 2).

Segments 3, 7 and 11 are pure ACKs and do not advance the sequence number; the FINs at 3501 and 7301 do.

A UDP datagram from 192.168.10.5:5353 to 172.16.30.40:53 carries the 4 bytes "GATE". Length = 12. The 16-bit words summed are:

The one's complement sum is 0x45B4, so the checksum is 0xBA4B.

RTT samples 100 ms then 140 ms; ignore $G$ and the 1-second minimum unless a problem includes them.

Using the new SRTT (105) in the RTTVAR update would give $\tfrac34 \cdot 50 + \tfrac14 \cdot 35 = 46.25$ and RTO 290: the order matters.

A TCP header has data offset 8: header length 32 bytes, 12 of them options. If the IP total length is 552 with a 20-byte IP header, the segment carries $552 - 20 - 32 = 500$ data bytes.

$\alpha = 0.9$, $\beta = 2$, SRTT starting at 30 ms, then samples of 26, 32 and 24 ms. SRTT becomes $0.9 \times 30 + 0.1 \times 26 = 29.6$, then $0.9 \times 29.6 + 3.2 = 29.84$, then $0.9 \times 29.84 + 2.4 = 29.256$ ms, and RTO $= 2 \times 29.256 = 58.512$ ms.

Continue Example 3 (SRTT 105, RTTVAR 47.5, RTO 295 ms). The next segment times out, so RTO doubles to 590 ms, and after a second timeout to 1180 ms. The ACK that finally arrives, 400 ms after the first copy was sent, could belong to either copy, so it gives no sample: SRTT and RTTVAR stay at 105 and 47.5. The following segment is acknowledged after 120 ms without retransmission:

Taking the ambiguous 400 ms as a sample would instead have given RTO 579.375 ms.

Five 500-byte segments start at 1001, 1501, 2001, 2501 and 3001; the one starting at 1501 is lost, and the receiver buffers out-of-order data. The four segments that arrive draw the ACKs 1501, 1501, 1501 and 1501: the first acknowledges bytes 1001 to 1500, the next three are duplicates (which trigger fast retransmit, TCP Congestion Control). When the retransmitted segment 1501 arrives the gap is filled, and the ACK jumps to 3501, covering everything buffered.

Client ISN 4,294,967,200. The first data byte is numbered 4,294,967,201; after 500 data bytes the next sequence number is $(4{,}294{,}967{,}200 + 1 + 500) \bmod 2^{32} = 405$, and the 96th data byte carries number 0. All sequence arithmetic is modulo $2^{32}$.

Common misconceptions.