如此狗血的TCP close_wait

大家好，我是「****」，今天我们来聊聊最近遇到的线上出现大量close_wait导致服务不可用的问题。

***************
********************************

一、问题

服务A调用服务B，在服务A的机器上出现了大量的close_wait状态的TCP连接。

二、closed_wait

根据TCP四次挥手，理论上close_wait是一个非常短暂的状态，对应到下图：当服务端接收到客户端的FIN并且回复ACK后服务端就会进入close_wait。然后该服务端继续发送FIN包后就会继续进入后续的流程，最终会正常关闭TCP连接。

如果服务端出现了大量的close_wait那就证明没有进行正常的TCP关闭，也就是服务端最终没有调用close或者shutdown，导致最后一个FIN没有发出去。

IP异常

通过排查发现服务A处于closed_wait状态的对应的服务B的IP 都已经不在对方的服务列表中了。

同时同事反馈前天进行了一次压测，触发了下游的自动扩缩容。拿着这些IP跟运维确定，发现的确是前天扩容后又缩容了的IP。

三、分析

出现大量closed_wait的条件：

大量的短TCP链接
未正确关闭TCP(close或者shutdown)

前天压测满足了条件一，那就只剩下条件二了。

由于服务使用了连接池，猜测是不是这里导致的问题。连接池大致逻辑如下：

type ConnPool struct{
    poolName string
    connsMap map[string][]*net.Conn //key是对端ip+port,value是连接池列表
}

func (cli *TcpClient) doSend(ctx context.Context,sendByte []byte)([]byte,error){
    pool := getPool(TCP_POOL_NAME)

    //根据IP,PORT 分配conn ip port从服务注册中心获取
    conn := pool.Alloc(cli.ip,cli.port)

    //放回连接池
    defer pool.Put(conn)

    conn.Write()

    conn.Read()

    return 
}

发现该连接池的管理比较坑，使用被调用方的ip+port作为key进行存储。如果对方的服务下线了，那么从服务注册中心就再也无法获取该ip了，其对应的TCP连接就再也无法释放，并且未对连接做探活处理，从而导致TCP状态会永远停留在closed_wait状态。