Linux同时开启tcp_tw_recycle和tcp_timestamps导致TCP syn有时不响应故障排查

本文介绍了在多台PC通过NAT访问同一Linux服务器时,由于TCP时间戳选项和TCP_TW_RECYCLE设置导致的TCP握手失败问题。分析了PAWS机制的影响,并提供了解决方案,即关闭net.ipv4.tcp_tw_recycle参数。同时,注意到Linux内核4.12以后不再支持tcp_tw_recycle,并且建议保持net.ipv4.tcp_timestamps以获取准确的RTT信息。

问题描述

前几天,同事反馈从公司连接线上一台服务器有时候会失败,经过抓包发现,TCP握手过程失败。查了相关资料,发现是跟net.ipv4.tcp_tw_recyclenet.ipv4.tcp_timestamps两个参数有关,将net.ipv4.tcp_tw_recycle改为0,问题解决。

排查过程

在PC上通过wireshark抓包发现,失败的时候,TCP syn包是一直在重传的。在server端通过tcpdump抓包发现,PC侧发的syn包是已经到达,所以基本排除网络问题。tcpdump抓包中确实看不到server端响应的syn-ack,所以基本判定问题出在server段,接下来就是分析为啥server端不响应。
net.ipv4.tcp_tw_recycle = 1net.ipv4.tcp_timestamps = 1同时间开启,当多个PC经过NAT设备访问同一server的时候,受TCP PAWS(Protect Against Wrapped Sequence Numbers)影响,后发起连接的PC可能因为tcp options中的timestamp比前面PC的timestamp小,而导致syn不被响应。
linux服务器上可以通过netstat -s查看是否存在该问题。如果多次执行下面的命令,发现数字再增加,说明存在该问题,而且现在还在发生。

[root@anonymous ~]# netstat -s | grep "connections rejected because of time stamp"
    26 passive connections rejected because of time stamp
[root@anonymous ~]#

关于PAWS的检查机制,是对于处于TIME_WAIT状态的tcp连接的对端IP,为了防止来自同一IP的延迟数据的干扰,需要在60秒(#

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值