解决TIME_WAIT过多造成的问题_转

转自:解决TIME_WAIT过多造成的问题 (eroswang的csdn)

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

LAST_ACK 14
SYN_RECV 348
ESTABLISHED 70
FIN_WAIT1 229
FIN_WAIT2 30
CLOSING 33
TIME_WAIT 18122 

状态:描述

CLOSED:无连接是活动的或正在进行

LISTEN:服务器在等待进入呼叫

SYN_RECV:一个连接请求已经到达,等待确认

SYN_SENT:应用已经开始,打开一个连接

ESTABLISHED:正常数据传输状态

FIN_WAIT1:应用说它已经完成

FIN_WAIT2:另一边已同意释放

ITMED_WAIT:等待所有分组死掉

CLOSING:两边同时尝试关闭

TIME_WAIT:另一边已初始化一个释放

LAST_ACK:等待所有分组死掉

也就是说,这条命令可以把当前系统的网络连接状态分类汇总。

下面解释一下为啥要这样写:

一个简单的管道符连接了netstat和awk命令。

——————————————————————

先来看看netstat:

netstat -n

Active Internet connections (w/o servers)

Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 123.123.123.123:80 234.234.234.234:12345 TIME_WAIT

你实际执行这条命令的时候,可能会得到成千上万条类似上面的记录,不过我们就拿其中的一条就足够了。

——————————————————————

再来看看awk:

/^tcp/

滤出tcp开头的记录,屏蔽udp, socket等无关记录。

state[]相当于定义了一个名叫state的数组

NF

表示记录的字段数,如上所示的记录,NF等于6

$NF

表示某个字段的值,如上所示的记录,$NF也就是$6,表示第6个字段的值,也就是TIME_WAIT

state[$NF]表示数组元素的值,如上所示的记录,就是state[TIME_WAIT]状态的连接数

++state[$NF]表示把某个数加一,如上所示的记录,就是把state[TIME_WAIT]状态的连接数加一

END

表示在最后阶段要执行的命令

for(key in state)

遍历数组

print key,”\t”,state[key]打印数组的键和值,中间用\t制表符分割,美化一下。

如发现系统存在大量TIME_WAIT状态的连接,通过调整内核参数解决,

vim /etc/sysctl.conf

编辑文件,加入以下内容:

net.ipv4.tcp_syncookies = 1

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_tw_recycle = 1

net.ipv4.tcp_fin_timeout = 30

然后执行 /sbin/sysctl -p 让参数生效。

net.ipv4.tcp_syncookies = 1 表示开启SYN cookies。当出现SYN等待队列溢出时,启用cookies来处理,可防范少量SYN攻击,默认为0,表示关闭;

net.ipv4.tcp_tw_reuse = 1 表示开启重用。允许将TIME-WAIT sockets重新用于新的TCP连接,默认为0,表示关闭;

net.ipv4.tcp_tw_recycle = 1 表示开启TCP连接中TIME-WAIT sockets的快速回收,默认为0,表示关闭。

net.ipv4.tcp_fin_timeout 修改系統默认的 TIMEOUT 时间

下面附上TIME_WAIT状态的意义:

客户端与服务器端建立TCP/IP连接后关闭SOCKET后,服务器端连接的端口

状态为TIME_WAIT

是不是所有执行主动关闭的socket都会进入TIME_WAIT状态呢?

有没有什么情况使主动关闭的socket直接进入CLOSED状态呢?

主动关闭的一方在发送最后一个 ack 后

就会进入 TIME_WAIT 状态 停留2MSL(max segment lifetime)时间

这个是TCP/IP必不可少的,也就是“解决”不了的。

也就是TCP/IP设计者本来是这么设计的

主要有两个原因

1. 防止上一次连接中的包,迷路后重新出现,影响新连接

(经过2MSL,上一次连接中所有的重复包都会消失)

2. 可靠的关闭TCP连接

在主动关闭方发送的最后一个 ack(fin) ,有可能丢失,这时被动方会重新发

fin, 如果这时主动方处于 CLOSED 状态 ,就会响应 rst 而不是 ack。所以

主动方要处于 TIME_WAIT 状态,而不能是 CLOSED 。

TIME_WAIT 并不会占用很大资源的,除非受到攻击。

还有,如果一方 send 或 recv 超时,就会直接进入 CLOSED 状态

时间: 2024-08-11 09:57:49

解决TIME_WAIT过多造成的问题_转的相关文章

解决TIME_WAIT过多造成的问题

