TCP — header, connection (3-way handshake, 4-way termination): Exercises

Before any numbers, three acronyms appear again and again on this page — pin them down now:

Definition Vocabulary this whole page uses

ISN — Initial Sequence Number: the starting byte-count each side randomly picks at connection setup. If a side's ISN is 4200, its very first byte is numbered 4200 (not 0) — random starts make it hard for an attacker to guess numbers and inject fake data.
MSL — Maximum Segment Lifetime: the longest time a single TCP segment is allowed to wander the network before it must be considered dead (routers drop it once its time-to-live expires). Typically ~2 minutes.
4-tuple (connection identity): a TCP connection is uniquely named by four things together: (source IP, source port, destination IP, destination port). Two connections differing in even one of these four are distinct. This is what must become "free again" after teardown before the same pair of ports can be safely reused.

Everything here rests on three rules you must internalize from the parent note:

Because R1–R3 are all about counting bytes, the figure below shows the counting as a ruler — every arrow you draw later is just a hop along this ruler. Read it before Level 2; the numbering in every later problem is this same picture with different start values.

Figure — TCP — header, connection (3-way handshake, 4-way termination)

Figure (byte ruler): a horizontal number line of sequence slots starting at ISN 4200. The leftmost tick (slot 4200) is drawn in red and labelled "SYN sits here (phantom slot, no data)". A black arrow spans slots 4201–4205 labelled "data segment: seq=4201, 5 bytes", and a caption reads "next seq = 4201 + 5 = 4206 (R1: count bytes, not packets)". Look for: the SYN occupies one slot even though it carries zero data.

Level 1 — Recognition

Problem 1.1

State the minimum and maximum size of a TCP header, name the single field that determines it, and derive why the minimum is 20 bytes — i.e. why the field can't legally be smaller than 5.

Recall Solution

Minimum = 20 bytes, maximum = 60 bytes.
The Data Offset field (4 bits) holds the header length measured in 32-bit words (1 word = 4 bytes). Four bits count $0$ to $2^{4} - 1 = 15$ , so the largest header is $15 \times 4 = 60$ bytes.
Why the minimum is 5 words, not 0–4: Data Offset must point past the fixed mandatory fields to where the data begins. The fixed fields — ports (4 B), sequence number (4 B), ack number (4 B), the offset/reserved/flags/window word (4 B), and checksum + urgent pointer (4 B) — already occupy $5 \times 4 = 20$ bytes. A Data Offset of 0–4 would claim the header is shorter than the mandatory fields, which is impossible (the data would overlap the ack number or the checksum). So values 0–4 are illegal; the smallest valid value is 5, giving the 20-byte minimum. (Note: "Reserved" bits are a separate field and are unrelated to this — they are held at 0 for future use, not part of the offset.)

Problem 1.2

For each flag below, write its one-line meaning: SYN, ACK, FIN, RST, PSH.

Recall Solution

SYN — "let's synchronize sequence numbers" (setup only).
ACK — "the Acknowledgment field is valid; I am acknowledging received bytes."
FIN — "I have no more data to send; closing my sending direction."
RST — "reset/abort this connection immediately, something is wrong."
PSH — "push these bytes up to the receiving application now, don't sit them in a buffer waiting for more." (You will see PSH set on data segments in Level 4.)

Problem 1.3

The Source Port field is 16 bits wide. What is the largest port number it can carry, and why exactly 16 bits?

Recall Solution

16 bits count from $0$ to $2^{16} - 1 = 65535$ . So the largest port is 65535. Ports are defined as unsigned integers in the range $0..65535$ , which needs exactly $⌈ lo g_{2} 65536 ⌉ = 16$ bits — no fewer would reach 65535, no more are needed.

Level 2 — Application

Problem 2.1

Client ISN (Initial Sequence Number) $x = 4200$ , Server ISN $y = 9000$ . Write the three handshake segments with their seq and ack values filled in.

Recall Solution

Apply R2 (SYN eats one slot) and R3 (ack = next expected).

C → S: SYN, seq $= 4200$ .
S → C: SYN,ACK, seq $= 9000$ , ack $= 4200 + 1 = 4201$ .
C → S: ACK, seq $= 4200 + 1 = 4201$ , ack $= 9000 + 1 = 9001$ .

The figure below is worth pausing on: it shows which side owns which number. The accent-red arrow is the single segment that carries both an ack of the client (4201) and the server's own new ISN (9000) — the piggyback that makes setup 3 messages instead of 4. That merge is invisible in the text but obvious in the picture.

