What is the TCP FIN Handshake (Connection Teardown)?
Learn the TCP FIN handshake — the four-step teardown with FIN, ACK, CLOSE_WAIT, and TIME_WAIT — versus an abrupt RST close.
Expected Interview Answer
The TCP FIN handshake is the four-step process used to gracefully close a connection: each side independently sends a FIN to signal it has no more data, and the other side ACKs it, so the connection can be fully torn down without losing in-flight data.
Because TCP connections are full-duplex, closing one is a two-sided affair: the side initiating close sends a FIN and moves to FIN_WAIT_1, the peer ACKs it and moves to CLOSE_WAIT (it can still send remaining data), and once that peer is done it sends its own FIN, which the original initiator ACKs, moving to TIME_WAIT. Because each direction closes independently, this is often called a four-way close, though the middle ACK and FIN can sometimes combine into one segment. The side that sends the final ACK enters TIME_WAIT for typically 2×MSL (maximum segment lifetime) before fully releasing the connection, which prevents delayed duplicate segments from a prior connection being misinterpreted by a new one reusing the same port pair. This is distinct from an abrupt RST, which tears down a connection immediately without this graceful exchange, discarding any unacknowledged data.
- Allows each direction of a full-duplex connection to close independently
- Ensures in-flight data is not lost during teardown
- TIME_WAIT prevents stale segments from corrupting a reused connection
- Distinguishes graceful close from an abrupt RST reset
AI Mentor Explanation
The FIN handshake is like both team captains formally agreeing to end play: one captain signals “we are done batting” (FIN), the umpire confirms it but the field is still active for the other side to finish their innings (ACK, CLOSE_WAIT), and only when the second captain also signals “we are done too” (FIN) and the umpire confirms that (ACK) is the match officially closed. Each side ends its own innings independently rather than both stopping at once. This two-sided, four-step confirmation is exactly how TCP tears down a full-duplex connection.
Step-by-Step Explanation
Step 1
Initiator sends FIN
The side closing the connection sends a FIN segment and enters FIN_WAIT_1.
Step 2
Peer ACKs and may keep sending
The peer ACKs the FIN, enters CLOSE_WAIT, and can still send any remaining data.
Step 3
Peer sends its own FIN
Once the peer has no more data, it sends its own FIN and enters LAST_ACK.
Step 4
Initiator ACKs and enters TIME_WAIT
The initiator ACKs the peer's FIN, entering TIME_WAIT for 2xMSL before fully closing.
What Interviewer Expects
- Explains each direction closes independently (four-step exchange)
- Names the states: FIN_WAIT_1, CLOSE_WAIT, LAST_ACK, TIME_WAIT
- Explains the purpose of TIME_WAIT (2xMSL, stale segment protection)
- Distinguishes graceful FIN close from an abrupt RST
Common Mistakes
- Calling it a three-way handshake like connection setup
- Not knowing why TIME_WAIT exists or how long it lasts
- Confusing FIN-based close with RST-based abrupt termination
- Assuming both sides must send FIN simultaneously
Best Answer (HR Friendly)
“The TCP FIN handshake is how two computers politely say goodbye instead of just hanging up. Each side says "I am done sending" separately, and the other confirms, so both directions of the conversation get to wrap up cleanly without losing any last messages. There is even a short waiting period afterward to make sure no old, delayed data confuses a future connection.”
Code Example
# Capture FIN and ACK flags during connection close
sudo tcpdump -n 'tcp[tcpflags] & (tcp-fin|tcp-ack) != 0' -i any host example.com
# Typical output for a graceful close:
# 10.0.0.5 > 93.184.216.34: Flags [F.], seq 1500 (FIN, ACK)
# 93.184.216.34 > 10.0.0.5: Flags [.], ack 1501 (ACK)
# 93.184.216.34 > 10.0.0.5: Flags [F.], seq 6000 (FIN, ACK)
# 10.0.0.5 > 93.184.216.34: Flags [.], ack 6001 (ACK) # enters TIME_WAITFollow-up Questions
- Why does TIME_WAIT last roughly 2xMSL and why does it matter for busy servers?
- How does an RST-based close differ from a FIN-based close?
- What is a half-closed connection?
- How can too many TIME_WAIT sockets cause port exhaustion on a busy server?
MCQ Practice
1. How many segments are exchanged in a full FIN-based TCP teardown?
Each side sends its own FIN and receives its own ACK, totaling four segments (sometimes combined).
2. What state does the side sending the final ACK enter?
The side that sends the final ACK enters TIME_WAIT for roughly 2xMSL before releasing the connection.
3. How does an RST differ from a FIN-based close?
RST immediately aborts the connection, discarding unacknowledged data, unlike the graceful FIN sequence.
Flash Cards
What is the FIN handshake? — The four-step process where each side of a TCP connection independently sends FIN and receives ACK to close gracefully.
Why four steps, not three? — TCP is full-duplex, so each direction must close independently.
What is TIME_WAIT for? — Prevents stale duplicate segments from a closed connection confusing a new one; lasts ~2xMSL.
FIN close vs RST? — FIN is graceful and preserves in-flight data; RST aborts immediately and discards it.