close wait状态_失眠是什么原因引起的

分类： C/C++

这个问题之前没有怎么留意过，是最近在面试过程中遇到的一个问题，面了两家公司，两家公司竟然都面到到了这个问题，不得不使我开始关注这个问题。说起CLOSE_WAIT状态，如果不知道的话，还是先瞧一下TCP的状态转移图吧。

关闭socket分为主动关闭（Active closure）和被动关闭（Passive closure）两种情况。前者是指有本地主机主动发起的关闭；而后者则是指本地主机检测到远程主机发起关闭之后，作出回应，从而关闭整个连接。将关闭部分的状态转移摘出来，就得到了下图：

产生原因
通过图上，我们来分析，什么情况下，连接处于CLOSE_WAIT状态呢？
在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。
通常来讲，CLOSE_WAIT状态的持续时间应该很短，正如SYN_RCVD状态。但是在一些特殊情况下，就会出现连接长时间处于CLOSE_WAIT状态的情况。

出现大量close_wait的现象，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。

参考资料4中描述，通过发送SYN-FIN报文来达到产生CLOSE_WAIT状态连接，没有进行具体实验。不过个人认为协议栈会丢弃这种非法报文，感兴趣的同学可以测试一下，然后把结果告诉我;-)

为了更加清楚的说明这个问题，我们写一个测试程序，注意这个测试程序是有缺陷的。
只要我们构造一种情况，使得对方关闭了socket，我们还在read，或者是直接不关闭socket就会构造这样的情况。
server.c:

client.c:

结果如下：

解决方法
基本的思想就是要检测出对方已经关闭的socket，然后关闭它。

1.代码需要判断socket，一旦read返回0，断开连接，read返回负，检查一下errno，如果不是AGAIN，也断开连接。(注:在UNP 7.5节的图7.6中，可以看到使用select能够检测出对方发送了FIN，再根据这条规则就可以处理CLOSE_WAIT的连接)
2.给每一个socket设置一个时间戳last_update，每接收或者是发送成功数据，就用当前时间更新这个时间戳。定期检查所有的时间戳，如果时间戳与当前时间差值超过一定的阈值，就关闭这个socket。
3.使用一个Heart-Beat线程，定期向socket发送指定格式的心跳数据包，如果接收到对方的RST报文，说明对方已经关闭了socket，那么我们也关闭这个socket。
4.设置SO_KEEPALIVE选项，并修改内核参数

前提是启用socket的KEEPALIVE机制：
//启用socket连接的KEEPALIVE
int iKeepAlive = 1;
setsockopt(s, SOL_SOCKET, SO_KEEPALIVE, (void *)&iKeepAlive, sizeof(iKeepAlive));

tcp_keepalive_intvl (integer; default: 75; since Linux 2.4)
       The number of seconds between TCP keep-alive probes.

tcp_keepalive_probes (integer; default: 9; since Linux 2.2)
       The  maximum  number  of  TCP  keep-alive  probes  to  send before giving up and killing the connection if no response is obtained from the other end.

tcp_keepalive_time (integer; default: 7200; since Linux 2.2)
       The number of seconds a connection needs to be idle before TCP begins sending out  keep-alive  probes.   Keep-alives  are only  sent when the SO_KEEPALIVE socket option is enabled.  The default value is 7200 seconds (2 hours).  An idle connec‐tion is terminated after approximately an additional 11 minutes (9 probes an interval of 75  seconds  apart)  when  keep-alive is enabled.

echo 120 > /proc/sys/net/ipv4/tcp_keepalive_time
echo 2 > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo 1 > /proc/sys/net/ipv4/tcp_keepalive_probes

除了修改内核参数外，可以使用setsockopt修改socket参数，参考man 7 socket。

