四次挥手 TIME_WAIT 存在的理由

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

在四次挥手第 4 阶段，client发送的确认报文可能会丢失。
如果该ACK报文丢失，过一段时间server会重新发送FIN报文给client（ 步骤3 ）。
如果没有TIME_WAIT等待的时间(即，client收到步骤3发的FIN后，发送完ACK后就立即关闭)。
那么此时的client 已经关闭，client在收到未连接的报文后，会发送给对方一个RST报文，告诉对方出现的错误连接。
而通过RST报文来关闭TCP连接，破坏了TCP连接正常释放的流程。

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

在TCP连接关闭前，可能有部分数据包“迷路”了，在TCP连接准备关闭时，有数据还在“赶来的路上”，而我们如果直接关闭连接就会造成，“迟来的”数据包到达目的主机时连接已关闭的情况。
主机在收到未连接的TCP发送的报文时，会发送一个RST报文回去告知对方连接错误，而这种TCP关闭的方式也是破坏了TCP连接正常释放的流程。

综上，TIME_WAIT的等待时间是必要的。

有关RST报文参考：
TCP异常终止（reset报文）
RST报文详解

附 tcp状态转移图

---

以下引用自《windows 网络编程》一书：

5.1.3 TCP连接的建立与终止

为了建立一条TCP连接，需要以下三个基本步骤：
1）请求端（通常称为客户）发送一个SYN报文段指明客户打算连接的服务器端口号，以及初始序号（Initial Sequence Number，ISN），SYN请求发送后，客户进入SYN_SENT状态。

2）服务器启动后首先进入LISTEN状态，当它收到客户发来的SYN请求后，进入SYN_RCV状态，发回包含服务器的初始序号的SYN报文段作为应答，同时将确认序号设置为客户的初始序号加1，对客户的SYN报文段进行确认。一个SYN将占用一个序号。

3）客户接收到服务器的确认报文后进入ESTABLISHED状态，表明本方连接已成功建立，客户将确认序号设置为服务器的ISN加1，对服务器的SYN报文段进行确认，当服务器接收到该确认报文后，也进入ESTABLISHED状态。

这三个报文段完成连接的建立，这个过程称为“三次握手”，如图所示。

一般由客户决定何时终止连接，因为客户进程通常由用户交互控制，比如Telnet的用户会键入quit命令来终止进程。既然一个TCP连接是全双工的（即数据在两个方向上能同时传递），那么每个方向必须单独关闭。终止一个连接要经过四次交互，当一方完成它的数据发送任务后，发送一个FIN报文段来终止这个方向的连接。当一端收到FIN，它必须通知应用层另一端已经终止了那个方向的数据传送。发送FIN通常是应用层进行关闭的结果。下图显示了终止一个连接的典型握手顺序。首先进行关闭的一方（即发送第一个FIN）将执行主动关闭，而另一方（收到这个FIN）执行被动关闭，具体步骤如下：

1）客户的应用进程主动发起关闭连接请求，它将导致TCP客户发送一个FIN报文段，用来关闭从客户到服务器的数据传送，此时客户进入FIN_WAIT_1状态。

2）当服务器收到这个FIN，它发回一个ACK，进入CLOSE_WAIT状态，确认序号为收到的序号加1。与SYN一样，一个FIN将占用一个序号。客户收到该确认后进入FIN_WAIT_2状态，表明本方连接已关闭，但仍可以接收服务器发来的数据。

3）接着服务器程序关闭本方连接，其TCP端发送一个FIN报文段，进入LAST_AC状态，当客户接收到该报文段后进入TIME_WAIT状态。

4）客户在收到服务器发来的FIN请求后，发回一个确认，并将确认序号设置为收到的序号加1。发送FIN将导致应用程序关闭它们的连接，服务器接收到该确认后，连接关闭。这些FIN的ACK是由TCP软件自动产生的。

在实际应用中，服务器也可以作为主动发起关闭连接的一方，如果交换图中的服务器和客户位置，其通信过程不变。

我们注意到在如图所示的连接关闭过程中，当四次交互完成后，客户并没有直接关闭连接，而是进入TIME_WAIT状态，且此状态会保留两个最大段生存时间（2MSL），等待2MSL时间之后，客户也关闭连接并释放它的资源。

为什么需要TIME_WAIT状态呢？设立TIME_WAIT有两个目的：

1）当由主动关闭方发送的最后的ACK丢失并导致另一方重新发送FIN时，TIME_WAIT维护连接状态。当最后的ACK发生丢失时，由于执行被动关闭的一方没有接收到最后序号的ACK，则会运行超时并重新传输FIN。假如执行主动关闭的一方不进入TIME_WAIT状态就关闭了连接，那么此时重传的FIN到达时，由于TCP已经不再有连接的信息了，所以它就用RST（重置连接）报文段应答，导致对等方进入错误状态而不是有序终止状态。由此看来，TIME_WAIT状态延长了TCP对当前连接的维护信息，对于正确处理连接的正常关闭过程中确认报文丢失是很有必要的。

2）TIME_WAIT为连接中“离群的段”提供从网络中消失的时间。IP数据包在广域网传输中不仅可能会丢失，还可能延迟。如果延迟或重传报文段在连接关闭之后到达，通常情况下，因为TCP仅仅丢弃该数据并响应RST，当该报文段到达发出延时报文段的主机时，因为该主机也没有记录该连接的任何信息，所以它也丢弃该报文段。然而如果两个相同主机之间又建立了一个具有相同端口号的新连接，那么离群的段就可能被看成是属于新连接的，如果离群的段中数据的任何序号恰好处在新连接的当前接收窗口中，数据就会被新连接接收，其结果是破坏新连接，使TCP不能保证以顺序的方式递交数据。因此TIME_WAIT状态确保了旧连接的报文段在网络上消失之前不会被重用，从而防止其在上述情况下扰乱新连接。

通常情况下，仅有主动关闭连接的一方会进入TIME_WAIT状态。RFC793中定义MSL为2分钟，在这个定义下，连接在TIME_WAIT状态下保持4分钟，而实际中，MSL的值在不同的TCP协议实现中的定义并不相同。如果连接处于TIME_WAIT状态期间有报文段到达，则重新启动一个2MSL计时器。

在客户和服务器建立连接和断开连接的交互过程中，双方端点所经历的TCP状态发生了多次转换，当发生网络环境异常时，这些状态的变迁有助于理解和解释基于流式套接字的应用程序在运行中的表现。