Noesis
4.3.19 · D5Computer Networks

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

2,167 words10 min read↑ Back to topic

These items are conceptual only — no arithmetic-heavy sequence-number chases (those live in the D3/D4 pages). Here we hunt misunderstandings.

Two terms you must have first

For the full picture of when each control flag rides the stream, keep these two exchange diagrams open while you answer:

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

True or false — justify

TCP numbers each packet with a packet ID.
False. TCP numbers bytes of the stream; a segment's sequence number is just the byte index of its first data byte. There is no per-packet counter anywhere in the header.
The SYN flag carries no sequence number of its own.
False. A SYN announces the sender's Initial Sequence Number (ISN) in the Sequence field, and it also consumes one sequence slot (a phantom byte position) so it can itself be retransmitted reliably.
A connection can be set up with only two messages if the network is perfect.
False. Even with zero loss you need three: each side must learn and confirm the other's ISN. Two messages would leave the client's ISN unconfirmed by anyone.
The Acknowledgment Number is only meaningful when the ACK flag is set.
True. The 32-bit Ack field always exists physically, but its contents are garbage unless the ACK flag says "this field is valid."
Both the SYN and the FIN each eat exactly one sequence slot.
True. Both are control events on the byte stream; giving each a phantom slot lets a lost SYN or FIN be retransmitted and acknowledged like real data.
TIME_WAIT lasts one MSL.
False. It lasts 2·MSL (two Maximum Segment Lifetimes) — long enough for a lost final ACK to trigger the peer's FIN retransmission (one MSL out) and that FIN's reply to return (one MSL back).
The server always enters TIME_WAIT.
False. Whoever sends the first FIN (the active closer) enters TIME_WAIT. That is often the client, so the role is behaviour-based, not machine-based.
A 20-byte header means the segment has no Options.
True. The Data Offset of a 20-byte header is 5 words (5×4=20), leaving no room for Options; any Options push the header above 20 bytes up to the 60-byte max.
The Window field controls congestion in the network core.
False. The Window field is flow control — how much the receiver can buffer right now. Congestion control is a separate mechanism (see TCP Congestion Control) using a variable that never appears in the header.
TCP Fast Open lets an application send data inside the very first SYN segment.
True. Classic TCP forbids data before the handshake completes, but the TCP Fast Open extension does permit data in the first SYN; the base mental model to keep is still "sync before data."
Sequence numbers count upward forever without ever restarting.
False. The Sequence field is only 32 bits, so it counts modulo and wraps around back to 0 on a long/fast connection; TCP compares numbers using modular ("is-A-before-B") arithmetic, not plain size comparison.

Spot the error

"S→C: SYN,ACK seq=5000 ack=5000" (client ISN was 1000).
The ack should be 1001, not 5000. Ack = next byte expected from the client, and the client's SYN used slot 1000, so the next expected byte is 1001. Ack has nothing to do with the server's own ISN.
"Teardown is symmetric to setup, so it's also 3-way."
Wrong — teardown is 4-way. Each direction closes independently: after the first FIN the other side may still send data (half-close), so its ACK of the FIN and its own FIN often cannot merge into one segment.
"The ACK number acknowledges the last byte I successfully received."
It names the next byte expected, i.e. last-received + 1. Reporting the last received byte would be ambiguous about whether byte N itself arrived.
"Two 32-bit fields (seq and ack) are redundant — one counter would do."
TCP is full-duplex: two independent byte streams flow at once. Seq tracks my stream's position, ack tracks how far I've read yours; a single number cannot represent two separate streams.
"Data Offset is measured in bytes, so its max header is 15 bytes."
Data Offset counts 32-bit words, not bytes. Max value 15 words × 4 = 60 bytes, which is why the ceiling is 60, not 15.
"RST and FIN mean the same thing — the connection ends."
FIN is a polite close ("no more data, let's flush both sides"); RST is an abort ("something is wrong, drop everything now") with no graceful exchange.
"After the client sends its FIN, it can never receive data again."
It can still receive — it only closed its own sending direction. This half-close lets the server keep sending until the server itself sends FIN.
"When the sequence number reaches its maximum it must be compared as a bigger integer, so old data always looks 'newer'."
Wrong — TCP uses modular comparison: after the 32-bit counter wraps to 0, "0 is after " holds, so ordering still works across the wrap. Treating them as plain integers would misjudge which byte is newer.

Why questions

