为何要等待2MSL？

1.假如第四次挥手失败了，因为丢失而未到达服务器会怎样呢？这样，服务器会一直收不到客户端的回应，也就无法得知客户端是否收到了即将要断开连接的请求。客户端此刻还蒙在鼓里，还在等待服务器继续发送消息。服务器不能判断客户端是否收到，本身就是一个BUG，于是才有的等待2MSL的情况。为了保证客户端最后一次挥手的报文能够到达服务器，若第4次挥手的报文段丢失了，服务器就会超时重传第3次挥手的报文段，所以客户端此时不是直接进入CLOSED，而是保持TIME_WAIT（等待2MSL就是TIME_WAIT）。当客户端再次受到服务器因为超时重传而发送的第3次挥手的请求时，客户端就会重新给服务器发送第4次挥手的报文（保证服务器能够受到客户端的回应报文）。最后，客户端、服务器才真正断开连接。说白了，等待2MSL就是为了确保服务器能够受到客户端最后的回应。
2.如果客户端直接CLOSED，然后又再次向服务器发起一个新连接，谁也不能保证新发起的连接和刚关闭的连接的端口号是不同的，有可能新、老连接的端口号就是一样的。假设新、老连接端口号一致，若老连接的一些数据仍滞留在网络中，这些滞留数据在新连接建立后才到达服务器，鉴于前后端口号一致，TCP协议就默认这些数据属于新连接，于是数据就这样乱成一锅粥了。所以TCP连接还要在TIME_WAIT状态下等待2MSL，确保所有老连接的数据都在网络中消失！

总结来说：
1.为了确保第四次挥手的ACK能被服务器接收到
2.确保所有的老链接都在网络中消失。

等待时间为什么是2MSL？

首先说明什么是MSL，MSL是Maximum Segment Lifetime的缩写，译为报文最大生存时间，也就是任何报文在网络上存活的最大时间，一旦超过该时间，报文就会被丢弃。2MSL也就是指的2倍MSL的时间。
为什么是2倍呢？
主动断开的一侧为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，会再次发送ACK
2）如果B收到自己的ACK，也不会再发任何消息，包括ACK
无论是1还是2，A都需要等待，要取这两种情况等待时间的最大值，以应对最坏的情况发生，这个最坏情况是：

去向ACK消息最大存活时间（MSL) + 来向FIN消息的最大存活时间(MSL)。

这恰恰就是2MSL( Maximum Segment Life)。

等待2MSL时间，A就可以放心地释放TCP占用的资源、端口号，此时可以使用该端口号连接任何服务器。同时也能保证网络中老的链接全部消失。