TCP协议：理解CLOSE_WAIT/TIME_WAIT状态

理解CLOSE_WAIT状态

概念及介绍：

客户端调用了close函数发起两次挥手，服务器接收后就会进入CLOSE_WAIT状态，客户端再接收到服务端的ACK之后则会进入到FIN_WAIT_2状态；但服务端还没有发起两次挥手，只有完成四次挥手后连接才算真正断开，此时双方才会释放对应的连接资源
如果服务器接收到两次挥手后不进行调用close，那么服务器端就会存在大量处于CLOSE_WAIT状态的连接，而每个连接都会占用服务器的资源，最终就会导致服务器可用资源越来越少

注：对于服务器上出现大量的 CLOSE_WAIT 状态, 原因就是服务器没有正确的关闭 socket, 导致四次挥手没有正确完成，这是一个 BUG，只需要加上对应的 close 即可解决问题

理解TIME_WAIT状态

概念及介绍：

客户端主动关闭连接时，发送最后一个ACK后，然后会进入TIME_WAIT状态，再停留2个MSL时间(后有MSL的解释)，进入CLOSED状态，所以我们可以粗略地理解成在断开连接后主动断开连接的那一方就会进入一个等待状态，过了一定时间后，再真正的关闭，这所谓的状态也就是TIME_WAIT状态，这其中所说的一定时间也就是2MSL（MSL：最长分节生命期maximum segment lifetime，这个状态会持续MSL时长的两倍，所以称为2MSL）

TIME_WAIT状态产生的原因：

可靠地实现TCP全双工连接的终止

假设发起主动关闭的一方（client）最后发送的ACK在网络中丢失，由于TCP协议的重传机制，执行被动关闭的一方（server）将会重发其FIN，在该FIN到达client之前，client必须维护这条连接状态，也就说这条TCP连接所对应的资源（client方的local_ip,local_port）不能被立即释放或重新分配，直到另一方重发的FIN达到之后，client重发ACK后，经过2MSL时间周期没有再收到另一方的FIN之后，说明被动关闭的一方（server）成功收到ACK，这样才能转变成CLOSED状态，正式断开双方建立的连接

如果主动关闭一方不维护这样一个TIME_WAIT状态，那么当被动关闭一方重发的FIN到达时，主动关闭一方的TCP传输层会用RST包响应对方，这会被对方认为是有错误发生，然而这事实上只是正常的关闭连接过程，并非异常

允许老的重复分节在网络中消逝

假设在12.106.32.254的1500端口和206.168.112.219的21端口之间有一个TCP连接。我们关闭这个连接，过一段时间后在相同的IP地址和端口之间建立另一个连接。后一个连接称为前一个连接的化身（incarnation），因为它们的IP地址和端口号都相同

TCP必须防止来自某个连接的老的重复分组在该连接已终止后再现，从而被误解成属于同一连接的某个新的化身。为做到这一点，TCP将不给处于TIME_WAIT状态的连接发起新的化身。所以TIME_WAIT状态的持续时间是MSL的2倍，这就足以让某个方向上的分组最多存活MSL秒即被丢弃，另一个方向上的应答最多存活MSL秒也被丢弃；此后，就可以用相同的四元组建立一条新连接而不会发生前后两次连接数据错乱的情况

注：MSL在RFC1122中规定为两分钟，但是各个操作系统的实现不同，比如在Centos7上默认配置的值是60s，可以通过cat /proc/sys/net/ipv4/tcp_fin_timeout命令来查看MSL的值