问题：TCP时间戳导致syn-ack没有返回（不能返回正常响应数据）
客户端A通过NAT网关访问应用服务成功，而客户端B通过NAT网关访问 应用服务经常性出现connect失败。在服务端抓包发现：服务端已经收到了syn包，但没有回复synack包；客户端A 关闭了tcp_tw_recycle，而客户端B开启了tcp_tw_recycle；据当事人称开启 tcp_tw_recycle 是为了减少tcp的TIME_WAIT状态。
linux默认启用时间戳（/etc/sysctl.conf）：
由于net.ipv4.tcp_tw_recycle=1、net.ipv4.tcp_timestamps=1均开启产生的问题（tcp_tw_recycle=1表示：开启TCP连接中TIME-WAIT sockets的快速回收）
net.ipv4.tcp_timestamps=1
tcp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。（默认开启）
说明： Linux启用了时间戳导致syn-ack没有返回，原理如下：
tcp 三次握手，如果有一个用户的时间戳大于这个链接发出的syn中的时间戳，服务器上就会忽略掉这个syn，不返会syn-ack消息，表现为用户无法正常完成tcp3次握手，从而不能打开web页面（或不能返回正常响应数据）。 在业务闲时，如果用户的NAT（网络地址与接口号转换NAPT）端口没有被使用过时，就可以正常打开；业务忙时，NAT端口重复使用的频率高，很难分到没有被使用的端口，从而产生这种问题。
通过查阅资料，发现tcp_timestamps默认是开启，如果再把tcp_tw_recycle设置为1，则60s内同一源ip主机的socket connect请求中的timestamp必须是递增的。
也就是说服务器打开了 tcp_tw_reccycle了，就会检查时间戳，如果对方发来的包的时间戳是乱跳的或者说时间戳是滞后的，这样服务器肯定不会回复，所以服务器就把带了“倒退”的时间戳的包当作是“recycle的tw连接的重传数据，不是新的请求”，于是丢掉不回包，就出现了开始说的syn不响应。
只有客户端和服务端都开启时间戳的情况下，才会出现能ping通不能建立tcp三次握手的情况
netstat -s | grep timestamp
问题分析：
大致可以推测上述问题和tcp_tw_recycle有关，查看linux内核对应的代码
tcp_v4_conn_request()函数：
if (tmp_opt.saw_tstamp &&
tcp_death_row.sysctl_tw_recycle &&
(dst = inet_csk_route_req(sk, req)) != NULL &&
(peer = rt_get_peer((struct rtable *)dst)) != NULL &&
peer->v4daddr == saddr) {
if (get_seconds() < peer->tcp_ts_stamp + TCP_PAWS_MSL &&
(s32)(peer->tcp_ts - req->ts_recent) > TCP_PAWS_WINDOW) {
goto drop_and_release;
}
}
其中：
sysctl_tw_recycle：本机系统开启tcp_tw_recycle选项
TCP_PAWS_MSL：60s，该条件判断表示该源ip的上次tcp通讯发生在60s
TCP_PAWS_WINDOW：1，该条件判断表示该源ip的上次tcp通讯的timestamp 大于 本次tcp。
tmp_opt.saw_tstamp：该socket支持tcp_timestamp
简单说就是在tcp_tw_recycle/tcp_timestamps都开启的条件下，60s内同一源ip主机的tcp 链接请求中的timestamp必须是递增的。
结合问题分析：
主机client1和client2通过NAT网关访问服务时，而client1和client2的timestamp（tcp报文的时间戳与系统时钟有关）不相同； 根据上述syn包处理源码，在tcp_tw_recycle和tcp_timestamps同时开启的条件下，timestamp大的客户端访问服务成功，而timestmap小的主机访问失败。
解决方法分析：
echo 0 > /proc/sys/net/ipv4/tcp_tw_recycle;
tcp_tw_recycle默认是关闭的。 为了解决上述问题，需要建议关闭tcp_tw_recycle选项，而不是timestamp；因为 在tcp timestamp关闭的条件下，开启tcp_tw_recycle是不起作用的； tcp_timestamp选项开启，可以提高TCP RTT的计算精度，提高TCP的性能。linux许多参数调优，需要根据业务场景以及参数背景的工作原理进行综合考虑，不存在一个配置文件搞定所有问题的情况。
进一步深入
上面的代码究竟是处于什么考虑呢？是BUG吗？实际上这个属于TCP协议栈的PAWS机制的逻辑。PAWS (Protection Against Wrapped Sequence numbers)，防止序号回绕。
tcp报文头中使用了32位的整数做序号。在高速网络中，一个TCP链接的tcp序号很快就会出现回绕的情况。
例如，下图中之前消息的序号为A的数据包，由于网络路径或其他原因刚好在当前数据流要接收序号为A的数据包时，又被服务端收到， 那么服务端就错误地把这个数据包当做新消息的一部分，从而可能会导致上层业务使用错误数据。
在通过实际数据计算看一下，感受一下发送回绕需要的网路速度。假设网络带宽为B bytes/s，那么序号回绕的时间为 2^31/B。对于 1Gbps速率（125MBps），计算一下，发现只需要17秒就序号就回绕了，而TCP标准中MSL（Maximum Segment Lifetime）是2分钟。
为了避免这种情况的发送，需要TCP的PAWS机制，而为了说清楚PAWS，就需要说一下tcp timestamp。
如上所示，开启tcp timestamp时，发送端的报文携带时间戳，接受端接受到报文进行应答时，会把发送的时间戳再返回给发送端。这样发送端可以有效计算TCP的RTT值。这是tcp timestamp的一个功能，另一个功能就是用于PAWS。
PAWS如何解决序号回绕问题呢？ 由于接收的每个数据包都携带了时间戳，对于一个TCP链接来说，数据包的时间戳是单调递增的，所以若数据包时间戳的数值小于当前链接已处理数据包的时间戳，那么就认定序号发生了回绕，将消息丢弃。
【最终解决方法】：
在默认 /etc/sysctl.conf 文件中添加或修改（只修net.ipv4.tcp_timestamps=0即可）为：
关闭net.ipv4.tcp_tw_recycle=0、net.ipv4.tcp_timestamps=0（两者都关闭，或关闭任意一个即可）
net.ipv4.tcp_tw_recycle=0
# 禁用时间戳
net.ipv4.tcp_timestamps=0
#允许系统打开的端口范围
net.ipv4.ip_local_port_range = 1024 65000
保存后，执行命令（令修改生效）：
sysctl -p
注：修改保存，令配置生效期间，如果系统间存在通信，可能导致期间通信异常！！！
