关于Socket通讯中的Close_wait状态
文/转 编辑
编者按：使用Socket通讯，有时我们查看端口状态的时候，经常会发现Socket处于close_wait状态，从而影响系统性能，此文或许会给你一些答案。
最近遇到的一个关于socket.close的问题,在某个应用服务器出现的状况(执行netstat -np | grep tcp):
tcp 0
0 10.224.122.16:50158 10.224.112.58:8788
CLOSE_WAIT
tcp 0
0 10.224.122.16:37655 10.224.112.58:8788
CLOSE_WAIT
tcp 1
0 127.0.0.1:32713
127.0.0.1:8080 CLOSE_WAIT
tcp 38 0
10.224.122.16:34538 10.224.125.42:443
CLOSE_WAIT
tcp 38 0
10.224.122.16:33394 10.224.125.42:443
CLOSE_WAIT
tcp 1
0 10.224.122.16:18882 10.224.125.10:80
CLOSE_WAIT
tcp 1
0 10.224.122.16:18637 10.224.125.10:80
CLOSE_WAIT
tcp 1
0 10.224.122.16:19655 10.224.125.12:80
CLOSE_WAIT
........................................
总共出现了200个CLOSE_WAIT的socket.而且这些socket长时间得不到释放.下面我们来看看为什么会出现这种大量socket的CLOSE_WAIT情况
首先我们要搞清楚的是,这个socket是谁发起的,我们可以看到122.16这台机器开了很多端口,而且端口号都很大,125.12
或者125.10上的端口都是很常见服务器端口,所以122.16上这么多CLOSE_WAIT
的socket是由122.16开启的,换句话说这台机器是传统的客户端,它会主动的请求其他机器的服务端口.
要搞清楚为什么会出现CLOSE_WAIT,那么首先我们必须要清楚CLOSE_WAIT的机制和原理.
假设我们有一个client,
一个server.
当client主动发起一个socket.close()这个时候对应TCP来说,会发生什么事情呢?如下图所示.
client首先发送一个FIN信号给server, 这个时候client变成了FIN_WAIT_1的状态, server端收到FIN之后,返回ACK,然后server端的状态变成了CLOSE_WAIT.
接着server端需要发送一个FIN给client,然后server端的状态变成了LAST_ACK,接着client返回一个ACK,然后server端的socket就被成功的关闭了.
从这里可以看到,如果由客户端主动关闭一链接,那么客户端是不会出现CLOSE_WAIT状态的.客户端主动关闭链接,那么Server端将会出现CLOSE_WAIT的状态.
而我们的服务器上,是客户端socket出现了CLOSE_WAIT,由此可见这个是由于server主动关闭了server上的socket.
那么当server主动发起一个socket.close(),这个时候又发生了一些什么事情呢.
从图中我们可以看到,如果是server主动关闭链接,那么Client则有可能进入CLOSE_WAIT,如果Client不发送FIN包,那么client就一直会处在CLOSE_WAIT状态(后面我们可以看到有参数可以调整这个时间).
那么现在我们要搞清楚的是,在第二中场景中,为什么Client不发送FIN包给server.要搞清楚这个问题,我们首先要搞清楚server是怎么发FIN包给client的,其实server就是调用了
socket.close方法而已,也就是说如果要client发送FIN包,那么client就必须调用socket.close,否则就client就一直会处在CLOSE_WAIT。