访问服务时断时续连接超时三次握手只有SYN，没有ACK返回问题排查

同事反馈他们访问服务时断时续，页面经常会报连接超时的问题。F12时看到报的是net:ERR_CONNECTION_TIMED_OUT。出现该问题时过个1-2分钟又自行恢复。

客户访问的这个页面服务前面是nginx做转发，nginx前面挂的是阿里云的SLB

解决过程：
1、在其他办公网络环境下复现该问题，但一直没有复现成功
2、查看nginx日志，发现出问题时，nginx中没有任何日志，说明当时客户访问请求没有到达nginx
3、部署shell监控脚本，主要是通过nmap命令（nmap -P0 -n -p80 xx.xxx.xxx.xx |grep tcp |awk ‘{print $2}’ ）每30秒进行一次TCP探测，对SLB 和端口进行探测。发现频繁出现fililted的状态，然后恢复为open状态
4、通过在客户端和NGINX上分别进行tcpdump抓包测试（sudo tcpdump -vv -X -s 0 -i eth0 host xxx.xxx.xxx.xxx -w 17_35_c.cap）xxx.xxx.xxx.xxx代表另一端的外网IP地址，这个地方是客户端的出口IP，发现NGINX端有时出现只收到SYN，没有给客户端返回ACK的情况。

5、说明问题出在NGINX服务器上。因为nmap做的四层端口探测，客户端尝试与nginx建立连接，与后端服务没有关系（nginx做的七层http和https转发，没有做四层转发）

6、针对只有SYN，没有ACK的情况，百度一下，发现有的人通过修改tcp_tw_recycle等参数解决该问题。我们问题现象与其很像，最后也是通过该参数解决该问题

https://blog.csdn.net/zhuyiquan/article/details/68925707
解决：

echo “0” > /proc/sys/net/ipv4/tcp_tw_recycle

四、扩展

1，net.ipv4.tcp_timestamps

tcp_timestamps的本质是记录数据包的发送时间。基本的步骤如下：

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

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

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

当然实际运用中要考虑到RTT的波动，因此有了后续的(Round-Trip Time Measurement)RTTM机制。

TCP Timestamps Option (TSopt)具体设计如下：

Kind: 8 // 标记唯一的选项类型，比如window scale是3
Length: 10 bytes // 标记Timestamps选项的字节数
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Kind=8 | Length=10 | TS Value (TSval) | TS ECho Reply (TSecr) |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 1 4 4
timestamps一个双向的选项，当一方不开启时，两方都将停用timestamps。比如client端发送的SYN包中带有timestamp选项，但server端并没有开启该选项。则回复的SYN-ACK将不带timestamp选项，同时client后续回复的ACK也不会带有timestamp选项。当然，如果client发送的SYN包中就不带timestamp，双向都将停用timestamp。

tcp数据包中timestamps的value是系统开机时间到现在时间的（毫秒级）时间戳。

参数：

0：停用

1：启用(系统默认值)

2，net.ipv4.tcp_tw_recycle

TCP规范中规定的处于TIME_WAIT的TCP连接必须等待2MSL时间。但在linux中，如果开启了tcp_tw_recycle，TIME_WAIT的TCP连接就不会等待2MSL时间（而是rto或者60s），从而达到快速重用（回收）处于TIME_WAIT状态的tcp连接的目的。这就可能导致连接收到之前连接的数据。为此，linux在打开tcp_tw_recycle的情况下，会记录下TIME_WAIT连接的对端（peer）信息，包括IP地址、时间戳等。这样，当内核收到同一个IP的SYN包时，就会去比较时间戳，检查SYN包的时间戳是否滞后，如果滞后，就将其丢掉（认为是旧连接的数据）。这在绝大部分情况下是没有问题的，但是对于我们实际的client-server的服务，访问我们服务的用户一般都位于NAT之后，如果NAT之后有多个用户访问同一个服务，就有可能因为时间戳滞后的连接被丢掉。

参数：

0：停用(系统默认值)

1：启用