应用环境下的TIME_WAIT和CLOSE_WAIT处理

昨天解决了一个HttpClient调用错误导致的服务器异常，具体过程如下：
/article/2973927.html
里头的分析过程有提到，通过查看服务器网络状态检测到服务器有大量的CLOSE_WAIT的状态。

在服务器的日常维护过程中，会经常用到下面的命令：

[plain] view
plaincopyprint?





netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'

它会显示例如下面的信息：
TIME_WAIT 814

CLOSE_WAIT 1

FIN_WAIT1 1

ESTABLISHED 634

SYN_RECV 2

LAST_ACK 1

常用的三个状态是：ESTABLISHED 表示正在通信，TIME_WAIT 表示主动关闭，CLOSE_WAIT 表示被动关闭。

具体每种状态什么意思，其实无需多说，看看下面这种图就明白了，注意这里提到的服务器应该是业务请求接受处理的一方：



连接关闭状态转换描述：

1. 默认情况是established状态，当服务器首先向客户机发送FIN包，然后服务器进入FIN_WAIT_1状态。

2. 客户机向服务器确认FIN包收到，向服务器发送FIN/ACK，客户机进入CLOSE_WAIT状态。

3. 服务器收到来自客户机的FIN/ACK后，进入FIN_WAIT_2状态

4. 现在客户机进入被动关闭(“passive
close”)状态，客户机操作系统等待他上面的应用程序关闭连接。一旦连接被关闭，客户端会发送FIN包到服务器

5. 当服务器收到FIN包后，服务器会向客户机发送FIN/ACK确认，然后进入著名的TIME_WAIT状态。由于在连接关闭后，还不能确定所有连接关闭前的包都被服务器接受到了(包的接受是没有先后顺序的)，因此有了TIME_WAIT状态。在这个状态中，服务器仍然在等待客户机发送的但是还未到达服务器的包。这个状态将保持2*MSL的时间，这里的MSL指的是一个TCP包在网络中存在的最长时间。一般情况下
2*MSL=240秒。

其实fin_wait1、fin_wati2、close_wait都不是正常现象，只有established和time_wait是正常的。

如果发现fin_wait状态很多，并且client ip分布正常，那可能是有ddos攻击、又或者最近的程序改动引起了问题。一般说来后者可能性更大，应该主动联系程序员解决。

这么多状态不用都记住，只要了解到我上面提到的最常见的三种状态的意义就可以了。一般不到万不得已的情况也不会去查看网络状态，如果服务器出了异常，百分之八九十都是下面两种情况：
1.服务器保持了大量TIME_WAIT状态
2.服务器保持了大量CLOSE_WAIT状态
因为linux分配给一个用户的文件句柄是有限的（可以参考：/article/2973926.html），而TIME_WAIT和CLOSE_WAIT两种状态如果一直被保持，那么意味着对应数目的通道就一直被占着，而且是“占着茅坑不使劲”，一旦达到句柄数上限，新的请求就无法被处理了，接着就是大量Too
Many Open Files异常，tomcat崩溃。。。
下面来讨论下这两种情况的处理方法。
网上有很多资料把这两种情况的处理方法混为一谈，以为优化系统内核参数就可以解决问题，其实是不恰当的，优化系统内核参数解决TIME_WAIT可能很容易，但是应对CLOSE_WAIT的情况还是需要从程序本身出发。现在来分别说说这两种情况的处理方法：

1.服务器保持了大量TIME_WAIT状态

这种情况比较常见，一些爬虫服务器或者WEB服务器（如果网管在安装的时候没有做内核参数优化的话）上经常会遇到这个问题，这个问题是怎么产生的呢？
从上面的示意图可以看得出来，TIME_WAIT是主动关闭连接的一方保持的状态，对于爬虫服务器来说他本身就是“客户端”，在完成一个爬取任务之后，他就会发起主动关闭连接，从而进入TIME_WAIT的状态，然后在保持这个状态2MSL（max segment lifetime）时间之后，彻底关闭回收资源。为什么要这么做？明明就已经主动关闭连接了为啥还要保持资源一段时间呢？这个是TCP/IP的设计者规定的，主要出于以下两个方面的考虑：
1.防止上一次连接中的包，迷路后重新出现，影响新连接（经过2MSL，上一次连接中所有的重复包都会消失）