参考：
http://blog.chinaunix.net/u/20146/showart_1217433.html
http://blog.csdn.net/eroswang/archive/2008/03/10/2162986.aspx
http://haka.sharera.com/blog/BlogTopic/32309.htm
http://learn.akae.cn/media/ch37s02.html
http://faq.csdn.net/read/208036.html
http://www.cndw.com/tech/server/2006040430203.asp
http://davidripple.bokee.com/1741575.html
http://doserver.net/post/keepalive-linux-1.php
man 7 tcp

不久前，我的Socket Client程序遇到了一个非常尴尬的错误。它本来应该在一个socket长连接上持续不断地向服务器发送数据，如果socket连接断开，那么程序会自动不断地重试建立连接。
有一天发现程序在不断尝试建立连接，但是总是失败。用netstat查看，这个程序竟然有上千个socket连接处于CLOSE_WAIT状态，以至于达到了上限，所以无法建立新的socket连接了。
为什么会这样呢？
它们为什么会都处在CLOSE_WAIT状态呢？
CLOSE_WAIT状态的生成原因
首先我们知道，如果我们的Client程序处于CLOSE_WAIT状态的话，说明套接字是被动关闭的！
因为如果是Server端主动断掉当前连接的话，那么双方关闭这个TCP连接共需要四个packet：
       Server —> FIN —> Client
       Server <— ACK <— Client
    这时候Server端处于FIN_WAIT_2状态；而我们的程序处于CLOSE_WAIT状态。
       Server <— FIN <— Client
这时Client发送FIN给Server，Client就置为LAST_ACK状态。
        Server —> ACK —> Client
Server回应了ACK，那么Client的套接字才会真正置为CLOSED状态。
 
我们的程序处于CLOSE_WAIT状态，而不是LAST_ACK状态，说明还没有发FIN给Server，那么可能是在关闭连接之前还有许多数据要发送或者其他事要做，导致没有发这个FIN packet。
 
原因知道了，那么为什么不发FIN包呢，难道会在关闭己方连接前有那么多事情要做吗？
还有一个问题，为什么有数千个连接都处于这个状态呢？难道那段时间内，服务器端总是主动拆除我们的连接吗？
 
不管怎么样，我们必须防止类似情况再度发生！
首先，我们要防止不断开辟新的端口，这可以通过设置SO_REUSEADDR套接字选项做到：
重用本地地址和端口
以前我总是一个端口不行，就换一个新的使用，所以导致让数千个端口进入CLOSE_WAIT状态。如果下次还发生这种尴尬状况，我希望加一个限定，只是当前这个端口处于CLOSE_WAIT状态！
在调用
sockConnected = socket(AF_INET, SOCK_STREAM, 0);
之后，我们要设置该套接字的选项来重用：
/// 允许重用本地地址和端口:
/// 这样的好处是，即使socket断了，调用前面的socket函数也不会占用另一个，而是始终就是一个端口
/// 这样防止socket始终连接不上，那么按照原来的做法，会不断地换端口。
int nREUSEADDR = 1;
setsockopt(sockConnected,
              SOL_SOCKET,
              SO_REUSEADDR,
              (const char*)&nREUSEADDR,
              sizeof(int));
教科书上是这么说的：这样，假如服务器关闭或者退出，造成本地地址和端口都处于TIME_WAIT状态，那么SO_REUSEADDR就显得非常有用。
也许我们无法避免被冻结在CLOSE_WAIT状态永远不出现，但起码可以保证不会占用新的端口。
其次，我们要设置SO_LINGER套接字选项：
从容关闭还是强行关闭？
LINGER是“拖延”的意思。
默认情况下(Win2k)，SO_DONTLINGER套接字选项的是1；SO_LINGER选项是，linger为{l_onoff：0，l_linger：0}。
如果在发送数据的过程中(send()没有完成，还有数据没发送)而调用了closesocket()，以前我们一般采取的措施是“从容关闭”：
因为在退出服务或者每次重新建立socket之前，我都会先调用
/// 先将双向的通讯关闭
     shutdown(sockConnected, SD_BOTH);
     /// 安全起见，每次建立Socket连接前，先把这个旧连接关闭
