TCP connection termination (four-way handshake) in Computer Networks - Time & Space Complexity
When closing a TCP connection, the four-way handshake ensures both sides agree to end communication safely.
We want to understand how the number of steps grows as the connection closes.
Analyze the time complexity of the TCP four-way handshake termination process.
1. Host A sends FIN to Host B
2. Host B sends ACK to Host A
3. Host B sends FIN to Host A
4. Host A sends ACK to Host B
This sequence shows the four messages exchanged to close a TCP connection properly.
Look for repeated actions or message exchanges.
- Primary operation: Sending and receiving control messages (FIN and ACK packets)
- How many times: Exactly four message exchanges happen, each once per connection termination
The number of messages to close a connection stays the same no matter how long the connection was open.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 connections | 40 messages (4 per connection) |
| 100 connections | 400 messages |
| 1000 connections | 4000 messages |
Pattern observation: The total messages grow linearly with the number of connections, but each connection always uses four messages.
Time Complexity: O(1)
This means closing one TCP connection always takes a fixed number of steps, regardless of connection length.
[X] Wrong: "The termination time depends on how much data was sent during the connection."
[OK] Correct: The four-way handshake only handles closing the connection, not the data transfer, so its steps stay constant.
Understanding fixed-step processes like TCP termination helps you explain how protocols manage communication efficiently and predictably.
"What if the TCP connection used a three-way handshake to close instead of four steps? How would that affect the time complexity?"
Practice
Solution
Step 1: Understand TCP connection termination
TCP uses a four-way handshake to close connections, allowing each side to finish sending data independently.Step 2: Identify the purpose of the handshake
This process ensures no data is lost and both sides agree to close the connection properly.Final Answer:
To allow both sides to close their sending channels independently -> Option AQuick Check:
Four-way handshake = independent close [OK]
- Confusing termination with connection setup
- Thinking handshake encrypts data
- Assuming simultaneous close in TCP
Solution
Step 1: Recall TCP termination flags
The four-way handshake uses FIN and ACK flags to close the connection properly.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.Final Answer:
FIN, ACK, FIN, ACK -> Option DQuick Check:
Termination = FIN then ACK pairs [OK]
- Including SYN or RST flags in termination
- Mixing order of flags
- Assuming simultaneous FIN flags
A sends FINB replies ACKB sends FINA replies ACKWhat is the state of the connection after Host A sends the final ACK?
Solution
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.Step 2: Understand connection state after final ACK
After the last ACK, both sides have agreed to close, so the connection is fully closed.Final Answer:
Connection is fully closed -> Option AQuick Check:
Final ACK means full close [OK]
- Thinking connection stays half-open after final ACK
- Confusing reset with normal close
- Assuming data can still be sent
Host A sends FINHost B sends FINHost A sends ACKWhich step is missing or incorrect in this sequence?
Solution
Step 1: Review correct four-way handshake order
After Host A sends FIN, Host B must acknowledge (ACK) before sending its own FIN.Step 2: Identify missing ACK
The sequence shows Host B sending FIN without ACKing Host A's FIN first, which is incorrect.Final Answer:
Host B should send ACK before sending FIN -> Option CQuick Check:
ACK always precedes FIN from other side [OK]
- Skipping ACK step
- Confusing SYN with FIN
- Thinking RST is normal close
Solution
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.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.Final Answer:
The connection will close cleanly without issues -> Option BQuick Check:
Stack handles states after socket close [OK]
- Thinking immediate close causes reset by peer
- Expecting retransmissions without ACK loss
- Confusing socket close with immediate connection abort
Ready to prove it?
Pass the test and this pattern moves unknown
