连接状态

@fin_wait1 状态

四次挥手中，主动关闭方发送fin报文后，进入find_wait1状态

@close_wait

四次挥手中，表示接受到对方fin报文，并发送对方ack回复，从此进入close_wait状态，等待发送对方fin报文

这中状态在开发中容易遇见，而且是灾难性的，因为这种状态会在网络中持续2*MSL（Max Segment Lifetime，最大分段生存期，指一个 TCP 报文在 Internet 上的最长生存时间。每个具体的 TCP 协议实现都必须选择一个确定的 MSL 值，RFC 1122 建议是 2 分钟，但 BSD 传统实现采用了 30 秒，Linux 可以 cat /proc/sys/net/ipv4/tcp_fin_timeout 看到本机的这个值）导致系统资源不会被释放

一般是由于服务端发生异常，导致未向客户端回复fin报文关闭连接进入time_wait状态

@fin_wait2 状态

四次挥手中，表示发送对方fin报文，并接收到对方ack回复，进入到fin_wait2状态

@time_wait 状态

四次挥手中，表示发送对方fin报文，并且受到ack报文和fin报文后进入time_wait状态

@last_ack 状态

刚好和close_wait相反，四次挥手中，最后一次报文迟迟没有回复，客户端没有回复服务端ack确认

LAST_ACK 当被动关闭的一方在发送 FIN 报文后，等待对方的 ACK 报文的时候，就处于 LAST_ACK 状态。当收到对方的 ACK 报文后，也就可以进入到 CLOSED 可用状态了。

@closing 状态

在四次挥手中，一般不会出现closing状态，因为主动关闭方发送Fin报文后，一般会先收到ack报文，随后在收到fin报文则进入time_wait状态

但是如果双方同时发送fin报文断开连接的话，就会出现fin报文先到，而ack报文在后面，也就是导致fin_wait2的状态直接进入closing状态