Why TCP connection termination (four-way handshake) in Computer Networks? - Purpose & Use Cases

The Big Idea

What if ending a simple connection was as tricky as saying goodbye without hanging up the phone?

The Scenario

Imagine you are trying to end a phone call with a friend, but both of you keep talking at the same time without agreeing to hang up. This confusion makes it hard to know when the call really ends.

The Problem

If computers tried to close a connection without a clear process, data could be lost or connections might stay open forever, wasting resources and causing errors in communication.

The Solution

The TCP four-way handshake is like a polite conversation where both sides say goodbye clearly and confirm the call is over, ensuring no messages are lost and the connection closes cleanly.

Before vs After

✗ Before

send FIN; close connection immediately

✓ After

send FIN; wait for ACK; receive FIN; send ACK; close connection

What It Enables

This process ensures reliable and orderly ending of communication, preventing data loss and freeing network resources properly.

Real Life Example

When you finish browsing a website, your device and the server use this handshake to close the connection safely, so your next visit starts fresh without leftover data.

Key Takeaways

Manual connection closing can cause confusion and data loss.

The four-way handshake coordinates a clean, reliable termination.

This keeps networks efficient and communication trustworthy.

Practice

1. What is the main purpose of the TCP four-way handshake during connection termination?

easy

A. To allow both sides to close their sending channels independently

B. To establish a new connection between two hosts

C. To encrypt data before transmission

D. To synchronize sequence numbers at the start of communication

Solution

1. Step 1: Understand TCP connection termination

   TCP uses a four-way handshake to close connections, allowing each side to finish sending data independently.

2. Step 2: Identify the purpose of the handshake

   This process ensures no data is lost and both sides agree to close the connection properly.

3. Final Answer:

   To allow both sides to close their sending channels independently -> Option A

4. Quick Check:

   Four-way handshake = independent close [OK]

Hint: Four steps mean both sides close separately [OK]

Common Mistakes:

• Confusing termination with connection setup
• Thinking handshake encrypts data
• Assuming simultaneous close in TCP

2. Which of the following is the correct sequence of TCP flags used in the four-way handshake for connection termination?

easy

A. FIN, SYN, ACK, FIN

B. SYN, ACK, FIN, RST

C. ACK, SYN, FIN, ACK

D. FIN, ACK, FIN, ACK

Solution

1. Step 1: Recall TCP termination flags

   The four-way handshake uses FIN and ACK flags to close the connection properly.

2. Step 2: Identify correct flag order

   The sequence is FIN from one side, ACK from the other, then FIN from the second side, and finally ACK from the first side.

3. Final Answer:

   FIN, ACK, FIN, ACK -> Option D

4. Quick Check:

   Termination = FIN then ACK pairs [OK]

Hint: Termination uses FIN and ACK flags in pairs [OK]

Common Mistakes:

• Including SYN or RST flags in termination
• Mixing order of flags
• Assuming simultaneous FIN flags

3. Consider this sequence of TCP flags exchanged between Host A and Host B during connection termination:
A sends FIN
B replies ACK
B sends FIN
A replies ACK
What is the state of the connection after Host A sends the final ACK?

medium

A. Connection is fully closed

B. Connection is half-closed, waiting for more data

C. Connection is still established

D. Connection is reset abruptly

Solution

1. Step 1: Analyze the four-way handshake steps

   Host A sends FIN, B acknowledges, B sends FIN, and A acknowledges. This completes the four steps.

2. Step 2: Understand connection state after final ACK

   After the last ACK, both sides have agreed to close, so the connection is fully closed.

3. Final Answer:

   Connection is fully closed -> Option A

4. Quick Check:

   Final ACK means full close [OK]

Hint: Final ACK completes termination [OK]

Common Mistakes:

• Thinking connection stays half-open after final ACK
• Confusing reset with normal close
• Assuming data can still be sent

4. A TCP connection termination sequence is observed as:
Host A sends FIN
Host B sends FIN
Host A sends ACK
Which step is missing or incorrect in this sequence?

medium

A. Host B should send RST instead of FIN

B. Host A should send SYN before FIN

C. Host B should send ACK before sending FIN

D. Host A should send FIN twice

Solution

1. Step 1: Review correct four-way handshake order

   After Host A sends FIN, Host B must acknowledge (ACK) before sending its own FIN.

2. Step 2: Identify missing ACK

   The sequence shows Host B sending FIN without ACKing Host A's FIN first, which is incorrect.

3. Final Answer:

   Host B should send ACK before sending FIN -> Option C

4. Quick Check:

   ACK always precedes FIN from other side [OK]

Hint: ACK must come before FIN from other side [OK]

Common Mistakes:

• Skipping ACK step
• Confusing SYN with FIN
• Thinking RST is normal close

5. During a TCP connection termination, if Host A sends a FIN and immediately closes its socket without waiting for the ACK from Host B, what is the likely outcome?

hard

A. Host B will retransmit FIN until it receives ACK, causing delays

B. The connection will close cleanly without issues

C. Host A will receive data after closing the socket

D. Host B will reset the connection immediately

Solution

1. Step 1: Understand proper termination behavior

   In TCP, after sending FIN, the application closes the socket, but the TCP stack manages states like FIN_WAIT_1, FIN_WAIT_2, and TIME_WAIT independently.

2. Step 2: Analyze consequence of immediate close

   The stack processes incoming ACK and FIN from Host B, sending responses as needed, so the connection closes cleanly without issues.

3. Final Answer:

   The connection will close cleanly without issues -> Option B

4. Quick Check:

   Stack handles states after socket close [OK]

Hint: TCP stack handles states post-socket close [OK]

Common Mistakes:

• Thinking immediate close causes reset by peer
• Expecting retransmissions without ACK loss
• Confusing socket close with immediate connection abort