net.ipv4.tcp_tw_recycle引发的故障

  • A+

netstat看到服务器上发现非常多的TIME_WAIT等待,于是百度了下让我开启net.ipv4.tcp_tw_recycle这个参数,改成1启用。然后后来发现go开发那边服务经常性的会有包发出去但是收不到回来的ack包的消息。后来想了一下这段时间是打开了这个开关。于是将它改为0关闭掉,sysctl -p生效以后,过了一段时间观察发现问题是解决了。

网上说开启net.ipv4.tcp_tw_recycle这个开关,可以快速回收处于TIME_WAIT状态的socket(针对Server端而言)。
而实际上,这个开关,需要net.ipv4.tcp_timestamps(默认开启的)这个开关开启才有效果。
更不为提到却很重要的一个信息是:当tcp_tw_recycle开启时(tcp_timestamps同时开启,快速回收socket的效果达到),对于位于NAT设备后面的Client来说,是一场灾难——会导到NAT设备后面的Client连接Server不稳定(有的Client能连接server,有的Client不能连接server)。也就是说,tcp_tw_recycle这个功能,是为“内部网络”(网络环境自己可控——不存在NAT的情况)设计的,对于公网,不宜使用。

我们在一些高并发的 WebServer上,为了端口能够快速回收,打开了 tcp_tw_reccycle ,而在关闭 tcp_tw_reccycle 的时候,kernal 是不会检查对端机器的包的时间戳的;打开了 tcp_tw_reccycle 了,就会检查时间戳,很不幸移动的cmwap发来的包的时间戳是乱跳的,所以我方的就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据,不是新的请求”,于是丢掉不回包,造成大量丢包

  • 我的微信
  • 扫一扫添加微信好友
  • weinxin
  • QQ群
  • 扫一扫加入QQ群
  • weinxin
allenjol

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: