Linux默认开启TCP时间戳导致syn-ack不能返回（不能返回响应数据）

HaleyTiger

已于 2022-10-03 12:13:23 修改

阅读量3.2k

点赞数 2

分类专栏： linux相关文章标签： linux tcp/ip 服务器

于 2022-08-13 16:21:13 首次发布

本文链接：https://blog.youkuaiyun.com/hu1010037197/article/details/126320392

版权

linux相关专栏收录该内容

50 篇文章

订阅专栏

问题：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

注：修改保存，令配置生效期间，如果系统间存在通信，可能导致期间通信异常！！！