time_wait状态

主动发起关闭连接的一方将出现time_wait状态

四次挥手如下所示：

主动关闭端                                                                    被动关闭端

第一次挥手--------FIN---------->主动关闭端发出FIN分节之后从established状态转为fin_wait_1状态。

第二次挥手<------ACK--------被动关闭端发送ACK之后进入close_wait状态，主动关闭端接收ACK之后从fin_wait_1状态进入fin_wait_2状态。

第三次挥手<------FIN----------被动关闭端发送FIN之后从close_wait状态转为last_ack状态，等待主动关闭端发回ACK并最终关闭全双工连接。

第四次挥手--------ACＫ------->主动关闭端接受FIN之后随即发送ACK，此时从fin_wait_2状态转为非常著名的time_wait状态，被动关闭端接受ACK之后进入close状态。

time_wait状态有2个存在理由：

（1）可靠地实现TCP全双工连接的终止。

假设第四次挥手过程中主动关闭端发送了ACK,不进入time_wait状态而直接进入close状态关闭连接，如果该ACK分节由于某种原因长时间没有到达被动关闭端，则被动关闭端的TCP定时器则出现超时（太长时间没接到ack了），会进行第三次挥手中的ＦＩＮ分节的重传，而此时主动关闭端已经进入了close状态，这个时候收到被动关闭端重传过来的ＦＩＮ分节的话，主动关闭端会回送一个ＲＳＴ分节（这个分节的回送跟主动关闭端的应用程序无关，由系统的ＴＣＰ协议栈自行进行处理），而该ＲＳＴ分节传到被动关闭端之后，会被解释为一个错误。因此主动关闭端必须维护状态信息（不能直接就进入close状态），需要进入time_wait状态，等待2ＭＳＬ的时间，以便能够有机会重传最后一个ＡＣＫ。

（2）允许老的分节在网络中消逝

假设192.168.0.2:1500端口与192.168.0.3:21号端口之间建立了ＴＣＰ连接，双方互相发送数据，由于网络不太给力，双方发送的数据在网络中到处游荡，迟迟不到达对方（但尚未超时），此时断开这一连接，并迅速重新在这同一对套接字上建立新的连接（同样的ＩＰ，同样的端口上，后一连接称为前一连接的化身），这样的话之前还在网上游荡的ＴＣＰ分节可能在新连接建立之后到达目的地，从而被误会成这些数据是新连接中的数据。ＴＣＰ协议必须阻止这一现象的发生，为做到这一点，ＴＣＰ协议规定不能向处于time_wait状态的连接发起新的化身，因此time_wait状态就用来等待旧连接的所有ＴＣＰ分节都在网络中消逝。

（对于这一规则，源于Ｂerkeley的实现会有一些特殊之处，如果新建连接的ＳＹＮ序列号大于前一化身的结束序列号，则允许启动新的化身）

参考《ＵＮＩＸ网络编程——卷1:套接字联网ＡＰＩ》37页