大致网络拓扑如下：

业务刚上线，数据量不大，一直运行平稳未发现任何异常情况，直到智博会该系统拿到会场展示，访问量暴增，问题就出现了。

下午开始出现大量用户不能正常访问接口服务，部分业务瘫痪，搞得老夫头皮发麻，开始一系列紧张的排查：

首先排查业务日志，无任何报错现象，ZABBIX监控无异常，排查NGINX的access日志，没有发现大量访问日志，至此基本可以认定，业务访问请求报文还没到达nginx就已经被抛弃。

后续抓包也证明了果然如此，tcpdump抓包如下

Tcp握手全部失败，马上开始百度,谷歌查询问题，最后发现与sysctl.conf中2个参数有关：

修改前net.ipv4.tcp_timestamps的配置为1

按照网上所说改为0，问题立即解决。

为深入分析原因，下载对应版本的内核源码看了下

找到内核处理TCP连接函数：tcp_v4_conn_request，对于该设置的处理流程如下：

在tcp_v4_conn_request()方法中：

tmp_opt.saw_tstamp对应 net.ipv4.tcp_timestamps

tcp_death_row.sysctl_tw_recycle对应net.ipv4.tcp_tw_recycle

在该2个配置项都开起情况下会调用tcp_peer_is_proven()函数检查tcp发送的syn报文

tcp_peer_is_proven()函数处理片段如下

该if语句判断：该源ip的上次tcp通讯发生在60s内，且该源ip的上次tcp通讯的timestamp 大于本次tcp。

至此问题发生原因就很明显了：

由于多个个用户通过NAT网关（1个ip地址）访问server_1, server_2，由于timestamp时间为系统启动到当前的时间，因此，各个用户的timestamp不相同；根据上述syn包处理流程，在tcp_tw_recycle和tcp_timestamps同时开启的条件下，timestamp大的主机访问server_1, server_2成功，而timestmap小的主机访问失败；

所以占时关闭tcp_timestamps检查，后续要求NAT网关转发真实用户IP。

╮(╯▽╰)╭

[CTF入门培训]顶尖高校博士及硕士团队亲授《30小时教你玩转CTF》，视频+靶场+题目！助力进入CTF世界