四次挥手TIME_WAIT状态存在的原因

客户端连接在收到服务器的结束报文段之后，并没有直接进入CLOSED状态，而是转移到TIME_ WAIT 状态。在这个状态，客户端连接要等待一段长为2MSL (Maximum Segment Life，报文段最大生存时间)的时间，才能完全关闭。MSL是TCP报文段在网络中的最大生存时间。
TCP状态变化图：

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

• 可靠地终止TCP连接
• 保证让迟来的TCP报文段有足够的时间被识别并丢弃。

第一个原因很好理解。假设上图中用于确认服务器结束报文段6的TCP报文段7丟失，那么服务器将重发结束报文段。因此客户端需要停留在某个状态以处理重复收到的结束报文段(即向服务器发送确认报文段)。否则，客户端将以复位报文段来回应服务器，服务器则认为这是一个错误，因为它期望的是一个像TCP报文段7那样的确认报文段。
在Linux系统上，一个TCP端口不能被同时打开多次(两次及以上)。当一个TCP连接处于TIME_WAIT 状态时，我们将无法立即使用该连接占用着的端口来建立一个新连接。反过来思考，如果不存在TIME_WAIT状态，则应用程序能够立即建立一个和刚关闭的连接相似的连接(这里说的相似，是指它们具有相同的IP地址和端口号)。这个新的、和原来相似的连接被称为原来的连接的化身，新的化身可能接收到属于原来的连接的、携带应用程序数据的TCP报文段(迟到的报文段)，这显然是不应该发生的。这就是TIME_WAIT状态存在的第二个原因。
另外，因为TCP报文段的最大生存时间是MSL，所以坚持2MSL时间的TIME_WAIT状态能够确保网络上两个传输方向上尚未被接收到的、迟到的TCP报文段都已经消失(被中转路由器丢弃)。因此，一个连接的新的化身可以在2MSL时间之后安全地建立，而绝对不会接收到属于原来连接的应用程序数据，这就是TIME_WAIT状态要持续2MSL时间的原因。
有时候我们希望避免TIME_WAIT 状态，因为当程序退出后，我们希望能够立即重启它。但由于处在TIME_WAIT状态的连接还占用着端口，程序将无法启动(直到2MSL超时时间结束)。
对客户端程序来说，我们通常不用担心上面描述的重启问题。因为客户端一般使用系统自动分配的临时端口号来建立连接，而由于随机性，临时端口号一般和程序上一次使用的端口号(还处于TIME_WAIT状态的那个连接使用的端口号)不同，所以客户端程序一般可以立即重启。除非我们强制客户端使用固定端口。
但如果是服务器主动关闭连接后异常终止，则因为它总是使用同一个知名服务端口号,所以连接的TIME_WAIT状态将导致它不能立即重启。不过，我们可以通过socket选项SO_REUSEADDR来强制进程立即使用处于TIME_WAIT状态的连接占用的端口。