大量的TIME_WAIT解决办法

不记得从哪摘下来的了,做个备忘记录。


#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 状态
  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
服务器出现大量time_wait是指在TCP连接断开后,服务器端口仍处于等待状态的情况。这可能会导致服务器资源的浪费,影响服务器的性能和可用性。以下是理解并解决这个问题的步骤: 首先,需要理解time_wait的原因:TCP连接的断开是一个多步骤的过程,在最后一个ACK报文发送后,服务器端口会进入time_wait状态一段时间,以确保在这段时间内没有延迟的报文重新出现。这是网络协议设计的一部分,用于确保数据传输的可靠性。 为了解决服务器出现大量time_wait的问题,可以采取以下措施: 1. 调整服务器参数:可以通过修改服务器操作系统的参数来调整time_wait状态的时间。例如,可以减少time_wait状态的持续时间,以释放服务器资源。具体的操作方法可以参考操作系统的文档或相关文档。 2. 加大服务器资源:如果服务器出现大量time_wait的问题,可能是服务器的资源(例如端口号)不足造成的。此时,可以考虑增加服务器的资源,例如扩大服务器的端口范围等。 3. 优化应用程序代码:服务器出现大量time_wait可能是应用程序代码设计不佳造成的。在应用程序中,可以优化代码,以减少TCP连接的数量和时间。例如,可以使用连接池来重用连接,或者调整连接关闭的时机。 4. 负载均衡和故障转移:如果服务器经常出现大量time_wait,可能是由于服务器负载过高或单点故障引起的。此时,可以考虑使用负载均衡和故障转移技术来分散流量和提高服务器的可用性,从而减少time_wait的数量。 总之,彻底理解并解决服务器出现大量time_wait的问题需要对网络协议、服务器参数和应用程序代码等方面有一定的了解。通过调整参数、加大服务器资源、优化代码以及使用负载均衡和故障转移等技术,可以有效地减少time_wait的数量,提高服务器的性能和可靠性。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值