closesocket(sockConnected);
 
我们这次要这么做：
设置SO_LINGER为零（亦即linger结构中的l_onoff域设为非零，但l_linger为0），便不用担心closesocket调用进入“锁定”状态（等待完成），不论是否有排队数据未发送或未被确认。这种关闭方式称为“强行关闭”，因为套接字的虚电路立即被复位，尚未发出的所有数据都会丢失。在远端的recv()调用都会失败，并返回WSAECONNRESET错误。
在connect成功建立连接之后设置该选项：
linger m_sLinger;
m_sLinger.l_onoff = 1;  // (在closesocket()调用,但是还有数据没发送完毕的时候容许逗留)
m_sLinger.l_linger = 0; // (容许逗留的时间为0秒)
setsockopt(sockConnected,
         SOL_SOCKET,
         SO_LINGER,
         (const char*)&m_sLinger,
         sizeof(linger));
 
总结
也许我们避免不了CLOSE_WAIT状态冻结的再次出现，但我们会使影响降到最小，希望那个重用套接字选项能够使得下一次重新建立连接时可以把CLOSE_WAIT状态踢掉。
Feedback
# 回复：[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:41 PM yun.zheng 
回复人： elssann(臭屁虫和他的开心果) ( ) 信誉：51 2005-01-30 14:00:00 得分: 0

我的意思是：当一方关闭连接后，另外一方没有检测到，就导致了CLOSE_WAIT的出现，上次我的一个朋友也是这样，他写了一个客户端和 APACHE连接，当APACHE把连接断掉后，他没检测到，出现了CLOSE_WAIT，后来我叫他检测了这个地方，他添加了调用 closesocket的代码后，这个问题就消除了。 
如果你在关闭连接前还是出现CLOSE_WAIT,建议你取消shutdown的调用，直接两边closesocket试试。

另外一个问题:
比如这样的一个例子： 
当客户端登录上服务器后，发送身份验证的请求，服务器收到了数据，对客户端身份进行验证，发现密码错误，这时候服务器的一般做法应该是先发送一个密码错误的信息给客户端，然后把连接断掉。
如果把 
m_sLinger.l_onoff = 1; 
m_sLinger.l_linger = 0; 
这样设置后，很多情况下，客户端根本就收不到密码错误的消息，连接就被断了。
 
# 回复：[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:41 PM yun.zheng 
elssann(臭屁虫和他的开心果) ( ) 信誉：51 2005-01-30 13:24:00 得分: 0

出现CLOSE_WAIT的原因很简单，就是某一方在网络连接断开后，没有检测到这个错误，没有执行closesocket，导致了这个状态的实现，这在TCP/IP协议的状态变迁图上可以清楚看到。同时和这个相对应的还有一种叫TIME_WAIT的。
另外，把SOCKET的SO_LINGER设置为0秒拖延（也就是立即关闭）在很多时候是有害处的。 
还有，把端口设置为可复用是一种不安全的网络编程方法。
 

# 回复：[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:42 PM yun.zheng 
elssann(臭屁虫和他的开心果) ( ) 信誉：51 2005-01-30 14:48:00 得分: 0

能不能解释请看这里 
http://blog.csdn.net/cqq/archive/2005/01/26/269160.aspx
再看这个图：
http://tech.ccidnet.com/pub/attachment/2004/8/322252.png
断开连接的时候， 
当发起主动关闭的左边这方发送一个FIN过去后，右边被动关闭的这方要回应一个ACK，这个ACK是TCP回应的，而不 是应用程序发送的，此时，被动关闭的一方就处于CLOSE_WAIT状态了。如果此时被动关闭的这一方不再继续调用closesocket,那么他就不会 发送接下来的FIN，导致自己老是处于CLOSE_WAIT。只有被动关闭的这一方调用了closesocket,才会发送一个FIN给主动关闭的这一 方，同时也使得自己的状态变迁为LAST_ACK。
 