Figure (3-way handshake): two vertical black lifelines, CLIENT (ISN x=4200) on the left, SERVER (ISN y=9000) on the right. Three diagonal arrows drop down between them: "1. SYN seq=4200" (C→S), "2. SYN,ACK seq=9000 ack=4201" drawn in red (S→C), "3. ACK seq=4201 ack=9001" (C→S). Look for: the red middle arrow is the one segment that both acks the client and announces the server's own ISN.

Problem 2.2

After the handshake of 2.1 completes, the client sends a 500-byte data segment, then a 300-byte data segment. Give the seq number of each data segment.

Recall Solution

After the handshake the client's next byte index is 4201 (its SYN used 4200).

First data segment: seq $= 4201$ , carries bytes $4201 \dots 4700$ (500 bytes).
Second data segment: seq $= 4201 + 500 = 4701$ , carries bytes $4701 \dots 5000$ (300 bytes).

By R1, next seq = current seq + payload length. This is literally two hops along the ruler in the intro figure.

Problem 2.3

The client received the server's first 500 data bytes starting at seq 9001. What ACK number does the client send back?

Recall Solution

By R3, ack = next expected byte. The server sent bytes $9001 \dots 9500$ . The next byte expected is $9500 + 1 = 9501$ . So the client sends ack = 9501.

Level 3 — Analysis

Problem 3.1

You capture this trace. Fill in the missing values A and B:

#	Dir	Flags	seq	ack
1	C→S	SYN	100	—
2	S→C	SYN,ACK	700	A
3	C→S	ACK	B	701

Recall Solution

A = ack of client's SYN = $100 + 1 = 101$ (R2: SYN eats one slot).
B = client's next seq = $100 + 1 = 101$ (its SYN used slot 100).
Cross-check: line 3's ack $= 701 = 700 + 1$ , consistent with acking the server's SYN. ✓

Problem 3.2

A client sends SYN seq=100. The server has no process listening on that port. What flags does the server reply with, and what seq/ack does that reset carry? Explain why some resets set the ACK flag and some don't.

Recall Solution

The server replies with a RST. There is no application to synchronize with, so a SYN-ACK would be meaningless — it would promise a connection that cannot exist. RST tells the client "abort, no one is here," so the client fails fast instead of retransmitting SYNs.

The seq/ack of the reset — two cases (RFC 793 rule):

If the incoming segment had the ACK flag off (a bare SYN does, as here): the RST must acknowledge the offending segment so the peer accepts it. The RST is sent as RST,ACK with seq = 0 and ack = (incoming seq + segment length + 1 for the SYN). For our bare SYN seq=100 (0 data bytes, SYN eats one slot): seq = 0, ack = 100 + 0 + 1 = 101. The ACK flag is set precisely because the RST must name the next expected byte so the client can validate that this reset really belongs to its SYN.
If the incoming segment had the ACK flag on (e.g. a stray data segment carrying ack = z): the RST simply echoes that number as its own sequence — seq = z, ACK flag off, no ack field. Here the incoming ACK already pins the sequence space, so no separate acknowledgment is needed.

Why the split matters: a reset that can't be validated against the sequence space would be a trivial attack vector (anyone could inject a blind RST). By forcing the RST to either ACK the offending segment or echo its ack number, TCP makes a reset believable only if it lines up with real sequence numbers.

Problem 3.3

During teardown the active closer C sends FIN seq=u. The server acks with ack=u+1, then keeps sending 200 bytes of data (half-close) before sending its own FIN. If the server's data started at seq $= 3000$ , what seq does the server's FIN carry?

Recall Solution

The server sent bytes $3000 \dots 3199$ (200 bytes). By R1, the next byte index is $3000 + 200 = 3200$ . The FIN sits at that next slot, so the server's FIN carries seq = 3200 (and by R2 it consumes slot 3200, so C will ack with $3201$ ).

The half-close timeline below adds one insight the numbers alone hide: the red DATA arrow physically sits between the ACK and the FIN. That gap is why the server's ACK and FIN cannot merge into one segment — you can literally see the 200 bytes forcing them apart, which is the geometric reason teardown is 4-way.

Figure (half-close teardown): two vertical black lifelines, CLIENT (active closer) left, SERVER (still has data) right. Four black arrows plus one red one, top to bottom: "1. FIN seq=u" (C→S), "2. ACK ack=u+1" (S→C), then in red "DATA seq=3000..3199 (200 B)" (S→C), "3. FIN seq=3200" (S→C), "4. ACK ack=3201" (C→S). Look for: the red data arrow wedged between the ACK and the FIN — that is why the two cannot merge into one message.

Level 4 — Synthesis

Problem 4.1

Write the complete segment sequence for this whole conversation. Client ISN $= 2000$ , Server ISN $= 8000$ . After the handshake: client sends 100 data bytes; server acks then sends 50 data bytes; client acks; then the client closes (4-way teardown, server has no more data so its ACK and FIN merge). Give seq and ack for every segment.