Why must the handshake happen before any data, not alongside it?
Because acknowledging byte k is meaningless until both sides agree where byte 0 sits (the ISN). Without an agreed origin, "I got up to byte X" has no defined meaning.
Why does TCP number bytes instead of segments?
Byte numbering survives re-segmentation — a retransmission may split or merge data differently, but byte positions stay fixed, so acknowledgments and ordering remain unambiguous.
Why can setup's middle two logical steps merge but teardown's cannot?
In setup the server's ack of the client and its own SYN both happen instantly and can piggyback. In teardown the receiver's ack of the FIN is immediate, but its own FIN waits until the receiver has no more data — different times, so no reliable merge.
Why do ISNs start at random-ish values instead of 0?
Starting at unpredictable numbers stops old duplicate segments from a previous connection (same port pair) from being mistaken for valid data, and makes sequence numbers harder to spoof.
Why does TIME_WAIT also help the next connection on the same ports?
It forces stray packets from the finished connection to expire (die within one MSL) before the identical port pair can be reused, preventing ghost data from bleeding into a fresh connection.
Why is there a Checksum in TCP when IP already has one?
IP's checksum covers only the IP header, and lower layers may not catch every error. TCP's checksum protects its header + payload (plus a pseudo-header), giving end-to-end integrity — the reliability job is TCP's, not IP's.
Why does a SYN need to be retransmittable at all?
Because the underlying IP layer can lose it. Giving the SYN a sequence slot lets a lost setup attempt be detected (no SYN-ACK) and retried, just like lost data.
Why does the 32-bit sequence space eventually force wrap-around handling?
Because bytes (~4 GB) is finite; a fast connection can cycle through every number and reuse them, so TCP must compare sequence numbers modularly and (with timestamps) guard against old wrapped numbers looking fresh.

Edge cases

What happens if the very first SYN is lost?
No SYN-ACK ever comes, the client's timer fires, and it retransmits the SYN. This is exactly why the SYN occupies a sequence slot — it is recoverable like normal data.
What if the active closer's final ACK (step 4) is lost?
The peer's FIN goes unacknowledged, so the peer retransmits its FIN; the closer is still in TIME_WAIT, sees it, and re-sends the ACK. This is one of the two reasons TIME_WAIT exists.
What if both sides send FIN at the same time (simultaneous close)?
Each FIN is acknowledged by the other, and both ends pass through their own closing states independently — no single "active closer"; each side that sent a FIN handles TIME_WAIT for its own direction.
Can a receiver advertise a Window of 0?
Yes. A zero window means "my buffer is full, stop sending"; the sender pauses and later probes with a tiny packet until the receiver advertises room again. This is flow control (see Sliding Window & Flow Control), not an error.
What does it mean if a segment has payload length 0 but the ACK flag set?
It's a pure acknowledgment — no data, just reporting the next expected byte. Its sequence number does not advance the stream because it carries no bytes.
What happens when the 32-bit sequence number reaches its maximum during a long transfer?
It wraps around to 0 and keeps counting (modulo ). TCP still orders bytes correctly using modular comparison, and the Timestamp option (PAWS) protects against an old, wrapped number being mistaken for a new one.
What if an application sends nothing but wants to keep the connection open?
The stream simply idles; no sequence numbers advance because no bytes flow. Unlike UDP, the TCP connection state persists on both ends even with zero data in flight.
What is the smallest legal Data Offset value, and why can't it be smaller?
5 (words) = 20 bytes, the mandatory fixed header. Nothing below 20 bytes can hold all required fields, so 5 is the floor.

One-line recall

Recall Fastest self-check
  • Numbering unit? ::: bytes, not packets
  • What is a sequence slot? ::: one position on the byte-number line; SYN/FIN each take one phantom slot
  • Ack field meaning? ::: next byte expected
  • Why 3-way but 4-way teardown? ::: setup syncs both directions at once; teardown closes each direction separately (half-close)
  • Who does TIME_WAIT, how long, what is MSL? ::: active closer, 2·MSL, where MSL = Maximum Segment Lifetime
  • What happens at sequence number ? ::: wrap-around to 0, compared modularly
  • Header min/max? ::: 20 / 60 bytes

Connections

  • 4.3.19 TCP — header, connection (3-way handshake, 4-way termination) (Hinglish) (parent, Hinglish)
  • UDP — connectionless transport (the no-handshake contrast)
  • Sliding Window & Flow Control (the Window field's real job)
  • TCP Congestion Control (why Window is not congestion control)
  • Reliable Data Transfer Principles (why seq/ack/checksum exist)
  • Sockets & Ports (the port fields)
  • IP — packet structure & routing (the layer TCP repairs)