sh-4.1# netstat -an |awk '/tcp/ {++S[$NF]}END {for (a in S) print a , S[a]}' TIME_WAIT 41 CLOSE_WAIT 1 ESTABLISHED 2 LISTEN 7 TCP/IP TIME_WAIT状态原理: 通信双方建立TCP连接后,主动关闭连接的一方就会进入TIME_WAIT状态 客户端主动关闭连接时,会发送最后一个ack后,然后会进入TIME_WAIT状态,再停留2个MSL时间(后有MSL的解释),进入C

解决time_wait过多的问题

#netstat -n | awk ‘/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}’ LAST_ACK 14SYN_RECV 348ESTABLISHED 70FIN_WAIT1 229FIN_WAIT2 30CLOSING 33TIME_WAIT 18122 状态:描述CLOSED:无连接是活动的或正在进行LISTEN:服务器在等待进入呼叫SYN_RECV:一个连接请求已经到达,等待确认SYN_SENT:应用已经开始,打开一个连接ESTAB

Nginx做前端Proxy时TIME_WAIT过多的问题

转自:http://www.cnblogs.com/QLeelulu/p/3601499.html 我们的DSP系统目前基本非凌晨时段的QPS都在10W以上,我们使用Golang来处理这些HTTP请求,Web服务器的前端用Nginx来做负载均衡,通过Nginx的proxy_pass来与Golang交互. 由于nginx代理使用了短链接的方式和后端交互的原因,使得系统TIME_WAIT的tcp连接很多: shell> netstat -n | awk '/^tcp/ {++state[$NF]}

linux TIME_WAIT过多的解决方法

查看TCP状态:netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'查看SOCKET状态:cat /proc/net/sockstatTIME_WAIT状态的socket一般需要等到2msl时间后,socket才会被回收.修改(添加)系统内核参数:/etc/sysctl.conf #改系統默认的TIMEOUT时间net.ipv4.tcp_fin_timeout=2 #启重用,允许将TIME-WAIT socket

time_wait 过多 造成网络慢 实战

sh-3.2# scripts]# netstat -an|awk '/tcp/ {++S[$NF]}END {for (a in S) print a,S[a]}' TIME_WAIT 33 ESTABLISHED 70 LISTEN 13 sh-3.2# 5 scripts]# cat /etc/sysctl.conf|awk '/net.ipv4.tcp_syncookies|net.ipv4.tcp_tw_reuse|net.ipv4.tcp_tw_recycle|net.ipv4.tc

Nginx下TIME_WAIT过多的调优

查看Nginx并发状态 #netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' TIME_WAIT 1259SYN_SENT 2FIN_WAIT1 8ESTABLISHED 166FIN_WAIT2 24SYN_RECV 25CLOSING 17LAST_ACK 18 ======================== 以上参数解释:CLOSED:无连接是活动的或正在进行LISTEN:服务器在等待进入呼叫SYN_R

TCP TIME_WAIT过多的解决方法

总结: 最合适的解决方案是增加更多的四元组数目,比如,服务器监听端口,或服务器IP,让服务器能容纳足够多的TIME-WAIT状态连接.在我们常见的互联网架构中(NGINX反代跟NGINX,NGINX跟FPM,FPM跟redis.mysql.memcache等),减少TIME-WAIT状态的TCP连接,最有效的是使用长连接,不要用短连接,尤其是负载均衡跟web服务器之间.尤其是链家事件中的PHP连不上redis. 在服务端,不要启用net.ipv4.tcp_tw_recycle,除非你能确保你的服

TCP连接状态详解及TIME_WAIT过多的解决方法

TCP建立连接的三次握手过程,以及关闭连接的四次握手过程. TCP建立连接的三次握手过程,以及关闭连接的四次握手过程. 1.建立连接协议(三次握手)(1)客户端发送一个带SYN标志的TCP报文到服务器.这是三次握手过程中的报文1. (2) 服务器端回应客户端的,这是三次握手中的第2个报文,这个报文同时带ACK标志和SYN标志.因此它表示对刚才客户端SYN报文的回应:同时又标志SYN给客户端,询问客户端是否准备好进行数据通讯. (3) 客户必须再次回应服务段一个ACK报文,这是报文段3. 2.连接

TIME_WAIT过多

Linux系统下,TCP/IP连接断开后,会以TIME_WAIT状态保留一定的时间,然后才会释放端口.当并发请求过多的时候,就会产生大量的 TIME_WAIT状态的连接,无法及时断开的话,会占用大量的端口资源和服务器资源(因为关闭后进程才会退出).这个时候我们可以考虑优化TCP/IP 的内核参数,来及时将TIME_WAIT状态的端口清理掉 在下面的参数的基础上,建议优化点(/etc/sysctl.conf): 1:增大tcp_max_tw_buckets为200000 2:修改tcp_times