为什么 Linux 内核协议栈会丢弃 SYN 数据包

最近了解到 SYN 数据包丢弃的问题，网上有一些资料，这里记录分享一下。

serverfault上的重要信息

tcp - No SYN-ACK Packet from server - Server Fault

信息如下：

        My embedded system with LwIP is the client and I have server1 and server2. I connected to server1 and end the connection before connecting to server2.

Further breakdown on the flow:

1. Client creates New Socket with server1
2. Client sent DNS packet to obtain server1's ip address; received ACK from AP
3. Client send TCP SYN packet;
4. Server1 send TCP SYN-ACK and perform some data transmission
5. Client ends connection with server1 by sending TCP RST packet; and close socket
6. Client creates New Socket with server2
7. Client sent DNS packet to obtain server2's ip address; received ACK from AP
8. Client send TCP SYN packet to server2
9. Server2 send TCP SYN-ACK and perform some data transmission
10. Client ends connection with server2 by sending TCP RST packet; and close socket

        However, sometimes server2 did not response to client's SYN Packet which is in Step 9. Its only happens sometime. I checked several forum like:

[1] Why would a server not send a SYN/ACK packet in response to a SYN packet

[2] Server not sending a SYN/ACK packet in response to a SYN packet

主要就是关闭下面配置：

sysctl -w net.ipv4.tcp_timestamps=0
sysctl -w net.ipv4.tcp_tw_recycle=0

或设置

cat /etc/sysctl.conf 

net.ipv4.tcp_tw_recycle = 0
net.ipv4.tcp_tw_reuse = 0
net.ipv4.tcp_window_scaling = 0
net.ipv4.tcp_timestamps = 0

下面翻译自：Why Are Linux Kernel Protocol Stacks Dropping SYN Packets - Alibaba Cloud Community

SYN 数据包丢弃

        在排除网络问题时，经常会遇到 TCP 连接失败的情况。如果能获取到两端抓到的数据包，则数据包如下：

• 客户端一直在以指数退避方式重新传输 TCP SYN。

这是因为第一个数据包还没有获得RTT和RTO，会在1、2、4、8秒左右重传，直到net.ipv4.tcp_syn_retries重传完成。

• 在服务器端可以看到TCP SYN包已经到达网卡，但是没有返回TCP包。

        这个问题出现的比较频繁。本博客将重点讨论与 TCP 协议栈相关的网络问题。对于TCP协议栈来说，我们指的是相关的网络问题可能是这样的情况：TCP SYN包可能已经到达了内核的TCP处理模块，但是根据服务器端内核代码却没有给客户端返回SYNACK。客户端持续重传TCP SYN也可能是由其他原因造成的，比如服务器端多个网卡导致访问路径不一致，或者SYN报文被规则拦截iptables，但这里不讨论这些。相反，我们将关注最常见的原因。

处于监听状态时处理 TCP SYN

        在本教程中，我们将使用广泛使用的CentOS 7内核版本。在本教程中，我们首先看一下TCP处理SYN的主要逻辑，并根据案例处理经验分析可能出现问题的点。Listen状态下的socket处理第一个TCP SYN报文的逻辑如下：

tcp_v4_do_rcv() @net/ipv4/tcp_ipv4.c
        |--> tcp_rcv_state_process() @net/ipv4/tcp_input.c // This functiuon implements the processing of accept messgaes in the vast TCP state (except for ESTABLISHED and TIME-WAIT), including of course the LISTEN state we are interested in.
                |--> tcp_v4_conn_request() @@net/ipv4/tcp_ipv4.c // When the TCP socket is in the LISTEN state and the TCP SYN flag is in the received message is set, it comes to this function.

        CentOS中的内核代码可能会略有调整。如果您需要跟踪源代码中的确切行数，systemtap是一种适合此目的的方法，如下所示：

# uname -r
3.10.0-693.2.2.el7.x86_64
# stap -l 'kernel.function("tcp_v4_conn_request")'
kernel.function("tcp_v4_conn_request@net/ipv4/tcp_ipv4.c:1303")

在tcp_v4_conn_request()的代码中，前几行函数逻辑如下：

        进入该函数的前提是TCP套接字处于Listen状态，并且接收到的数据包中设置了TCP SYN标志。进入函数逻辑后，我们可以发现函数应该考虑各种可能出现的异常，但很多异常其实并不那么常见。比如前几行的两种情况：

1. 第1482行：拒绝发送到广播和组播的数据包。
2. 1490行：如果请求队列（存放SYN包的队列）已满，则isn为0，为want_cookiefalse，则丢弃SYN包。

        第一种情况比较容易理解，实际中还没有见过。但是，第二种情况稍微复杂一些，在实际中也有一定概率会遇到。下面我们就来看看：

        第一个条件，请求队列已满，其实很容易满足。syn 洪水攻击很容易导致这种情况发生。TCP_SKB_CB(skb)->isn 的分配与函数开头的when相同。这是用于计算 TCP 控制块结构中的 RTT 的字段。表示want_cookie是否使用syn syncookies方法。它在tcp_syn_flood_action()中的定义如下。如果ifdef前面添加CONFIG_SYN_COOKIES，并且内核参数net.ipv4.tcp_syncookies也设置为1，则摘要返回 true，因此want_cookie返回为true。

        因此，在上述丢弃SYN数据包的情况下，真正的前提条件是内核参数net.ipv4.tcp_syncookies未启用。但在实际生产系统中，参数net.ipv4.tcp_syncookies是默认启用的。Syn syncookies是一种通过以时间（CPU计算）换取空间（请求队列）来防御syn Flood攻击的方法。在实际生产中，任何场景都不需要显式关闭该开关。所以一般来说，1490行的请求并不是很常见。

内核丢弃SYN数据包的主要场景

        下面介绍两种主要可能导致SYN包丢失的场景以及如何快速判断服务器不返回SYNACK的原因。

1. 每主机 PAWS(Protect Against Wrapped Sequences ) 检查导致 SYN 数据包丢失

症状

        这是实际生产环境中最常见的问题：对于同时启用了net.ipv4.tcp_tw_recycle和 的服务器net.ipv4.tcp_timestamps，当服务器有 NAT 客户端访问时，出现此问题的概率非常高。从客户端来看，这个问题的症状是新连接不稳定。有时可以连接，有时不能连接。

每主机 PAWS 原则

        有关背景信息，PAWS 是 Protect Against Wrapped Sequences 的缩写，这是一种防止序列号被包装的方法。接下来，Per-host 检查对等主机的 IP 地址，而不是 IP 端口的四元组。

        每主机PAWS检查的方式如下：对于快速回收的TIME_WAIT套接字的五元组对等主机IP，这有助于防止来自同一主机的旧数据的干扰。因此，新 SYN 数据包的 TCP Timestamps 选项需要在 60 秒内增加。当客户端处于NAT环境中时，这个条件往往不容易满足。

        理论上，只需要记住上面这句话，就可以解决很多客户端三向握手时而连通、时而断开的问题。欲了解更多信息，请参阅下面的详细解释。

为什么存在单主机 PAWS？

RFC 1323中提到了每主机 PAWS ，如下：

• 允许旧的重复段过期。为了取代 TIME-WAIT 状态的这一功能，必须有一种跨连接操作的机制。PAWS 严格定义在单个连接内；最后一个时间戳是 TS.Recent 保存在连接控制块中，并在连接关闭时丢弃。
• 可以向 TCP 添加一个附加机制，即从任何连接接收到的最后时间戳的每主机缓存。然后，如果可以保证时间戳时钟自旧连接打开以来至少已滴答一次，则可以在 PAWS 机制中使用该值来拒绝连接早期版本中的旧重复段。这要求 TIME-WAIT 延迟加上 RTT 必须至少是发送方时间戳时钟的一个刻度。此类扩展不属于本 RFC 提案的一部分。
• 请注意，这是 Garlick、Rom 和 Postel [Garlick77] 提出的机制的一个变体，该机制要求每个主机维护包含每个连接上的最高序列号的连接记录。如果使用时间戳，则只需为每个远程主机保留一个数量，而不管到该主机的同时连接数是多少。

