TIME_WAIT状态

前言：
在前面我们讲TCP的三次握手和四次挥手的时候，最后有一个问题就是为什么主动断开连接的一方会进入TIME_WAIT状态。三次握手和四次挥手的链接如下：
http://blog.csdn.net/payshent/article/details/73773789
这一节就主要讲讲TIME_WAIT状态。
TIME_WAIT状态是保证重新生成的socket不受到之前残留的延迟重发报文的影响，是必要的逻辑保证。
下面我们先看一下TCP的状态转移图：

什么是TIME_WAIT状态？
在客户端收到服务器的结束报文之后并没有进入CLOSED状态，而是转移到TIME_WAIT状态。在这个状态客户端连接要等到一段长为2MSL（报文段最大生存时间）的时间，才会完全关闭。MSL是TCP报文段在网络中的最大生存时间，标准文档RFC1122建议时长为2min。

TIME_WAIT状态存在的原因？
TIME_WAIT状态存在的原因有两点：

1、可靠的终止TCP的连接。
如果用来确认服务器结束的报文段（也就是最后一条报文段）丢失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态来处理重复收到结束报文段的情况（即向服务器发送确认报文段），否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误就会一直等待客户端来给它回应，这就会导致资源的浪费。
2、保证让迟来的TCP报文段有足够的时间被识别并被丢弃。
我们知道在linux系统上一个TCP端口不能被多次打开（两次以上），当一个TCP连接处于TIME_WAIT时，我们将无法立即使用该连接所占的端口来建立一个新的连接。如果不存在TIME_WAIT状态应用程序建立一个和刚关闭的连接相似的连接（相似指的是它们有同的ip和端口号），这个新的和原来相似的连接就有可能收到属于原来连接的TCP报文段，这是不应该发生的。

为什么TIME_WAIT状态的时间是2MSL？

MSL：是报文段最大生存周期，指明TCP报文在internet上的最大生存周期，每个具体的TCP的实现都必须选择一个特定的MSL值，RFC1122建议是两分钟但是BSD传统实现采用了30秒，TIME_WAIT的最大状态是2*MSL也就是1~4分钟。
如果TIME_WAIT状态保持的时间不足够长（小于2MSL），第一个连接就会正常终止。第二个拥有相同相关五元组的连接出现，第一个连接重复报文的到达就会干扰第二个连接。TCP必须防止某个连接的重复报文在连接终止后出现，所以让TIME_WAIT状态保持时间足够长（2MSL），连接相应方向上的TCP报文要么完全相应完毕，要么被丢弃，建立第二个连接的时候就不会混淆。
五元组：协议，本地地址，本地端口，远程地址，远程端口。

为什么TIME_WAIT状态还需要等2MSL后才能返回CLOSED状态？
虽然双方都同意关闭连接，而且握手的四个报文也都协调和发送完毕，按理可以直接回到CLOSED状态。但是网络是不可靠的，我们无法保证最后发的ACK报文一定会被对方收到。因此对发处于LAST_ACK状态下的socket可能会因为超时未收到ACK报文而重发FIN报文。所以TIME_WAIT状态是用来重发可能丢失的ACK报文，并保证于此。