先上转换图：
重点研究TIME_WAIT状态，根据UNIX网络编程中的思路，TIME_WAIT状态有两个存在的理由：
理由1、客户端执行主动关闭，假设最终的ACK丢失，服务器将重新发送它的最后那个FIN，因此客户端必须维护状态信息，以允许它重新发送最终那个ACK，要是客户端 不维护状态信息，它将响应一个RST分节，该分节将被服务器解释成一个错误，如果TCP打算执行所有必要的工作以彻底终止连接上两个方向的数据流，那么它必须正确处理连接终止序列4个分节中任何一个分节丢失的情况。为什么执行主动关闭的那一端是处于TIME_WAIT状态的那一端：因为可能不得不重传最终那个ACK的就是那一端。
看了理由1的解释，想必还是有点蒙，根据个人的理解，给出一个通俗的解释：
MSL是最长分节生命期，也即一个分节在网络中传输，如果经过MSL时间还没有到达目的地，则这个分节自动失效。TIME_WAIT状态的超时时间是2MSL，就是如果TCP处于TIME_WAIT状态时，经过2MSL的时间后悔自动转到CLOSED状态。如果在TIME_WAIT状态时收到服务器发来的FIN，则会回复一个ACK。从图中可以看到，正常情况下，是从FIN_WAIT_2状态回复ACK然后转到TIME_WAIT状态的。而在TIME_WAIT状态恢复ACK则会转到CLOSED状态，不用等到超时时间到。
要是客户端不维护状态信息，也即没有TIME_WAIT状态，则客户端在FIN_WAIT_2状态回复ACK后直接回到CLOSED状态，来看看这样会存在什么问题，如果客户端在FIN_WAIT_2状态回复的这个ACK丢失了，而服务器由于超时没有接到ACK则会再一次发送FIN给客户端，这时的客户端是处于CLOSED状态的，当它接到FIN后会回复一个RST，服务器如果接到了这个RST则会解释成一个错误，这明显不是我们期望的。因此，客户端维护一个TIME_WAIT状态也就是有必要的了，在TIME_WAIT状态时收到FIN并回复ACK，然后回到CLOSED状态，这样客户端就功成身退了。读到这里，可能有读者会迷惑，如果在TIME_WAIT状态回复的这个ACK再次丢失呢，那处于CLOSED状态的客户端不还是会再次接收到服务端发来的FIN，然后回复RST吗？我想说不会的，这个ACK即使再丢失，服务端也不会回复FIN的，要不然，在网络不稳定的情况下，客户端和服务器会陷入死循环，永远无法走出困境。看下面的分析。