2MSL即两倍的MSL，TCP的TIME_WAIT状态也称为2MSL等待状态，当TCP的一端发起主动关闭，在发出最后一个ACK包后，即第3次握手完成后发送了第四次握手的ACK包后就进入了TIME_WAIT状态，必须在此状态上停留两倍的MSL时间，等待2MSL时间主要目的是怕最后一个ACK包对方没收到，那么对方在超时后将重发第三次握手的FIN包，主动关闭端接到重发的FIN包后可以再发一个ACK应答包。在TIME_WAIT状态时两端的端口不能使用，要等到2MSL时间结束才可继续使用。当连接处于2MSL等待阶段时任何迟到的报文段都将被丢弃。
不过在实际应用中可以通过端口复用来设置不必等待2MSL时间结束再使用此端口。
SO_REUSEADDR
int flag = 1; |
setsockopt(lfd, SOL_SOCKET, SO_REUSEADDR,&flag, sizeof(flag) );
主动断开的一侧为A，被动断开的一侧为B。
第一个消息：A发FIN
第二个消息：B回复ACK
第三个消息：B发出FIN
此时此刻：B单方面认为自己与A达成了共识，即双方都同意关闭连接。此时，B能释放这个TCP连接占用的内存资源吗？不能，B一定要确保A收到自己的ACK、FIN。所以B需要静静地等待A的第四个消息的到来
第四个消息：A发出ACK，用于确认收到B的FIN当B接收到此消息，即认为双方达成了同步：双方都知道连接可以释放了，此时B可以安全地释放此TCP连接所占用的内存资源、端口号。所以被动关闭的B无需任何wait time，直接释放资源。但，A并不知道B是否接到自己的ACK，A是这么想的：1）如果B没有收到自己的ACK，会超时重传FiN那么A再次接到重传的FIN，会再次发送ACK2）如果B收到自己的ACK，也不会再发任何消息，包括ACK无论是1还是2，A都需要等待，要取这两种情况等待时间的最大值，以应对最坏的情况发生，
这个最坏情况是：去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。
这恰恰就是2MSL( Maximum Segment Life)。
等待2MSL时间，A就可以放心地释放TCP占用的资源、端口号，此时可以使用该端口号连接任何服务器。
为何一定要等2MSL？
如果不等，释放的端口可能会重连刚断开的服务器端口，这样依然存活在网络里的老的TCP报文可能与新TCP连接报文冲突，造成数据冲突，为避免此种情况，需要耐心等待网络老的TCP连接的活跃报文全部死翘翘，2MSL时间可以满足这个需求（尽管非常保守）！