1） socket 客户端 FIN_WAIT_2，而设备端显示CloseWait
这个原因是服务器端没有及时CloseSocket；
下面讲解下socket的断开流程：
TCP报文段首部格式：
序号：本报文段所发送的数据的第一个字节的序号。
确认号ack：期待收到对方下一个报文段的第一个数据字节的序号
确认ACK：占1位，仅当ACK=1时，确认号字段才有效。ACK=0时，确认号无效
同步SYN：连接建立时用于同步序号。当SYN=1，ACK=0时表示：这是一个连接请求报文段。 若同意连接，则在响应报文段中使得SYN=1，ACK=1。因此，SYN=1表示这是一个连接请求，或连接接受报文。终止FIN：用来释放一个连接。FIN=1表示：此报文段的发送方的数据已经发送完毕，并要求释放运输连接;
还要再发送一次确认是为了，防止已失效的连接请求报文段突然又传到了B，因而产生错误。
已失效的报文段：正常情况下：A发出连接请求，但因为丢失了，故而不能收到B的确认。于是A重新发出请求，然后收到确认，建立连接，数据传输完毕后，释放连接，A发了2个，一个丢掉，一个到达，没有“已失效的报文段”，但是，某种情况下，A的第一个在某个节点滞留了，延误到达，本来这是一个早已失效的报文段，但是在A发送第二个，并且得到B的回应，建立了连接以后，这个报文段竟然到达了，于是B就认为，A又发送了一个新的请求，于是发送确认报文段，同意建立连接，假若没有三次的握手，那么这个连接就建立起来了（有一个请求和一个回应），此时，A收到B的确认，但A知道自己并没有发送建立连接的请求，因为不会理睬B的这个确认，于是呢，A也不会发送任何数据，而B呢却以为新的连接建立了起来，一直等待A发送数据给自己，此时B的资源就被白白浪费了。但是采用三次握手的话，A就不发送确认，那么B由于收不到确认，也就知道并没有要求建立连接。
TIME_WAIT 是主动关闭 TCP 连接的那一方出现的状态，系统会在 TIME_WAIT 状态下等待 2MSL（maximumsegment lifetime）后才能释放连接（端口）。
CLOSE_WAIT 是被动关闭 TCP 连接时产生的，如果收到另一端关闭连接的请求后，本地不关闭相应套接字就会导致本地套接字进入这一状态。如果存在大量的 CLOSE_WAIT，说明客户端并发量大，且服务器未能正常感知客户端的退出，也并未及时 close 这些套接字。