需要TIME_WAIT的原因在.的代码注释tcp_minisocks.c中也有解释。而PAWS机制，TIME_WAIT快速回收的理论基础如下：

• TIME-WAIT 状态的主要目的是，当其中一端处于 LAST-ACK 或 CLOSING 重传 FIN（可能还有数据尾部）并且一个或多个 ACK​​ 丢失时，优雅地关闭连接。
• 什么是TIME-WAIT超时？它与互联网中的最大数据包生存期相关，这会导致错误的结论，即它被设置为捕获偏离其路径的“旧重复段”。这并不完全正确。该超时的计算方式使其超过最大重传超时，足以允许丢失由对等方发送的一个（或多个）分段和我们的 ACK。这个时间可以根据RTO来计算。
• 当TIME-WAIT套接字收到RST时，意味着另一端终于关闭了，我们也可以杀死TIME-WAIT。
• TIME-WAIT 的第二个目的是捕获旧的重复段。好吧，这当然是纯粹的偏执，但如果我们用这种语义加载 TIME-WAIT，我们就不能用 RST 杀死 TIME-WAIT 状态。
• 如果我们发明一些更聪明的方法来捕获重复项（基于 PAWS），我们可以将 TIME-WAIT 截断为多个 RTO。

        根据上面RFC的描述以及内核代码注释，我们可以看出Linux内核对状态实现了快速回收机制TIME-WAIT。Linux可以丢弃60秒的TIME-WAIT时间，直接缩短到RTO时间的3.5倍，因为Linux使用了一些“聪明”的方法来捕获旧的重复数据包（例如，基于PAWS机制）。相比之下，Linux 确实使用每主机 PAWS 来防止先前连接中的数据包被包装到新连接中。

Linux 内核实现

        在tcp_ipv4.c中，在收到 SYN 之前，如果满足以下两个条件，则检查对等体是否经过验证，即执行每主机 PAWS 检查：

• 接收到的数据包具有 TCP 时间戳选项。
• 计算机上启用了内核参数net.ipv4.tcp_tw_recycle。

...
else if (!isn) {
/* VJ's idea. We save last timestamp seen
 * from the destination in peer table, when entering
 * state TIME-WAIT, and check against it before
 * accepting new connection request.
 *
 * If "isn" is not zero, this request hit alive
 * timewait bucket, so that all the necessary checks
 * are made in the function processing timewait state.
 */
if (tmp_opt.saw_tstamp &&  // The report contains TCP timestamp option
    tcp_death_row.sysctl_tw_recycle &&  // The net.ipv4.tcp_tw_recyclekernel parameter is enabled.
    (dst = inet_csk_route_req(sk, &fl4, req)) != NULL &&
    fl4.daddr == saddr) {
    if (!tcp_peer_is_proven(req, dst, true)) {  // peer  (per-host PAWS)
        NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_PAWSPASSIVEREJECTED);
        goto drop_and_release;
    }
}

        在tcp_metrics.c中，Linux per-host PAWS 的实现逻辑如下。简单来说，正如本节开头提到的：新的SYN数据包的TCP Timestamps选项需要在60秒内增加。

bool tcp_peer_is_proven(struct request_sock *req, struct dst_entry *dst, bool paws_check)
{
    struct tcp_metrics_block *tm;
    bool ret;
    ...
    
    tm = __tcp_get_metrics_req(req, dst);
    if (paws_check) {
      if (tm &&
          // peer information is saved within 60 seconds (TCP_PAWS_MSL)之内
          (u32)get_seconds() - tm->tcpm_ts_stamp < TCP_PAWS_MSL &&
          // Compared with the timestamp in the current(TCP_PAWS_WINDOW)
          (s32)(tm->tcpm_ts - req->ts_recent) > TCP_PAWS_WINDOW)
        ret = false;
      else
        ret = true;
    }
}

