Linux服务器大量的CLOSE_WAIT、TIME_WAIT解决办法.pdfVIP

Linux服务器⼤量的 CLOSE_WAIT、TIME_WAIT解决办法 系统上线之后，通过如下语句查看服务器时，发现有不少TIME_WAIT和CLOSE_WAIT。 netstat -an | awk {print $6} | sort | uniq -c | sort -rn netstat -n | awk /^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]} 打印显⽰如下： TIME_WAIT 297 ESTABLISHED 53 CLOSE_WAIT 5 TIME_WAIT：表⽰主动关闭，通过优化系统内核参数可容易解决。 CLOSE_WAIT ：表⽰被动关闭，需要从程序本⾝出发。 ESTABLISHED ：表⽰正在通信 通过上⽹了解，总结如下： ⼀、TIME_WAIT （通过优化系统内核参数可容易解决） 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 会定时的回收资 源，并不会占⽤很⼤资源的，除⾮短时间内接受⼤量请求或者受到攻击。 解决⽅案很简单，通过修改/etc/sysctl.conf⽂件，服务器能够快速回收和重⽤那些TIME_WAIT的资源 #表⽰开启SYN C kies。当出现SYN等待队列溢出时，启⽤c kies来处理，可防范少量SYN攻击，默认为0，表⽰关闭 net.ipv4.tcp_sync kies = 1 #表⽰开启重⽤。允许将TIME-WAIT sockets 重新⽤于新的TCP连接，默认为0，表⽰关闭 net.ipv4.tcp_tw_reuse = 1 #表⽰开启TCP连接中TIME-WAIT sockets 的快速回收，默认为0，表⽰关闭 net.ipv4.tcp_tw_recycle = 1 #表⽰如果套接字由本端要求关闭，这个参数决定了它保持在FIN-WAIT-2状态的时间 net.ipv4.tcp_fin_timeout=30 ⽣效，如下命令 /sbin/sysctl -p ⼆、CLOSE_WAIT （需要从程序本⾝出发） TCP状态转移要点 TCP协议规定，对于已经建⽴的连接，⽹络双⽅要进⾏四次握⼿才能成功断开连接，如果缺少了其中某个步骤，将会使连接处于假死状 态，连接本⾝占⽤的资源不会被释放。⽹络服务器程序要同时管理⼤量连接，所以很有必要保证⽆⽤连接完全断开，否则⼤量僵死的连接会 浪费许多服务器资源. 客户端TCP状态迁移： CLOSED-SYN_SENT-ESTABLISHED-FIN_WAIT_1-FIN_WAIT_2-TIME_WAIT-CLOSED 服务器TCP状态迁移 CLOSED-LISTEN-SY 收到-ESTABLISHED-CLOSE_WAIT-LAST_ACK-CLOSED 当客户端开始连接时，服务器还处于LISTENING，客户端发⼀个SY 包后，他就处于SYN_SENT 状态,服务器就处于SYS 收到状态,然后 互相确认进⼊连接状态ESTABLISHED 。 TIME_WAIT状态可以通过优化服务器参数得到解决，因为发⽣TIME_WAIT的情况是服务器⾃⼰可控的，要么就是对⽅连接的异常，要 么就是⾃⼰没有迅速回收资源，总之不是由于⾃⼰程序错误导致的。 但是CLOSE_WAIT就不⼀样了，如果⼀直保持在CLOSE_WAIT状态，那么只有⼀种情况，就是在对⽅关闭连接之后服务器程序⾃⼰没