Connection Termination

FIN, ACK, FIN, ACK — and the mysterious TIME-WAIT

Step 1 of 2 — understand the idea. Read this first and the packet trace will confirm what you already expect, instead of teaching you two things at once.

What you'll be able to do

▸Walk the four-way close packet by packet
▸Show that each direction closes independently (half-close)
▸Explain what TIME-WAIT is for and who pays it

Before this lesson — it builds directly on:

A connection is two independent streams — bytes flowing each way — and there is no reason both should finish at the same moment. A client can say 'that's my whole request, but keep the answer coming'. So TCP closes each direction separately: each side announces it's finished sending, and each announcement gets acknowledged. Two announcements plus two acknowledgements is four packets, and unlike the handshake they usually can't be combined, because the two sides finish at different times.

✗ Common misunderstanding: RST and FIN both just close the connection.

Why that's wrong: FIN is a graceful, acknowledged, half-duplex shutdown: 'I'm done sending, but I'll keep receiving.' RST is an immediate abort — unacknowledged, unanswerable, and it discards anything still in flight.

Correct model: FIN is saying goodbye; RST is hanging up mid-sentence. FIN takes four packets and preserves data; RST takes one and may lose data.

The packets prove it: Compare the termination trace (FIN, ACK, FIN, ACK, then TIME-WAIT) with the reset trace: one RST, both ends CLOSED instantly, nothing retransmitted.

Watch these fields in the lab: tcp.flags.fin · tcp.flags.ack

FIN-WAIT-1: 'I sent my FIN and I'm waiting for it to be acknowledged.' The closer enters this immediately after sending FIN.
FIN-WAIT-2: 'My FIN was acknowledged; now I'm waiting for the peer to finish too.' Data can still legally arrive in this state — the peer's direction is still open.
CLOSE-WAIT: 'The peer is done sending; I've acknowledged that, and now my own application needs to close.' Sockets stuck here are an application bug — TCP is waiting for a close() that never comes.
LAST-ACK: 'I've sent my own FIN and I'm waiting for the final acknowledgement.' Once it arrives, the connection is gone with no waiting period.
TIME-WAITglossary: 'Everything is closed, but I'll keep this record for a while.' The closing side lingers so that stray delayed packets from this connection can't be mistaken for part of a new one, and so it can re-send the final ACK if it was lost.
Half-closeglossary: The legal state where one direction is closed and the other still carries data. This is why FIN means 'I'm finished sending' and never 'this connection is over'.

Watch these fields in the lab: tcp.flags.fin

✓ Concept check — before you open the packets

These test the idea, not the trace. You should be able to answer them from the explanation above.

Why does termination usually need four packets when the handshake needs only three?

A server has thousands of sockets sitting in CLOSE-WAIT. What does that tell you?

Now that you understand the concept, observe how it appears in the packet exchange.

The lab runs a real simulated capture — pause, step, click any packet, and inspect every byte.