I found that the reason the active closer enters TIME WAIT is to make sure that the final ACK is not lost. But how does it know if the final ACK is lost? Will the passive closer resend the FIN and then the active closer knows the ACK was lost? Here is a picture of the TCP FSM.



Will the passive closer resend the FIN and then the active closer knows the ACK was lost?

Yes. Quoting from TCP/IP Illustrated Volume 1, in the TCP Connection Management section:

  1. To complete the close, the final segment contains an ACK for the last FIN. Note that if a FIN is lost, it is retransmitted until an ACK for it is received.

There is a timeout. When in LAST_ACK, the passive closer will resend FIN when there is a timeout, assuming that it was lost. If it was indeed lost, then the active closer will eventually receive the retransmitted FIN and enter TIME_WAIT. If the FIN was not lost but the final ACK was lost, then the active closer is in TIME_WAIT and receives FIN again. When this happens - receiving a FIN in TIME_WAIT - the ACK is retransmitted.

The timeout value in TIME_WAIT is NOT used for retransmission purposes. When there is a timeout in TIME_WAIT, it is assumed that the final ACK was successfully delivered because the passive closer didn't retransmit FIN packets. So, the timeout in TIME_WAIT is just an amount of time after which we can safely assume that if the other end didn't send anything, then it's because he received the final ACK and closed the connection.

| improve this answer | |

But how does it know if the final ACK is lost?

Because it didn't receive it within the timeout period. I know that's a "duh" answer, but that's exactly why these states and timeouts exist.

Will the passive closer resend the FIN

No. Not unless further packets arrive for that stream, and that would result in "RST" (reset) being sent.

The whole process is complicated state machine to execute an orderly shutdown despite the possibility of network failures. Networks break, links experience errors, links become saturated and have to drop packets, devices fail, etc. As an exercise, run the state tree for an active connection when one of the endpoints just disappears (eg. power failure.)

TL;DR That state tree is designed to handle every possible failure mode.

| improve this answer | |
  • Thanks, but I'm still confused about the first part. I meant how does the active closer know the ACK was not received by the passive closer? When the passive closer receives the ACK, it just tears down its side of the connection, and if it doesn't receive the ACK, it just stays in LAST ACK, so how does the active closer know if the ACK was received? – czhao Jul 1 '15 at 0:44
  • because there are timers attached to every state. – Ricky Beam Jul 1 '15 at 0:56
  • Sorry I'm not understanding. How do these timers tell the active closer that the passive closer did not receive the final ACK? i.e. how does the active closer know if it has to resend the final ACK? – czhao Jul 1 '15 at 1:56

The purpose of TIME_WAIT is to allow the networking to distinguish packets that arrive as belong to the 'old, existing' connection from a new one. The recommendation is to set the TIME_WAIT timer to twice the Maximum Segment Lifetime (MSL), on my system the MSL is 1 minute, so connections linger in the TIME_WAIT state for 2 minutes.

After this amount of time any packets that arrive are no longer associated with the old connection.

TIME_WAIT is not directly waited to sending ACK packets; that is driven by the CLOSE_WAIT and FIN_WAIT states. When you get to TIME_WAIT state the socket is already closed.

References: http://www.tcpipguide.com/free/t_TCPConnectionTermination-3.htm https://en.wikipedia.org/wiki/Maximum_segment_lifetime http://www.lognormal.com/blog/2012/09/27/linux-tcpip-tuning/

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.