# 回复：[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 3:54 PM yun.zheng 
elssann(臭屁虫和他的开心果) ( ) 信誉：51 2005-01-30 15:39:00 得分: 0

比如被动关闭的是客户端。。。
当对方调用closesocket的时候，你的程序正在
int nRet = recv(s,….); 
if (nRet == SOCKET_ERROR) 
{ 
// closesocket(s); 
return FALSE; 
}
很多人就是忘记了那句closesocket，这种代码太常见了。
我的理解，当主动关闭的一方发送FIN到被动关闭这边后，被动关闭这边的TCP马上回应一个ACK过去，同时向上面应用程序提交一个ERROR，导 致上面的SOCKET的send或者recv返回SOCKET_ERROR，正常情况下，如果上面在返回SOCKET_ERROR后调用了 closesocket,那么被动关闭的者一方的TCP就会发送一个FIN过去，自己的状态就变迁到LAST_ACK.
 
# 回复：[Socket]尴尬的CLOSE_WAIT状态以及应对策略 2005-01-30 4:17 PM yun.zheng 
int nRecvBufLength = 
recv(sockConnected, 
szRecvBuffer, 
sizeof(szRecvBuffer), 
0); 
/// zhengyun 20050130: 
/// elssann举例说，当对方调用closesocket的时候，我的程序正在 
/// recv，这时候有可能对方发送的FIN包我没有收到，而是由TCP代回了 
/// 一个ACK包，所以我这边程序进入CLOSE_WAIT状态。 
/// 所以他建议在这里判断是否已出错，是就主动closesocket。 
/// 因为前面我们已经设置了recv超时时间为30秒，那么如果真的是超时了， 
/// 这里收到的错误应该是WSAETIMEDOUT，这种情况下也可以关闭连接的 
if (nRecvBufLength == SOCKET_ERROR) 
{ 
TRACE_INFO(_T(“=用recv接收发生Socket错误=”)); 
closesocket(sockConnected); 
continue; 
}
这样可以吗？ 
网络连接无法释放—— CLOSE_WAIT
关键字：TCP ，CLOSE_WAIT, Java, SocketChannel
 
问题描述：最 近性能测试碰到的一个问题。客户端使用NIO，服务器还是一般的Socket连接。当测试进行一段时间以后，发现服务器端的系统出现大量未释放的网络连 接。用netstat -na查看，连接状态为CLOSE_WAIT。这就奇怪了，为什么Socket已经关闭而连接依然未释放。
 
解决：Google了半天，发现关于CLOSE_WAIT的问题一般是C的，Java似乎碰到这个问题的不多（这有一篇不错的，也是解决CLOSE_WAIT的，但是好像没有根本解决，而是选择了一个折中的办法）。接着找，由于使用了NIO，所以怀疑可能是这方面的问题，结果找到了这篇。顺着帖子翻下去，其中有几个人说到了一个问题—— 一端的Socket调用close后，另一端的Socket没有调用close.于是查了一下代码，果然发现Server端在某些异常情况时，没有关闭Socket。改正后问题解决。
时间基本上花在Google上了，不过也学到不少东西。下面为一张TCP连接的状态转换图：
 
说明：虚线和实线分别对应服务器端(被连接端)和客户端端(主动连接端)。
结合上图使用netstat -na命令即可知道到当前的TCP连接状态。一般LISTEN、ESTABLISHED、TIME_WAIT是比较常见。
 
分析：
上面我碰到的这个问题主要因为TCP的结束流程未走完，造成连接未释放。现设客户端主动断开连接，流程如下
 
       Client                            消息                                    Server
         close()
                                      —— FIN ——->
        FIN_WAIT1                                                         CLOSE_WAIT
                                      <—– ACK ——-
        FIN_WAIT2 
                                                                                  close()
                                       <—— FIN ——                     
        TIME_WAIT                                                       LAST_ACK      
                                      —— ACK ——->  
                                                                                   CLOSED
           CLOSED
 
