time_wait和close_wait产生缘由及解决

 

在服务器的平常维护过程当中，会常常用到下面的命令：
netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’
其中$NF表示最后一个字段
它会显示例以下面的信息：
TIME_WAIT 814
CLOSE_WAIT 1
FIN_WAIT1 1
ESTABLISHED 634
SYN_RECV 2
LAST_ACK 1
经常使用的三个状态是：ESTABLISHED 表示正在通讯，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

再具体一点，四次挥手的交互过程以下：
客户端先发送FIN，进入FIN_WAIT1状态
服务端收到FIN，发送ACK，进入CLOSE_WAIT状态，客户端收到这个ACK，进入FIN_WAIT2状态
服务端发送FIN，进入LAST_ACK状态
客户端收到FIN，发送ACK，进入TIME_WAIT状态，服务端收到ACK，进入CLOSE状态
客户端TIME_WAIT持续2倍MSL时长，在linux体系中大概是60s，转换成CLOSE状态

能不能发送完ACK以后不进入TIME_WAIT就直接进入CLOSE状态呢？不行的，这个是为了TCP协议的可靠性，因为网络缘由，ACK可能会发送失败，那么这个时候，被动一方会主动从新发送一次FIN，这个时候若是主动方在TIME_WAIT状态，则还会再发送一次ACK，从而保证可靠性。那么从这个解释来讲，2MSL的时长设定是能够理解的，MSL是报文最大生存时间，若是从新发送，一个FIN＋一个ACK，再加上不按期的延迟时间，大体是在2MSL的范围。
若是服务器出了异常，百分之八九十都是下面两种状况：
1.服务器保持了大量TIME_WAIT状态
2.服务器保持了大量CLOSE_WAIT状态
由于linux分配给一个用户的文件句柄是有限的，而TIME_WAIT和CLOSE_WAIT两种状态若是一直被保持，那么意味着对应数目的通道就一直被占着，一旦达到句柄数上限，新的请求就没法被处理了，接着应用程序可能返回大量Too Many Open Files异常。
1）服务端的Time-wait过多
先来讲一说长链接和短链接，在HTTP1.1协议中，有个 Connection 头，Connection有两个值，close和keep-alive，这个头就至关于客户端告诉服务端，服务端你执行完成请求以后，是关闭链接仍是保持链接。若是服务器使用的短链接，那么每次客户端请求后，服务器都会主动发送FIN关闭链接。最后进入time_wait状态。可想而知，对于访问量大的Web Server，会存在大量的TIME_WAIT状态。让服务器可以快速回收和重用那些TIME_WAIT的资源，能够修改内核参数。
修改/etc/sysctl.conf以下：
#对于一个新建链接，内核要发送多少个 SYN 链接请求才决定放弃,不该该大于255，默认值是5，对应于180秒左右时间
net.ipv4.tcp_syn_retries=2
#net.ipv4.tcp_synack_retries=2
#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改成300秒
net.ipv4.tcp_keepalive_time=1200
net.ipv4.tcp_orphan_retries=3
#表示若是套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间
net.ipv4.tcp_fin_timeout=30
#表示SYN队列的长度，默认为1024，加大队列长度为8192，能够容纳更多等待链接的网络链接数。
net.ipv4.tcp_max_syn_backlog = 4096
#表示开启SYN Cookies。当出现SYN等待队列溢出时，启用cookies来处理，可防范少许SYN攻击，默认为0，表示关闭
net.ipv4.tcp_syncookies = 1

#表示开启重用。容许将TIME-WAIT sockets从新用于新的TCP链接，默认为0，表示关闭
net.ipv4.tcp_tw_reuse = 1
#表示开启TCP链接中TIME-WAIT sockets的快速回收，默认为0，表示关闭
net.ipv4.tcp_tw_recycle = 1

##减小超时前的探测次数
net.ipv4.tcp_keepalive_probes=5
##优化网络设备接收队列
net.core.netdev_max_backlog=3000
修改完以后执行/sbin/sysctl -p让参数生效。

2）close_wait
若是一直保持在CLOSE_WAIT状态，那么只有一种状况，就是在对方关闭链接以后服务器程序本身没有进一步发出FIN信号，通常缘由都是TCP链接没有调用关闭方法。换句话说，就是在对方链接关闭以后，程序里没有检测到，或者程序压根就忘记了这个时候须要关闭链接，因而这个资源就一直被程序占着。这种状况，经过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行，必定程度上，可使用TCP的KeepAlive功能，让操做系统替咱们自动清理掉CLOSE_WAIT链接。
可是实际上，仍是主要是由于咱们的程序代码有问题，一般是以下问题：
当对方调用closesocket的时候，你的程序正在

C代码
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。