CLOSE_WAIT
CLOSED
ESTABLISHED
FIN_WAIT_1
FIN_WAIT_2
LAST_ACK
LISTEN
SYN_RECEIVED
SYN_SEND
TIMED_WAIT
我觉得客户端和服务端的状态要分开来看，不然盯着这个图，一直没法很清晰的分析它
服务端：
-本来没有tcp毛事，CLOSED状态
-开始监听后变成LISTEN状态
客户端：
-本来没有tcp毛事，CLOSED状态
-想建立连接给服务端发送SYN信号，请求建立连接后变成SYN_SEND 代表我客户端发送SYN了昂
服务端：
服务端收到这个SYN也不能置之不理，把自己的状态改成SYN_RECV代表我服务端收到SYN了昂
同时服务端需要回应一个ACK SYN
客户端：
客户端收到服务端的ACK就知道这个服务端对头~，很满意然后把自己变成ESTABLISHED已经建立连接状态，并且回给服务端一个ACK
服务端：服务端看到客户端回应了自己的ACK ，也建立了连接，将自己的状态改成ESTABLISHED
四次挥手过程
客户端和服务端本来互相收发消息，客户端的状态为ESATABLISHED 服务端的状态也为ESATABLISHED
客户端说我要关闭这个连接（主动），给服务端发送了FIN，然后自己的状态为FIN_WAIT1，这个wait是在等待服务端的ACK
服务端收到这个FIN知道自己要被关闭了，返回一个ACK “老子知道了” 进入CLOSE_WAIT，这个wai是在等待自己将剩余消息全部发送给客户端后主动发起的一个close
客户端收到ACK后状态进入FIN_WAIT2，这个wait在等待服务端的主动关闭
好服务端就给你来个主动关闭FIN，然后自己的状态为LAST_ACK等待最后一个ack的到来
客户端收到这个FIN主动关闭连接后给服务端发送一个ACK表示“收到你的关闭消息了”，将自己的状态改成TIME_WAIT,这个wait顾名思义就是在等待时间，多少时间2个MSL的时间
2个MSL的时间后客户端将自己的状态改成CLOSED代表这个tcp连接关闭了
服务端收到这个ACK后也CLOSED关闭了连接
这里有几个问题：
1.为什么一定要TIME_WAIT:
如果客户端发送完最后一个ACK后就关闭了连接，服务端收到这个ACK也关闭了连接，本身是 没有毛病
但是！如果网络不好，服务端没有收到这个ACK，就会再次发送FIN，而这时客户端已经关闭了连接，怎么回应嘛！ 所以此时客户端会恢复一个RST给客户端，代表老子不懂你这个FIN，并且要求你关闭你的连接
并且如果没有TIME_WAIT客户端再次发起连接后可能受到这个FIN，会影响到这次的连接
官方说法就是这时候其实连接已经关闭，需要一个TIME—WAIT来将这个连接与下一个连接隔开，避免下一个连接再受到这个连接的重传信号
2.客户端为什么会堆积FIN_WAIT2:
如果你通过netstat看到客户端堆积了大量的FIN_WAIT2，原因有两个
1.服务端无法发起主动关闭FIN信号，导致客户端收不到FIN将状态切换到TIME_WAIT
2.服务单在CLOSE_WAIT状态时死掉了，无法发送FIN