2.可靠的关闭TCP连接。在主动关闭方发送的最后一个 ack(fin) ，有可能丢失，这时被动方会重新发fin, 如果这时主动方处于 CLOSED 状态 ，就会响应 rst 而不是 ack。所以主动方要处于 TIME_WAIT 状态，而不能是 CLOSED 。另外这么设计TIME_WAIT 会定时的回收资源，并不会占用很大资源的，除非短时间内接受大量请求或者受到攻击。
关于MSL引用下面一段话：
MSL 為一個 TCP Segment (某一塊 TCP 網路封包) 從來源送到目的之間可續存的時間 (也就是一個網路封包在網路上傳輸時能存活的時間)，由於 RFC 793 TCP 傳輸協定是在 1981 年定義的，當時的網路速度不像現在的網際網路那樣發達，你可以想像你從瀏覽器輸入網址等到第一個 byte 出現要等 4 分鐘嗎？在現在的網路環境下幾乎不可能有這種事情發生，因此我們大可將 TIME_WAIT 狀態的續存時間大幅調低，好讓 連線埠 (Ports) 能更快空出來給其他連線使用。

再引用网络上的一段话：
值得一说的是，对于基于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，一个主要原因就是发现了这个问题。

也就是说HTTP的交互跟上面画的那个图是不一样的，关闭连接的不是客户端，而是服务器，所以web服务器也是会出现大量的TIME_WAIT的情况的。

现在来说如何来解决这个问题。

解决思路很简单，就是让服务器能够快速回收和重用那些TIME_WAIT的资源。

下面来看一下我们网管对/etc/sysctl.conf文件的修改：

#对于一个新建连接，内核要发送多少个 SYN 连接请求才决定放弃,不应该大于255，默认值是5，对应于180秒左右时间

net.ipv4.tcp_syn_retries=2

#SYN-ACK发送次数

#net.ipv4.tcp_synack_retries=2

#表示当keepalive起用的时候，TCP发送keepalive消息的频度。缺省是2小时，改为300秒

net.ipv4.tcp_keepalive_time=1200

