关于TCP状态的一些思考

TCP连接在整个生存期内，有一系列状态，这些状态是：LISTEN， SYN-SEND，SYN-RECEIVED，ESTABLISHED，FIN-WAIT-1，FIN-WAIT-2，CLOSE-WAIT，CLOSING，LAST-ACK，TIME-WAIT和CLOSED。

LISTEN： 表示等待TCP连接请求

SYN-SEND： 表示在已经发送连接请求后等待匹配的连接请求。

SYN-RECEIVED：表示在已经接收和发送连接请求后，等待一个确认连接请求ACK。

ESTABLISHED：表示连接已经建立，接收到的数据可以传递给用户。这个是数据传输阶段的正常状态。

FIN-WAIT-1：表示等待远端TCP的连接终止请求，或对先前发送的连接终止请求的确认。

FIN-WAIT-2：表示等待远端TCP的连接终止请求。

CLOSE-WAIT： 表示等待本地用户的连接终止请求。

CLOSING: 表示等待远端TCP的连接终止请求ACK。

LAST-ACK: 表示等待先前发送给远端TCP的连接终止请求的ACK(包括其连接终止请求的ACK)。

TIME-WAIT：表示等待经过足够长时间以确保远端TCP收到其连接终止请求

CLOSED： 表示连接已经断开。

关于一次正常的TCP连接与断开过程中对TCP状态的理解：

下图是通过一个完整的TCP连接与断开来更加清楚理解在这个过程中TCP连接的不同状态：

注:MSL(最大分段生存期)指明TCP报文在Internet上最长生存时间,每个具体的TCP实现都必须选择一个确定的MSL值.RFC 1122建议是2分钟,但BSD传统实现采用了30秒.TIME_WAIT 状态最大保持时间是2 * MSL,也就是1-4分钟.

为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？

虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文，并保证于此。

在看https://tools.ietf.org/html/rfc793 文档的时候，在RFC文档中关于TCP状态还有一种情况：

在TCP状态中，会存在从FIN WAIT-1 直接到CLOSING 状态，自己思考的会不会是如下图所描述的过程：

前面的TCP三次握手那里没有什么不同的，但是在断开连接的时候，server和 client同时发送了FIN消息，那么这个时候双方的状态都会变成FIN WAIT-1 状态，而当彼此收到对方的FIN消息之后，就会发送ACK， 那么这个时候又分别进入到CLOSING状态，那么这个时候会不会双方都会进入到等待2MSL 这个状态？