TCP协议规定2MSL等待的原因

转载：https://blog.csdn.net/marywang56/article/details/76144275

TCP协议规定主动关闭一方，进入FIN_WAIT_2->TIME_WAIT，必须等待2MSL（MSL为最大报文段生存时间）时间然后才进入CLOSED，删除TCP控制块。在2MSL等待时间内迟到的报文段将被抛弃。

原因有二：

保证TCP协议的全双工连接能够可靠关闭
如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

保证这次连接的重复数据段从网络中消失
如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2MSL，这样可以保证本次连接的所有数据都从网络中消失。
一般来说客户端主动关闭连接又立刻建立连接，2MSL时间内之前连接的端口号不能使用，即使调用bind函数也将返回-1（绑定失败），内核将自动分配一个新的端口号使用。所以如果服务器主动关闭连接，而服务器端口一般是固定的，会出现数据包混淆的问题，因此TCP规定主动关闭连接的一方需要等待2MSL。

可参考该文。

文章参考：

TCP四次分手中，主动关闭方最后为什么要等待2MSL之后才关闭连接？ - 知乎 来源：知乎，作者：Zeson

连接双方任何一方调用close()后，连接的两个传输方向都关闭，不能再发送数据了。如果一方调用shutdown()则连接处于半关闭状态，仍可接收对方发来的数据。

如果出现半关闭，例如客户->服务器方向关闭。则服务器还可以发，客户端还可以收。

协议规定主动关闭一方，进入FIN_WAIT_2->TIME_WAIT，必须等待2MSL（MSL为最大报文段生存时间，LWIP为1分钟，windows为2分钟）时间然后才进入CLOSED，删除TCP控制块。在2MSL等待时间内迟到的报文段将被抛弃。

如果我们在客户端关闭一个连接然后又立刻建立连接（使用同一端口号），2MSL时间内之前连接的端口号不能使用，即使调用bind函数也将返回-1（绑定失败），内核将自动分配一个新的端口号使用。通常情况下这个我们并不关心，因为客户端的端口号我们并不关心，只要能用就可以。但是如果是服务器就不一样了，服务器的端口一般是固定的，客户端必须知道服务器的端口号才能建立连接，所以如果服务器端主动断开连接时，就需要注意，或者做一些处理：不让它等待2MSL后才可以使用，具体做法：使能SO_REUSEPORT(允许重用本地地址)，可以通过调用setsockopt函数来使能。

2MSL等待的原因：报文段有生存时间，当连接关闭时，有可能收到迟到的报文段。这时，若立马就建立新的连接（同一端口），那么新的连接就会接收迟到的报文，误以为是发给自己的。另一个原因是可靠的实现全双工连接的终止。

在FIN_WAIT_2状态我们已经发出了FIN，并且另一端也已对它进行确认。除非我们在实行半关闭，否则将等待另一端的应用层意识到它已收到一个文件结束符说明，并向我们发一个FIN来关闭另一方向的连接。只有当另一端的进程完成这个关闭，我们这端才会从FIN_WAIT_2状态进入TIME_WAIT状态。这意味着我们这端可能永远保持这个状态(FIN_WAIT_2,如果对方不发送FIN包)。另一端也将处于CLOSE_WAIT状态，并一直保持这个状态直到应用层决定进行关闭（调用close然后进入LAST_ACK）。

转载：TCP连接状态与2MSL等待时间 - 时间已静止 - 博客园