NAT 环境中对客户端的影响

        当这种允许TIME-WAIT状态快速回收的每主机PAWS机制在Linux中实现时，它被设计为基于具有足够数量的IPv4地址池的网络环境的解决方案。然而，随着互联网的快速发展，NAT的应用越来越普遍，客户端在SNAT设备内访问同一台服务器的情况也很常见。

        Per-host PAWS 机制通过 TCP Timestamps 选项字段的增加来确定包装的数据，而时间戳是根据每个客户端的 CPU 滴答数获得的值，可以说在 NAT 设备内是完全随机的。当客户端主机1通过NAT与服务器建立TCP连接，然后服务器关闭并快速回收TIME-WAIT套接字时，其他客户端主机的新连接源IP与服务器对等表中记录的相同，但TCP Timestamps选项是完全随机的或者与主机1当时记录的时间戳相比有50%的概率是随机的。如果时间戳小于主机1的时间戳，则60秒内新连接将被拒绝，60秒后新连接将成功。如果时间戳大于主机1的时间戳，则新连接直接成功。所以，从客户端来看，这个问题的症状就是新连接不稳定。有时可以连接，有时不能连接。

        这就是NAT环境下客户端使用TIME-WAIT快速回收机制带来的副作用。这种副作用在每主机 PAWS 机制设计之初就无法预料到，因为当时的网络环境与现在有很大不同。在当前的网络环境下，唯一的建议是禁用TIME-WAIT快速回收，即制作net.ipv4.tcp_tw_recycle=0. 禁用net. ipv4.tcp_timestamps删除 TCP 时间戳选项也可以解决此问题。但由于时间戳是计算RTT和RTO的基础，因此一般不建议禁用。

故障排除

        在实际生产中，排除故障并不容易。但对于同时启用了net.ipv4.tcp_tw_recycle和 的net.ipv4.tcp_timestamps服务器，当服务器有 NAT 客户端访问时，出现此问题的概率非常高，所以如果获取了这两个内核参数的设置以及客户端网络的 NAT 环境，就可以做出基本的判断。

        另外，您可以参考 中的统计数据netstat -s，该统计数据来自/proc/net/snmp、/proc/net/netstat和/proc/net/sctp/snmp。如下所示，该统计值表示有多少新连接因时间戳而被拒绝。这是历史统计总计，因此两个时间点之间的差异对于故障排除更有意义。

xx passive connections rejected because of time stamp

2. 接受队列已满导致 SYN 数据包丢失

症状

        不存在统一的、有规律的现象。当 TCP 接受队列已满时会发生这种情况。当用户空间应用程序出现问题时，通常会发生这种情况。一般来说，发生的概率不是很高。

原则

        接受队列翻译为全连接队列或者接收队列。新连接经过三次握手后进入接受队列。用户空间应用程序调用accept系统调用来获取连接并创建一个新的套接字，返回与该套接字关联的文件描述符（fd）。在用户空间，可以使用poll等机制，通过可读事件获知已经完成3次握手的新连接已进入accept队列，收到通知后可以立即调用accept系统调用来获取新连接。

        接受队列的长度是有限的。长度取决于 min [backlog, net.core.somaxconn]，它是两个参数中较小的一个。

• Backlog是应用程序调用Listen系统调用时的第二个参数。请参考#include 中的 int Listen(int sockfd, int backlog) 。
• Net.core.somaxconn 是系统内核参数。默认值为128。当应用程序监听时，如果设置的backlog较大（例如NGINX默认为512），并且全局内核参数没有调整，则accept队列的长度仍然会由较小的net.core.somaxconn决定。

        即使在并发连接数较多的情况下，应用程序正常使用accept系统调用获取accept队列中的连接也不会因为效率问题而被延迟。但是，如果由于应用程序阻塞而未能及时获得连接，则可能会导致接受队列已满，从而导致新的 SYN 数据包被丢弃。

