1,登陆服务器查看资源使用top,vmstat等命令查看了一番发现服务器各项指标都没有异常。于是将问题转向了网络层。
2,本地使用ping服务器外网ip正常返回,无丢包,延迟也正常。
3,登录服务器查看tcp相关数据。
发现在卡顿时有大量tcp syn包被丢弃,数值一直在增长。
在查阅资料并结合实际情况后,发现该服务器同时启用了 tcp_timestamps和tcp_tw_recycle参数。
后想起,之前同事为改善time_wait连接数过多问题曾改过该内核参数。
解决办法是,关闭tcp_tw_recycle:
再观察,发现服务已正常,偶尔连接不上的现象消失。
我们先来man一下这两个参数(man tcp):
cp_timestamp 是 RFC1323 定义的优化选项,主要用于 TCP 连接中 RTT(Round Trip Time) 的计算,开启 tcp_timestamp 有利于系统计算更加准确的 RTT,也就有利于 TCP 性能的提升。(默认开启)
关于tcp_timestamps详情请见: https://tools.ietf.org/pdf/rfc7323.pdf
开启tcp_tw_recycle会启用tcp time_wait的快速回收,这个参数不建议在NAT环境中启用,它会引起相关问题。
tcp_tw_recycle是依赖tcp_timestamps参数的,在一般网络环境中,可能不会有问题,但是在NAT环境中,问题就来了。比如我遇到的这个情况,办公室的外网地址只有一个,所有人访问后台都会通过路由器做SNAT将内网地址映射为公网IP,由于服务端和客户端都启用了tcp_timestamps,因此TCP头部中增加时间戳信息,而在服务器看来,同一客户端的时间戳必然是线性增长的,但是,由于我的客户端网络环境是NAT,因此每台主机的时间戳都是有差异的,在启用tcp_tw_recycle后,一旦有客户端断开连接,服务器可能就会丢弃那些时间戳较小的客户端的SYN包,这也就导致了网站访问极不稳定。
主机A SIP:P1 (时间戳T0) --->Server 主机A断开后
主机B SIP:P1 (时间戳T2) T2 <T0 --->Server 丢弃
经过此次故障,告诫我们在处理线上问题时,不能盲目修改参数,一定要经过测试,确认无误后,再应用于生产环境。同时,也要加深对相关内核参数的认识和理解。
本文解决灵感来自于 https://blog.51cto.com/hld1992/2285410
https://blog.csdn.net/chengm8/article/details/51668992
云服务器被ddos攻击最恶心了,尤其阿里云的服务器受攻击最频繁,因为黑客知道阿里云服务器的防御低,一旦被攻击就会进入黑洞清洗。轻则停服半小时,重则停2-24小时,给网站、 游戏 等带来很严重的损失。最好处理ddos攻击的方法就是防止,不要等到被攻击了再来防御。这样成本就远超攻击前的防御。如果有把柄在黑客手中 ,就更加麻烦了,所以事前防御才是上上策 。想避免 DDOS 攻击 ,务必先搞清楚 ,当今销售市场 99 %的DDOS攻击是对于 IP 以百G攻击流量导致网络服务器瘫患,以便做到攻击目的 ,因而 你务必防止服务器ip泄漏并掩藏 源ip ,那样黑客就无法找到源服务器ip ,也没法使用ddos有效地攻击你。
其实ddos的核心问题是成本低,而防御成本高。我所知道的今年国内应该出现了很多超200G的ddos攻击,而大部分公司都扛不住。今天飞飞就和你们分享一下解决方案。
对于低成本的防御方法,我给出几点建议:
1、挂cdn隐藏IP,在换成新的ip后,请务必挂cdn对真实的ip进行隐藏,这样无论怎样被攻击,cdn都可以为你进行抵御。
2、cdn不止可以套一层,可以多层一起嵌套,网络上免费的也不少。
准备多个服务器做反向代理(配置可以不高能运行nginx就行,最好是那种空路由时间短的),每个反向代理服务器都指向主服务器节点,都绑定一个二级域名,都挂上不同的cdn。
3、主域名可以随时解析到任意一个反向代理服务器,并且可以挂免费的云监控来实时监控服务器状态,一个节点死了改解析就行。
4、在防火墙层面禁止所有的国外ip(这是大部分肉鸡主要来源),可以很好地降低攻击流量。
以上是比较简单、低成本的方法,如果资金充足的话,建议购买高防服务器和高防IP等防御产品,这样针对不同场景不同的环节也有针对性的防御方案,无法一概而论,当然也看您遇到的对手是什么样的级别。
因此,避免服务器遭受ddos攻击的最好是方式就是把高防CDN布置好,不能让对方了解你的源服务器ip ,即便高防cdn其中一个节点被打死 ,还可以立即切换到其他备用节点上。
携手驰网一同 探索 (拥有一台服务器可以做哪些很酷的事情?)
欢迎分享,转载请注明来源:夏雨云
评论列表(0条)