#在近端丢弃TCP连接之前﹐要进行多少次重试。默认值是7个﹐相当于
50秒 - 16分钟﹐
#视 RTO 而定。如果您的系统是负载很大的web服务器﹐那么也许需要降低该值﹐
#这类 sockets 可能会耗费大量的资源。
#另外参的考 tcp_max_orphans 。(事实上做NAT的时候,降低该值也是好处显著的,我本人的网络环境中降低该值为3)
#sysctl_tcp_orphan_retries
主要是针对孤立的socket(也就是已经从进程上下文中删除了，
#可是还有一些清理工作没有完成).对于这种socket，我们重试的最大的次数就是它。

#默认值是7，设置为0表示不重试
#最近测试发现socket会永远停留在FIN_WAIT_1这个状态，而不会重传超时RESET后closed。
#在Linux上，tcp_orphan_retries设置为0就是这个效果。

#查了资料，有这一段解释

/* Do not allow orphaned sockets to eat all our resources.

* This is direct violation of TCP specs, but it is required

* to prevent DoS attacks. It is called when a retransmission timeout

* or zero probe timeout occurs on orphaned socket.

*

* Criteria is still not confirmed experimentally and may change.

* We kill the socket, if:

* 1. If number of orphaned sockets exceeds an administratively configured

* limit.

* 2. If we have strong memory pressure.

*/

set to 0，It doesn't mean "try forever", it means "don't try at all." This is the server trying to politely tell the client that the server is getting ready to close his socket, and if it would please do an orderly disconnect, or send some more data, that would
be wonderful. It will try X times to get the client to respond, and after X, it reclaims the socket on the system side.

Setting that number to 0 would suggest to me that that server is heavily utilized, with a zero tolerance policy for orphans. It may also have been a response to a DDOS: lot of DDOS' work by opening a socket connection and then hanging on to it, doing nothing.

net.ipv4.tcp_orphan_retries=3

#表示如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间.
#注意，tcp_fin_timeout 不是2MSL，而是Fin-WAIT-2状态

net.ipv4.tcp_fin_timeout=30

#表示SYN队列的长度（半连接队列长度，半连接即接收了SYN，发送了SYN-ACK，但是还没有收到客户端ACK的连接），
#默认为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

##优化网络设备接收队列，number of unprocessed input packets before kernel starts dropping them,
##default 300。
##我所理解的含义，每个网络接口接收数据包的速率比内核处理这些包的速率快时，允许送到队列的最大数目，
##一旦超过将被丢弃。

net.core.netdev_max_backlog=3000

修改完之后执行/sbin/sysctl -p让参数生效。

这里头主要注意到的是net.ipv4.tcp_tw_reuse
net.ipv4.tcp_tw_recycle

net.ipv4.tcp_fin_timeout

net.ipv4.tcp_keepalive_*

这几个参数。

net.ipv4.tcp_tw_reuse和net.ipv4.tcp_tw_recycle的开启都是为了回收处于TIME_WAIT状态的资源。

net.ipv4.tcp_fin_timeout这个时间可以减少在异常情况下服务器从FIN-WAIT-2转到TIME_WAIT的时间。

net.ipv4.tcp_keepalive_*一系列参数，是用来设置服务器检测连接存活的相关配置。

关于keepalive的用途可以参考：http://hi.baidu.com/tantea/blog/item/580b9d0218f981793812bb7b.html

[2015.01.13更新]
注意tcp_tw_recycle开启的风险：http://blog.csdn.net/wireless_tech/article/details/6405755

2.服务器保持了大量CLOSE_WAIT状态

休息一下，喘口气，一开始只是打算说说TIME_WAIT和CLOSE_WAIT的区别，没想到越挖越深，这也是写博客总结的好处，总可以有意外的收获。

TIME_WAIT状态可以通过优化服务器参数得到解决，因为发生TIME_WAIT的情况是服务器自己可控的，要么就是对方连接的异常，要么就是自己没有迅速回收资源，总之不是由于自己程序错误导致的。
但是CLOSE_WAIT就不一样了，从上面的图可以看出来，如果一直保持在CLOSE_WAIT状态，那么只有一种情况，就是在对方关闭连接之后服务器程序自己没有进一步发出ack信号。换句话说，就是在对方连接关闭之后，程序里没有检测到，或者程序压根就忘记了这个时候需要关闭连接，于是这个资源就一直被程序占着。个人觉得这种情况，通过服务器内核参数也没办法解决，服务器对于程序抢占的资源没有主动回收的权利，除非终止程序运行。

如果你使用的是HttpClient并且你遇到了大量CLOSE_WAIT的情况，那么这篇日志也许对你有用：
/article/2973927.html
在那边日志里头我举了个场景，来说明CLOSE_WAIT和TIME_WAIT的区别，这里重新描述一下：
服务器A是一台爬虫服务器，它使用简单的HttpClient去请求资源服务器B上面的apache获取文件资源，正常情况下，如果请求成功，那么在抓取完资源后，服务器A会主动发出关闭连接的请求，这个时候就是主动关闭连接，服务器A的连接状态我们可以看到是TIME_WAIT。如果一旦发生异常呢？假设请求的资源服务器B上并不存在，那么这个时候就会由服务器B发出关闭连接的请求，服务器A就是被动的关闭了连接，如果服务器A被动关闭连接之后程序员忘了让HttpClient释放连接，那就会造成CLOSE_WAIT的状态了。

所以如果将大量CLOSE_WAIT的解决办法总结为一句话那就是：查代码。因为问题出在服务器程序里头啊。

参考资料：
1.windows下的TIME_WAIT的处理可以参加这位大侠的日志：http://blog.miniasp.com/post/2010/11/17/How-to-deal-with-TIME_WAIT-problem-under-Windows.aspx
2.WebSphere的服务器优化有一定参考价值：http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/tprf_tunelinux.html
3.各种内核参数的含义：http://haka.sharera.com/blog/BlogTopic/32309.htm
4.linux服务器历险之sysctl优化linux网络：/article/7774449.html

/article/2973950.html

http://jeanerpp.lofter.com/post/a817f_dfcd11

3down voteaccepted

It doesn't mean "try forever", it means "don't try at all." This is the server trying to politely tell the client that the server is getting ready to close his socket, and if it would please do an orderly disconnect, or send some more data, that would be wonderful. It will try X times to get the client to respond, and after X, it reclaims the socket on the system side. Setting that number to 0 would suggest to me that that server is heavily utilized, with a zero tolerance policy for orphans. It may also have been a response to a DDOS: lot of DDOS' work by opening a socket connection and then hanging on to it, doing nothing.