Linux 内核实现

        在tcp_ipv4中，“当接受队列已满时拒绝 SYN 数据包”的实现非常简单，如下：

/* Accept backlog is full. If we have already queued enough
 * of warm entries in syn queue, drop request. It is better than
 * clogging syn queue with openreqs with exponentially increasing
 * timeout.
 */
//If accept queueis full, and SYN queuehas a semi-join that has not been retransmitted by SYNACK, the SYN request is discarded.
if (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
  NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
  goto drop;
}

在sock.h中，定义了完整接受队列的内联函数：

static inline bool sk_acceptq_is_full(const struct sock *sk)
{
    return sk->sk_ack_backlog > sk->sk_max_ack_backlog;
}

inet_connection_sock.h和request_sock.h中定义了判断SYN队列中是否存在未重传SYNACK的半连接的方法：

static inline int inet_csk_reqsk_queue_young(const struct sock *sk)
{
    return reqsk_queue_len_young(&inet_csk(sk)->icsk_accept_queue);
}

static inline int reqsk_queue_len_young(const struct request_sock_queue *queue)
{
    return queue->listen_opt->qlen_young;
}

        以上是3.10中的实现。其实我们需要判断两个条件：“accept队列是否已满”和“SYN队列是否有没有SYNACK重传的半连接”。当接受队列已满时，通常会存在大量新连接，因此通常会同时满足第二个条件。如果SYN队列没有半连接，即当接受队列满时还没有重传SYNACK，Linux内核仍然接受SYN并返回SYNACK。这种情况在实际生产中很少见，除非应用程序进程完全停止，例如使用SIGSTOP信号停止进程。所以当accept队列满时，TCP内核协议栈仍然不会直接丢弃SYN数据包。

        由于接受队列已满而丢弃 SYN 的逻辑在较新的内核版本中略有变化。例如4.10中，判断条件由2个变为1个，即内核只判断accept队列是否已满。因此，在这些版本中，当接受队列已满时，内核将直接丢弃SYN数据包。

故障排除

        当用户空间应用程序出现问题时，通常会发生这种问题。一般来说，发生的概率不是很高。可以通过以下两种方法来确认该问题：

使用ss命令查看实时问题

        使用 ss 命令的选项 -l 检查监听套接字。显示 Recv-Q 和 Send-Q。Recv-Q表示当前accept队列的总连接数，Send-Q表示accept队列的最大长度。如下所示： 几个进程默认的accept队列是128，因为受到net.core.somaxconn=128系统的限制。

Netstat -s 统计

        参考netstat -s 中的统计信息。下面的统计值表示由于套接字溢出而被拒绝的新连接数。同样，这也是一个历史统计总计，两个时间点之间的差异对于故障排除更有意义。

xx times the listen queue of a socket overflowed

建议的解决方案

        如果确认SYN包被丢弃是由于accept队列的原因，那么很自然地想到解决办法就是增加accept队列的长度。同时增加backlog和net.core.somaxconn参数可以增加accept队列的长度。

        但一般来说，这种方法只能缓解问题，最有可能的情况是加长的accept队列很快又被填满。因此，解决这个问题的最好方法是检查应用程序，看看为什么它接受新连接的速度这么慢，解决根本原因。

概括

        本博客文章的主体总结了两个主要场景，主要是与云基础设施和服务软件层相关的问题，其中 SYN 由于每主机 PAWS 检查和完整接受队列而被丢弃。这两种情况涵盖了绝大多数 TCP 堆栈丢弃 SYN 的情况。如果其他协议栈出现SYN丢包，则需要结合参数配置和代码逻辑进一步具体排查。

参考

tcp - No SYN-ACK Packet from server - Server Fault

Why Are Linux Kernel Protocol Stacks Dropping SYN Packets - Alibaba Cloud Community