如上图所示，由于Server的Socket在客户端已经关闭时而没有调用关闭，造成服务器端的连接处在“挂起”状态，而客户端则处在等待应答的状态上。此问题的典型特征是：一端处于FIN_WAIT2 ，而另一端处于CLOSE_WAIT. 不过，根本问题还是程序写的不好，有待提高。

TIME_WAIT状态
根据TCP协议，主动发起关闭的一方，会进入TIME_WAIT状态，持续2*MSL(Max Segment Lifetime)，缺省为240秒，在这个post中简洁的介绍了为什么需要这个状态。
值得一说的是，对于基于TCP的HTTP协议，关闭TCP连接的是Server端，这样，Server端会进入TIME_WAIT状态，可 想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态，假如server一秒钟接收1000个请求，那么就会积压240*1000=240，000个 TIME_WAIT的记录，维护这些状态给Server带来负担。当然现代操作系统都会用快速的查找算法来管理这些TIME_WAIT，所以对于新的 TCP连接请求，判断是否hit中一个TIME_WAIT不会太费时间，但是有这么多状态要维护总是不好。
HTTP协议1.1版规定default行为是Keep-Alive，也就是会重用TCP连接传输多个 request/response，一个主要原因就是发现了这个问题。还有一个方法减缓TIME_WAIT压力就是把系统的2*MSL时间减少，因为 240秒的时间实在是忒长了点，对于Windows，修改注册表，在HKEY_LOCAL_MACHINE/ SYSTEM/CurrentControlSet/Services/ Tcpip/Parameters上添加一个DWORD类型的值TcpTimedWaitDelay，一般认为不要少于60，不然可能会有麻烦。
对于大型的服务，一台server搞不定，需要一个LB(Load Balancer)把流量分配到若干后端服务器上，如果这个LB是以NAT方式工作的话，可能会带来问题。假如所有从LB到后端Server的IP包的 source address都是一样的(LB的对内地址），那么LB到后端Server的TCP连接会受限制，因为频繁的TCP连接建立和关闭，会在server上留 下TIME_WAIT状态，而且这些状态对应的remote address都是LB的，LB的source port撑死也就60000多个(2^16=65536,1~1023是保留端口，还有一些其他端口缺省也不会用），每个LB上的端口一旦进入 Server的TIME_WAIT黑名单，就有240秒不能再用来建立和Server的连接，这样LB和Server最多也就能支持300个左右的连接。 如果没有LB，不会有这个问题，因为这样server看到的remote address是internet上广阔无垠的集合，对每个address，60000多个port实在是够用了。
一开始我觉得用上LB会很大程度上限制TCP的连接数，但是实验表明没这回事，LB后面的一台Windows Server 2003每秒处理请求数照样达到了600个，难道TIME_WAIT状态没起作用？用Net Monitor和netstat观察后发现，Server和LB的XXXX端口之间的连接进入TIME_WAIT状态后，再来一个LB的XXXX端口的 SYN包，Server照样接收处理了，而是想像的那样被drop掉了。翻书，从书堆里面找出覆满尘土的大学时代买的《UNIX Network Programming, Volume 1, Second Edition: Networking APIs: Sockets and XTI》，中间提到一句，对于BSD-derived实现，只要SYN的sequence number比上一次关闭时的最大sequence number还要大，那么TIME_WAIT状态一样接受这个SYN，难不成Windows也算BSD-derived?有了这点线索和关键字 (BSD)，找到这个post，在NT4.0的时候，还是和BSD-derived不一样的，不过Windows Server 2003已经是NT5.2了，也许有点差别了。
做个试验，用Socket API编一个Client端，每次都Bind到本地一个端口比如2345，重复的建立TCP连接往一个Server发送Keep-Alive=false 的HTTP请求，Windows的实现让sequence number不断的增长，所以虽然Server对于Client的2345端口连接保持TIME_WAIT状态，但是总是能够接受新的请求，不会拒绝。那 如果SYN的Sequence Number变小会怎么样呢？同样用Socket API，不过这次用Raw IP，发送一个小sequence number的SYN包过去，Net Monitor里面看到，这个SYN被Server接收后如泥牛如海，一点反应没有，被drop掉了。
按照书上的说法，BSD-derived和Windows Server 2003的做法有安全隐患，不过至少这样至少不会出现TIME_WAIT阻止TCP请求的问题，当然，客户端要配合，保证不同TCP连接的sequence number要上涨不要下降。

TCP 状态变化

关闭socket分为主动关闭(Active closure)和被动关闭(Passive closure)两种情况。前者是指有本地主机主动发起的关闭;而后者则是指本地主机检测到远程主机发起关闭之后，作出回应，从而关闭整个连接。将关闭部分的状态转移摘出来，就得到了下图：

发生原因

通过图上，我们来分析，什么情况下，连接处于CLOSE_WAIT状态呢?

在被动关闭连接情况下，在已经接收到FIN，但是还没有发送自己的FIN的时刻，连接处于CLOSE_WAIT状态。

通常来讲，CLOSE_WAIT状态的持续时间应该很短，正如SYN_RCVD状态。但是在一些特殊情况下，就会出现连接长时间处于CLOSE_WAIT状态的情况。

出现大量close_wait的现象，主要原因是某种情况下对方关闭了socket链接，但是我方忙与读或者写，没有关闭连接。代码需要判断socket，一旦读到0，断开连接，read返回负，检查一下errno，如果不是AGAIN，就断开连接。

more:

起初每个socket都是CLOSED状态，当客户端初使化一个连接，他发送一个SYN包到服务器，客户端进入SYN_SENT状态。服务器接收到SYN包，反馈一个SYN-ACK包，客户端接收后返馈一个ACK包客户端变成ESTABLISHED状态，如果长时间没收到SYN-ACK包，客户端超时进入CLOSED状态。

当服务器绑定并监听某一端口时，socket的状态是LISTEN，当客户企图建立连接时，服务器收到一个SYN包，并反馈SYN-ACK包。服务器状态变成SYN_RCVD，当客户端发送一个ACK包时，服务器socket变成ESTABLISHED状态。

当一个程序在ESTABLISHED状态时有两种图径关闭它，第一是主动关闭，第二是被动关闭。如果你要主动关闭的话，发送一个FIN包。当你的程序closesocket或者shutdown(标记)，你的程序发送一个FIN包到peer，你的socket变成FIN_WAIT_1状态。peer反馈一个ACK包，你的socket进入FIN_WAIT_2状态。如果peer也在关闭连接，那么它将发送一个FIN包到你的电脑，你反馈一个ACK包，并转成TIME_WAIT状态。TIME_WAIT状态又号2MSL等待状态。MSL意思是最大段生命周期(Maximum+Segment+Lifetime)表明一个包存在于网络上到被丢弃之间的时间。每个IP包有一个TTL(time_to_live)，当它减到0时则包被丢弃。每个路由器使TTL减一并且传送该包。当一个程序进入TIME_WAIT状态时，他有2个MSL的时间，这个充许TCP重发最后的ACK，万一最后的ACK丢失了，使得FIN被重新传输。在2MSL等待状态完成后，socket进入CLOSED状态。

被动关闭：当程序收到一个FIN包从peer，并反馈一个ACK包，于是程序的socket转入CLOSE_WAIT状态。因为peer已经关闭了，所以不能发任何消息了。但程序还可以。要关闭连接，程序自已发送给自已FIN，使程序的TCP socket状态变成LAST_ACK状态，当程序从peer收到ACK包时，程序进入CLOSED状态。

今天的文章close wait状态_失眠是什么原因引起的分享到此就结束了，感谢您的阅读。