关于某系统阵发性网络问题的处理。

探索Linux内核优化带来的隐秘网络问题：记录net.ipv4.tcp_timestamps与net.ipv4.tcp_tw_recycle内核开启状态对高并发的Linux高可用调度器节点和负载均衡节点的影响。这两个参数原本配合用于抵御DDoS与CC洪水攻击，然而在面对同一公网IP的客户端请求时，却引发了巨大的网络影响。详细记录了排查故障的过程，包括问题的再现、抓包分析、问题的定位和解决。通过深入剖析，我们揭示了内核优化可能带来的意外后果，以及如何妥善解决这些问题。

[toc]

关于某系统阵发性网络问题的处理。

一、问题描述

1、xxx 、移动 xx 等系统阵发性网络连接失败;
2、keepalived 虚拟ip未发生切换，nginx 访问日志记录正常，未收到错误日志，网络及链路测试正常;
3、keepalvied+ nginx 反代的其余系统未发现阵发性网络问题;
4、修改本地解析到keepalived虚拟ip，XXX相关系统访问正常。

二、应急切换与故障重现

1、周二频繁出现阵发性网络连接失败，应急将XXX虚ip切换回原私有云服务器，系统恢复;
2、后考虑移动xx系统出现的网络问题频率较高，因此考虑在个人客户端重现故障;
3、在个人macos中搭建dns服务器，配置xx域名解析到非XXX 系统keepavlied虚ip所映射的公网ip;
4、在手机上刷新app，多次刷新，锁屏再打开后故障重现。

三、问题定位

1、故障重现后，在XXX系统 keepailved 所在的服务器上进行 tcpdump 抓包分析;
2、因目前只有一个客户端访问非XXX nginx，因此可以看到nginx日志是一个公网ip访问过来的;
3、开启两个终端，一个实时监控日志，另一个用于tcpdump抓包保存

# tail -f /var/log/nginx/oa.huatu.com.log 
# tcpdump -i team1 -s 0 -n 'host xxx.xxx.xxx.xxx' -w /tmp/xx_packet.pcap

4、当app端问题复现后，发现nginx 未记录日志, 将 xx_packet.pcap 导出，用wireshark 导出分析
5、发现有三次tcp请求是正常进入网卡的，但是服务器没有回应，问题定位在服务器网络层面;
6、google搜索 linux tcp 没有回包，发现原理是由以下两个参数导致的
7、net.ipv4.tcp_timestamps net.ipv4.tcp_tw_recycle;
8、发现服务器上的net.ipv4.tcp_timestamps，net.ipv4.tcp_tw_recycle 都为1;

四、故障处理

修改两台服务器的 /etc/sysctl.conf 以下两条内核参数，并生效;

# vim  /etc/sysctl.conf
net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_timestamps = 0 

# sysctl -p 生效

将keepalived 虚拟ip再切换回物理服务器，故障处理;

五、内核参数说明;

1、net.ipv4.tcp_timestamps 是给所有进入服务器网卡的流量打时间标签，就像生产的面包打印生产日期;
2、net.ipv4.tcp_tw_recycle 是对连接时间超过60s的tcp资源进行回收并reject，同一时间内同一ip访问过多的tcp连接，它只会认为最近的一次SYN有效，其余的SYN拒绝;
这两条参数配合起来，当都开启时用于防范tcp攻击;
3、这两个参数结合起来是为了防止同一ip的tcp攻击，因同一局域网内是同一个公网ip，故造成同一局域网内多人访问时，SYN被拒绝，报网络错误，这也解释了为何非XXX业务访问未出现这样的问题、通过修改本地host解析直接访问私网ip未出现这样的问题。