Recall Solution

Handshake (R2, R3):

C→S SYN seq=2000
S→C SYN,ACK seq=8000 ack=2001
C→S ACK seq=2001 ack=8001

Data phase (R1, R3) — the PSH flag (defined in Problem 1.2) tells the receiver to hand these bytes to the application immediately: 4. C→S ACK,PSH seq=2001 ack=8001, 100 bytes ( $2001 \dots 2100$ ) 5. S→C ACK seq=8001 ack=2101 (acks C's 100 bytes) 6. S→C ACK,PSH seq=8001 ack=2101, 50 bytes ( $8001 \dots 8050$ ) 7. C→S ACK seq=2101 ack=8051 (acks S's 50 bytes)

Teardown (client active closer; here server is done, so its ACK+FIN merge → looks 3-message but is still logically 4): 8. C→S FIN,ACK seq=2101 ack=8051 (FIN eats slot 2101) 9. S→C FIN,ACK seq=8051 ack=2102 (acks C's FIN with 2102, and sends own FIN; FIN eats slot 8051) 10. C→S ACK seq=2102 ack=8052 → C enters TIME_WAIT

Note: the merge in step 9 only happened because the server had no more data. Had it needed to send more, steps 8–10 would expand to a full 4 distinct messages.

Problem 4.2

In Problem 4.1, explain in one sentence each why (a) step 8's seq is 2101 not 2100, and (b) step 10's ack is 8052 not 8051.

Recall Solution

(a) The client had sent bytes through 2100 (100 bytes starting at 2001), so its next byte index — where the FIN sits — is $2100 + 1 = 2101$ . (b) The server's FIN occupied slot 8051 (R2), so the next expected slot is $8051 + 1 = 8052$ ; the ACK number is always next expected.

Level 5 — Mastery

Level 5 needs one more tool that the earlier levels quietly assumed away: because the sequence number field is only 32 bits, it eventually runs out of numbers and wraps back to 0. Before the wrap-around problem, build the tool for reasoning across that wrap.

Definition Serial-number (modulo

$2^{32}$ ) arithmetic — how to compare seq numbers Sequence numbers live in a circle of size $2^{32}$ , not on an infinite line: after $2^{32} - 1$ comes $0$ again. So "is X ahead of Y?" cannot be answered by plain $X > Y$ (that breaks the moment Y is just below the wrap and X is just above it). The rule (this is serial-number arithmetic, RFC 1982) is:

Compute the signed difference $d = (X - Y) mod 2^{32}$ , then reinterpret $d$ into the range $- 2^{31} \dots 2^{31} - 1$ (i.e. if $d \geq 2^{31}$ , subtract $2^{32}$ ).
$X$ is after $Y$ (newer) iff $d > 0$ ; $X$ is before $Y$ iff $d < 0$ ; equal iff $d = 0$ .
This works because a real TCP window is tiny compared to $2^{31}$ — the two numbers you compare are always closer than half the circle, so "the short way round the circle" is unambiguous.

Example: is $X = 4$ after $Y = 4294967290$ ? $d = (4 - 4294967290) mod 2^{32} = 10$ , which is $\leq 2^{31}$ , so $d = + 10 > 0$ ⇒ yes, 4 is 10 bytes ahead even though $4 < 4294967290$ as plain integers. That is exactly the wrap you meet in Problem 5.4.

Problem 5.1

Explain the exact purpose of TIME_WAIT and compute its typical duration if $MSL = 2$ minutes. Give the two independent reasons it exists, name the four fields that must become reusable, and reconcile why both reasons land on the same $2 \times MSL$ interval even though flushing old duplicates seems to need only one MSL.

Recall Solution

Recall MSL = Maximum Segment Lifetime, the longest a stray segment may live on the network (~2 min). Duration $= 2 \times MSL = 2 \times 2 min = 4 minutes$ . Reason 1 — last-ACK safety: if the active closer's final ACK is lost, the peer will retransmit its FIN; staying in TIME_WAIT lets the closer still be around to re-ACK it. Reason 2 — flush old duplicates: any straggling packets from this connection must fully die before the same connection identity is reused. The identity that must become free again is the 4-tuple (defined at the top): (source IP, source port, destination IP, destination port).

Why both reasons need $2 \times MSL$ , not $1 \times MSL$ :

Reason 1 by itself already demands two MSLs: after the closer sends its final ACK, that ACK may take up to one MSL to arrive; if it is lost, the peer times out and resends its FIN, and that retransmitted FIN takes up to another MSL to travel back. To guarantee the closer is still alive to catch the very last possible resent FIN, it must wait $MSL + MSL = 2 \times MSL$ .
Reason 2 alone would indeed only need one MSL (a single straggler dies within one lifetime). But it does not shorten the wait — it is subsumed by Reason 1's stricter $2 \times MSL$ . So the two reasons don't add up; the larger requirement (Reason 1's $2 \times MSL$ ) governs, and Reason 2 is automatically satisfied within it. Hence one interval, $2 \times MSL$ , honours both.

Problem 5.2

Two hosts simultaneously send SYNs to each other (simultaneous open). C sends SYN seq=100; before it arrives, S sends SYN seq=500. Sketch what each side does and how many effective segments establish the single connection.

Recall Solution

This is a simultaneous open. Neither side is "the server."

C sends SYN seq=100; S sends SYN seq=500 — both cross on the wire.
Each host, on receiving the other's SYN, replies with a SYN,ACK acking $+ 1$ : C sends SYN,ACK seq=100 ack=501; S sends SYN,ACK seq=500 ack=101.
Both transition through SYN_RCVD and reach ESTABLISHED.
Total effective segments = 4 (two SYNs + two SYN-ACKs), not 3, because there is no single side to piggyback everything onto. Still one connection results.

Problem 5.3

A retransmitted SYN and a duplicate old SYN both reach the server. Explain why numbering the SYN itself (R2 — the phantom slot) is what makes SYN retransmission safe.

Recall Solution

Because the SYN consumes sequence slot $x$ , an ACK of value $x + 1$ specifically acknowledges "I received the SYN at slot $x$ ." If the SYN is lost, no $x + 1$ ack returns, so the sender knows to retransmit. If a stale duplicate SYN arrives after the connection moved on, its slot number won't match the current expected window and it is discarded (or triggers RST). Without giving the SYN its own slot, there would be no unambiguous way to acknowledge or to reject a stale copy — reliability of the very first message would collapse.

Problem 5.4 — sequence-number wrap-around

The sequence number field is 32 bits, so it counts $0$ to $2^{32} - 1 = 4294967295$ and then wraps back to 0 (modulo $2^{32}$ arithmetic). Suppose a segment has seq $= 4294967290$ and carries 10 data bytes. (a) What is the seq of the next segment? (b) Using the serial-number rule from the definition above, confirm the next seq is genuinely ahead of the current one even though its plain integer value is smaller.

Recall Solution

(a) Naively $4294967290 + 10 = 4294967300$ , but the field is modulo $2^{32}$ : $(4294967290 + 10) mod 2^{32} = 4294967300 - 4294967296 = 4 .$ So the next segment's seq is 4 — the counter rolled over: bytes at indices $\dots, 4294967294, 4294967295, 0, 1, 2, 3$ were sent, and the next unused slot is 4. (b) Apply serial-number arithmetic with $X = 4$ (next) and $Y = 4294967290$ (current): $d = (X - Y) mod 2^{32} = (4 - 4294967290) mod 2^{32} = 10.$ Since $10 < 2^{31}$ we keep $d = + 10 > 0$ , so X is 10 bytes ahead of Y — exactly the 10 bytes we sent, wrap notwithstanding. This is the deep reason R1/R2 are stated as counting, not as unbounded addition: the "line" is really a circle, and TCP measures the short signed distance around it.

Figure (seq wrap-around): a black circle representing the whole $2^{32}$ sequence space, with slot 0 marked at the top and a caption "2^32 wraps to 0 here". A point just to the left of the top is labelled "4294967290"; a red point just to the right of the top is labelled "lands at 4". A thick red arc sweeps from 4294967290 across the 0 mark to 4, annotated "+10 bytes crosses the top". Look for: the +10 hop is short and forward even though the number appears to shrink — that is why we compare by signed distance, not magnitude.

Wrap-up Recall

Recall Rapid-fire (cover the answers)

Next seq after sending $n$ data bytes from seq $s$ ? → $(s + n) mod 2^{32}$
Next seq after a lone SYN at seq $s$ ? → $s + 1$
Ack a peer's FIN sitting at seq $f$ ? → $f + 1$
RST to a bare SYN seq=100? → RST,ACK seq=0 ack=101
TIME_WAIT duration with MSL = 2 min? → 4 min (governed by the last-ACK $2 \times$ MSL rule)
What four fields identify a connection? → (src IP, src port, dst IP, dst port)
How many segments for simultaneous open? → 4
Is seq 4 ahead of seq 4294967290? → yes, by signed distance +10

Connections

Sliding Window & Flow Control (seq/ack numbers drive the window)
Reliable Data Transfer Principles (why phantom slots make SYN/FIN reliable)
Sockets & Ports (the 4-tuple reused after TIME_WAIT)
TCP Congestion Control (uses the same seq/ack machinery)
IP — packet structure & routing (the IPs in the 4-tuple)
UDP — connectionless transport (contrast: none of this numbering exists)