该图主要是为了更清楚地看到TCP连接的各状态的关系
这个还是在理解了3次握手和4次握手的基础上，对照任何一张图理解都比较深的好。
整个图主要分为三个部分。
客户端状态变化服务器侧的状态变化的各种意外的事态1、客户端的状态变化
我们讲这个图从ESTABLISHED分为上下两个部分
上面两个是TCP握手三次的前两次
第一次握手时，客户端首先主动向服务器发送SYN请求连接。 状态变为同步发送
在第二次握手中，客户端接收来自服务器的SYN ACK。 此时，客户端已确认自己可以发送或接收消息，因此处于ESTABLISHED状态，可以进行数据传输
(虽然还没有第三次握手，整个连接都不完整，但是对客户端来说已经很好了。 中途是数据交换的过程，接下来是第四次握手的过程)
因为客户端第一次挥手要关闭连接，所以发送FIN，状态变为FIN-WAIT-1
第二次挥手，客户端从服务器收到ACK，状态变为等待2
第三次和第四次挥手时，客户端再次从服务器收到FIN信息，自发发送ACK表示确认，状态为TIME-WAIT状态
2经过MSL事件后，关机，进入开始的CLOSED状态2，服务器侧的状态发生变化
我们讲这个图从ESTABLISHED分为上下两个部分
上面两个是TCP的三次握手
首先，第一个LISTEN状态在服务打开时处于侦听状态。
在第一次握手和第二次握手中，服务器从客户端接收SYN并将其发送回SYN ACK。 此时，服务器已具有接收信息的能力，将被证明处于SYN-RCVD状态
在第三次握手中，服务器再次接收到来自客户端的ACK。 此时，服务器端也确认了自己有发送和接收消息的能力，因此处于ESTABLISHED状态，可以进行数据传输
[此时3次握手成功]中间是数据的交换过程，接下来是4次握手
第一招和第二招在服务器端接收客户端发送的FIN，首先发送ACK。 但是，可能还没有收到消息，需要等一会儿。 状态变为CLOSE-WAIT
等到第三次挥手接收完毕后，服务器再次向客户端发送发送的FIN，此时客户端再次发送数据时，仍然需要接收，因此还没有关机，状态为last-last
第四次挥手，服务器端再次收到ACK并表示确认，表示客户端已关闭，自己也已关闭。 进入了状态开始的CLOSED状态3，发生了各种不可预测的事态
我们分部分看这种错误可能出现的原因：
最上面的监听器
在服务器侦听端口时，此时存在某些资源加载问题，http://www.Sina.com/http://www.Sina.com /
接收RST，从握手3次的前2次开始再次进入监听状态
RST表示重置，如果RST=1，则表示TCP连接出现严重错误，必须释放连接，然后重新建议运输连接。 从监听器
服务器也可能通过SYN-SENT-SYN-RCVD打开连接
如果服务器和客户端接收到SYN_SENT状态的SYN数据报，则必须发送SYN的ACK数据报，将自己的状态调整为SYN接收状态，准备进入ESTABLISHED旁边的SYN-SENT-CLOSED
长时间无法连接，发送超时，很自然地关闭了以下SYN-RCVD-FIN-WAIT-1
这里表示可以直接跳到FIN_WAIT_1状态等待关闭，而不是ESTABLISHED状态。服务没开启
最先等待，最先等待
表示直接4次握手改为3次。 也就是说，发送的数据全部接收完毕，可以直接从FIN-WAIT-1-CLOSING关闭
收到了FIN，但没有收到确认，所以变成http://www.Sina.com/closing-time-wait
接受ACK的确认后，关闭连接是TCP状态的连接图的各部分的分析即原因。
你可以多次看这张图，然后分成三个部分，一个部分一个分析。