一次服务端不响应报文情况

服务端不响应报文情况

 

 

原因是公司换了一套VPN现在为NAT网络模式，然后生产出现偶发性的页面无法连接问题，下面是排查处理结果

1.访问流程

2.问题现象

在旧版切换为新Vpn之后用户访问堡垒机首页，偶发性出现连接异常提示连接超时，没有规律日志没有报错，然后和vpn那边沟通他们也没有明确回复vpn的旧版新版差异性问题导致走了一堆弯路

 

 

 

3.排查思路

（1）网络排查

开始以为网络问题测试本地连接Vpn可以Ping和Telnet通Nginx但是访问不到时候Telnet端口不通（Telnet为应用层协议）

 

（2）前端日志排查

然后排查应用Nginx日志报错为：根据报错没有有用信息报错端口是图形化桌面端口

 

 

 

（3）后端应用排查

然后直接不通过Nginx代理直接访问后端IP进行访问应用来测试看看是否是应用

 

问题，发现直接访问应用不会出现断开连接丢包现象

 

（4）前端应用排查

在想是不是Nginx代理转发出了问题然后直接访问前端Nginx真实IP进行测试、也是一直可以打开页面没有出现断开连接超时情况。

 

（5）资源排查

Top看了资源占用情况发现剩余资源都在百分95以上不存在资源不够情况，又看Nginx连接数量和Tcp连接数远远没有达到最大标准。

 

（6）抓包测试

进行抓包测试当页面出现不能访问情况时服务端可以收到客户端发来数据包、但是服务端没有响应

 

遂www.baidu.com服务端接收数据包不回复原因，查询到两个Linux进程参数

 

tcp_tw_recycle

Enable fast recycling of TIME-WAIT sockets. Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation).

启用TIME-WAIT状态sockets的快速回收，这个选项不推荐启用。在NAT(Network Address Translation)网络下，会导致大量的TCP连接建立错误。

tcp_timestamps

 

1发送方在发送数据时，将一个timestamp(表示发送时间)放在包里面

 

2接收方在收到数据包后，在对应的ACK包中将收到的timestamp返回给发送方(echo back)

 

3发送发收到ACK包后，用当前时刻now - ACK包中的timestamp就能得到准确的RTT

 

 

当tcp_tw_recycle和tcp_timestamps同时打开时会激活TCP的一种隐藏属性：缓存连接的时间戳。

60秒内，同一源IP的后续请求的时间戳小于缓存中的时间戳，此时linux内核就会认为这个数据包异常的，因此就会丢掉这个包，并发送rst。

在NAT的环境下，由于公网ip是一样的，就很有可能出现请求连接被断开的现象。

 

 

 

均为开启状态，了解到tcp_timestamps为时间戳tcp_tw_recycle是快速回收处理TIME_WAIT状态的socket，当tcp_tw_recycle为1是开启状态，然后修改为0就可以了

echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle

 

 

 

 

4 . 总结

（以下为个人理解，如有不对欢迎大佬补充讨论）

 

大概意思就是当网络模式为NAT（可能旧版VPN不是大家共用一个IP所以没出现这个情况）连接用户都为一个IP发送到服务端数据包源IP一致，但是时间戳不同但是用户访问时候每个人有每个人对应的访问时间戳，当其中一个用户断开了连接之后他会短暂处于一个TIME_WATI状态，然后开启了tcp_tw_recycle之后系统会在一个RTO的极短时间内回收处于TIME_WAIT状态的socket但是同时他还会接收到之前连接了此页面的用户发来的数据包，然后就会进行判断时间戳如果是老报文，则丢弃且不回复。

 

5.处理方法

netstat -s |grep reject 查询到被动拒绝的连接数

 

当tcp_tw_recycle为1时在不断增长被动拒绝连接数

 

然后修改为0就可以了

echo "0" > /proc/sys/net/ipv4/tcp_tw_recycle

 

 

原文链接：https://blog.csdn.net/qq_42514511/article/details/119039007