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:
- 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.
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/
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.
