为什么 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](https://serverfault.com/questions/235965/why-would-a-server-not-send-a-syn-ack-packet-in-response-to-a-syn-packet?newreg=72fd3ad776724f3c8d5c33f22c320b1a "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](https://serverfault.com/questions/297134/server-not-sending-a-syn-ack-packet-in-response-to-a-syn-packet "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](https://www.alibabacloud.com/blog/why-are-linux-kernel-protocol-stacks-dropping-syn-packets_595251 "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_cookie`false，则丢弃SYN包。 第一种情况比较容易理解，实际中还没有见过。但是，第二种情况稍微复杂一些，在实际中也有一定概率会遇到。下面我们就来看看： 第一个条件，请求队列已满，其实很容易满足。syn 洪水攻击很容易导致这种情况发生。`TCP_SKB_CB(skb)->`isn 的分配与函数开头的when相同。这是用于计算 TCP 控制块结构中的 RTT 的[字段。](https://elixir.bootlin.com/linux/v3.10/source/include/net/tcp.h#L702 "字段。")表示`want_cookie`是否使用syn syncookies方法。[它在tcp_syn_flood_action()](https://elixir.bootlin.com/linux/v3.10/source/net/ipv4/tcp_ipv4.c#L890 "它在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](https://tools.ietf.org/html/rfc1323#page-28 "RFC 1323")中提到了每主机 PAWS ，如下： * 允许旧的重复段过期。为了取代 TIME-WAIT 状态的这一功能，必须有一种跨连接操作的机制。PAWS 严格定义在单个连接内；最后一个时间戳是 TS.Recent 保存在连接控制块中，并在连接关闭时丢弃。 * 可以向 TCP 添加一个附加机制，即从任何连接接收到的最后时间戳的每主机缓存。然后，如果可以保证时间戳时钟自旧连接打开以来至少已滴答一次，则可以在 PAWS 机制中使用该值来拒绝连接早期版本中的旧重复段。这要求 TIME-WAIT 延迟加上 RTT 必须至少是发送方时间戳时钟的一个刻度。此类扩展不属于本 RFC 提案的一部分。 * 请注意，这是 Garlick、Rom 和 Postel \[Garlick77\] 提出的机制的一个变体，该机制要求每个主机维护包含每个连接上的最高序列号的连接记录。如果使用时间戳，则只需为每个远程主机保留一个数量，而不管到该主机的同时连接数是多少。 需要TIME_WAIT的原因在.的[代码注释](https://elixir.bootlin.com/linux/v3.10/source/net/ipv4/tcp_minisocks.c#L156 "代码注释")`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](https://elixir.bootlin.com/linux/v3.10/source/net/ipv4/tcp_ipv4.c#L1540 "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](https://elixir.bootlin.com/linux/v3.10/source/net/ipv4/tcp_metrics.c#L536 "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](https://elixir.bootlin.com/linux/v3.10/source/net/ipv4/tcp_ipv4.c#L1496 "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](https://elixir.bootlin.com/linux/v3.10/source/include/net/sock.h#L723 "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](https://elixir.bootlin.com/linux/v3.10/source/include/net/sock.h#L723 "inet_connection_sock.h")和[request_sock.h](https://elixir.bootlin.com/linux/v3.10/source/include/net/request_sock.h#L252 "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](https://elixir.bootlin.com/linux/v4.10/source/net/ipv4/tcp_input.c#L6321 "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](https://serverfault.com/questions/1097629/no-syn-ack-packet-from-server "tcp - No SYN-ACK Packet from server - Server Fault") [Why Are Linux Kernel Protocol Stacks Dropping SYN Packets - Alibaba Cloud Community](https://www.alibabacloud.com/blog/why-are-linux-kernel-protocol-stacks-dropping-syn-packets_595251 "Why Are Linux Kernel Protocol Stacks Dropping SYN Packets - Alibaba Cloud Community")