解析 ‘TCP Three-way Handshake’ 的内核代码：SYN Queue 与 Accept Queue 满了会发生什么？ - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

在深入探讨TCP三向握手过程中，SYN队列（SYN Queue）与Accept队列（Accept Queue）在Linux内核中的行为及其在队列满载时的影响之前，我们首先需要对TCP连接建立的基本机制有一个清晰的理解。TCP（Transmission Control Protocol）作为面向连接的、可靠的传输协议，其连接建立的核心便是著名的“三向握手”过程。

TCP 三向握手概述

TCP的三向握手是一个确保双方都准备好发送和接收数据的过程。它涉及三个步骤：

客户端发送SYN报文：客户端（initiator）向服务器（responder）发送一个SYN（Synchronize）报文，请求建立连接。报文中包含一个初始序列号（ISN, Initial Sequence Number）。客户端进入SYN_SENT状态。
服务器发送SYN-ACK报文：服务器收到SYN报文后，如果接受连接，会发送一个SYN-ACK报文。报文中包含服务器的ISN，并确认（ACK）了客户端的ISN（ACK = 客户端ISN + 1）。服务器进入SYN_RCVD状态。
客户端发送ACK报文：客户端收到SYN-ACK报文后，发送一个ACK报文作为回应，确认了服务器的ISN（ACK = 服务器ISN + 1）。客户端进入ESTABLISHED状态。服务器收到此ACK报文后，也进入ESTABLISHED状态。

至此，一个TCP连接正式建立。然而，在服务器端，管理这些半开和全开的连接需要精巧的机制，这正是SYN队列和Accept队列发挥作用的地方。

内核中的TCP连接管理：核心数据结构

在Linux内核中，TCP连接的管理离不开几个关键的数据结构，它们是理解SYN队列和Accept队列的基础。

struct sock: 这是Linux内核中表示一个socket的基本结构体。它包含了所有与socket相关的通用信息，如协议类型、本地/远端地址、端口、状态等。对于TCP连接，sock结构体是最终建立的连接的代表。
struct inet_sock: 作为struct sock的一个嵌入结构，它为IP协议族（IPv4/IPv6）的socket提供了特有的字段，如IP地址、端口号等。
struct request_sock: 这是一个轻量级的结构体，用于在TCP三向握手过程中，服务器收到SYN报文但尚未收到最终ACK报文时，临时存储连接请求的信息。它代表了一个处于SYN_RCVD状态的半开连接。request_sock占用资源较少，旨在快速响应SYN请求并发送SYN-ACK，以应对潜在的SYN泛洪攻击。
struct listen_sock: 对于一个监听socket（通过listen()系统调用创建），内核会为其分配一个listen_sock结构。这个结构体包含了两个至关重要的队列：SYN队列和Accept队列。

`listen()` 系统调用：队列的初始化

当一个服务器应用程序调用listen()系统调用时，内核会为指定的socket准备好接收传入连接。listen()的典型用法是 listen(sockfd, backlog)。这里的backlog参数对于理解Accept队列至关重要。

// 伪代码：应用程序层
int server_fd = socket(AF_INET, SOCK_STREAM, 0);
bind(server_fd, (struct sockaddr *)&server_addr, sizeof(server_addr));
listen(server_fd, SOMAXCONN); // backlog参数

在内核中，listen()系统调用会执行以下关键操作：

将socket状态设置为LISTEN：表示此socket已准备好接收连接。
创建listen_sock结构：如果尚未创建，则为监听socket分配并初始化listen_sock结构。
初始化SYN队列和Accept队列：
- Accept队列：listen_sock中的sk_ack_backlog字段（或类似名称）用于跟踪Accept队列中的连接数。backlog参数在这里发挥作用，它被内核用来设置Accept队列的最大长度。然而，这个backlog值实际上会被系统级的net.core.somaxconn参数限制。最终的Accept队列大小是min(backlog, sysctl_somaxconn)。
- SYN队列：SYN队列的实际大小由内核参数net.ipv4.tcp_max_syn_backlog控制。listen()调用并不直接设置SYN队列的大小，但它为后续的SYN处理准备了环境。

以下表格总结了listen()参数与内核队列大小的关系：

队列名称	存储对象	状态	内核参数/`listen()`参数	默认值/范围
SYN队列	`request_sock`	`SYN_RCVD`	`net.ipv4.tcp_max_syn_backlog`	1024 (在某些发行版中可能更高)
Accept队列	`struct sock`	`ESTABLISHED`	`listen()`的`backlog`参数，受`net.core.somaxconn`限制	`listen()`参数可达`SOMAXCONN`（128），`net.core.somaxconn`默认128，可调整至更高

SYN队列：半开连接的舞台

SYN队列是专门用来存储那些只完成了TCP三向握手前两步的连接请求（即服务器收到了SYN，并发送了SYN-ACK，但尚未收到客户端的最终ACK）。这些连接处于SYN_RCVD状态，由request_sock结构体表示。

SYN报文的到达与处理流程

当一个客户端发送SYN报文到服务器的监听端口时，内核会经历以下关键步骤：

网络层接收报文：报文到达网卡，被网络驱动程序接收，并传递给IP层。
IP层处理：IP层根据目标IP地址将报文转发给TCP层。
TCP层查找监听socket：
- tcp_v4_rcv是接收TCP报文的入口函数。
- 它会尝试通过tcp_v4_lookup等函数，根据源/目标IP和端口，查找对应的sock结构。
- 对于SYN报文，如果找到的是一个处于LISTEN状态的sock，则调用tcp_v4_listen_rcv。
tcp_v4_listen_rcv函数：这是处理传入SYN报文的核心函数。
- 检查SYN队列是否满：内核会首先检查当前SYN队列中的request_sock数量是否已达到net.ipv4.tcp_max_syn_backlog所设定的上限。
- 创建request_sock：如果队列未满，内核会分配一个新的request_sock结构体。这个结构体从传入的SYN报文中提取关键信息，如客户端的IP地址、端口、ISN、TCP选项（MSS、窗口缩放、SACK等）。
- 初始化request_sock状态：新创建的request_sock被设置为SYN_RCVD状态。
- 发送SYN-ACK：内核使用tcp_v4_send_synack函数，根据request_sock中的信息构造并发送SYN-ACK报文给客户端。
- 添加到SYN队列：request_sock通过哈希表（tcp_synq_hash_add）被添加到监听socket的SYN队列中。这是一个哈希表，而不是一个简单的链表，为了能够快速查找（当最终的ACK到达时）。

// 伪代码：内核函数 tcp_v4_listen_rcv 简化版
struct sock *tcp_v4_listen_rcv(struct sock *sk, struct sk_buff *skb) {
    // ... 检查报文合法性 ...

    // 1. 检查SYN队列是否满
    if (inet_csk_reqsk_queue_is_full(sk)) {
        // SYN队列已满，执行拥塞策略
        tcp_syn_flood_action(sk, skb);
        return NULL; // 丢弃SYN报文
    }

    // 2. 创建 request_sock
    struct request_sock *req = inet_reqsk_alloc(&tcp_request_sock_ops, sk);
    if (!req) {
        // 内存不足，丢弃SYN
        return NULL;
    }

    // 3. 根据SYN报文初始化 request_sock
    tcp_v4_reqsk_init(req, sk, skb);
    // ... 处理TCP选项，如MSS，窗口缩放等 ...

    // 4. 发送 SYN-ACK
    if (tcp_v4_send_synack(sk, req) < 0) {
        // 发送失败，释放req
        reqsk_free(req);
        return NULL;
    }

    // 5. 将 request_sock 添加到SYN队列 (哈希表)
    inet_csk_reqsk_queue_add(sk, req);

    return NULL; // 监听socket不处理数据，返回NULL
}

SYN队列满了会发生什么？

当SYN队列中的request_sock数量达到net.ipv4.tcp_max_syn_backlog所设定的上限时，服务器将无法为新的SYN报文创建request_sock。此时，内核会采取以下策略：

默认行为：丢弃SYN报文
- 这是最常见的行为。服务器直接丢弃传入的SYN报文，不发送SYN-ACK。
- 客户端没有收到SYN-ACK，会在超时后重传SYN报文。如果重传多次仍无回应，客户端应用程序最终会报告连接超时错误。
- 这种行为的优点是简单，不消耗服务器资源处理无法建立的连接。缺点是可能导致正常客户端连接失败。
tcp_syncookies机制（推荐）
- 当net.ipv4.tcp_syncookies被设置为1（开启）时，如果SYN队列满载，内核会启用Syncookies机制来应对。
- Syncookies原理：服务器不创建request_sock，而是将所有必要的连接状态信息（客户端IP、端口、ISN、MSS等）编码到一个特殊的初始序列号中，并将其作为SYN-ACK报文的序列号发送给客户端。这个特殊的序列号被称为“Syncookie”。
- 当客户端发送最终的ACK报文时，服务器可以从ACK报文的确认序列号中解码出原始的连接状态信息，从而“重建”连接，而无需在SYN队列中存储request_sock。
- 优点：Syncookies机制能够有效抵御SYN泛洪攻击，因为它不需要为每个SYN请求分配内核内存，因此SYN队列理论上可以无限大。
- 缺点：Syncookies机制在实现时会禁用一些TCP选项（如窗口缩放、SACK），因为这些选项不能完全编码到Syncookie中。这可能会对性能产生轻微影响，但在应对SYN泛洪攻击时，其优势远大于劣势。
- net.ipv4.tcp_syncookies的默认值通常是1（开启），这对于服务器的健壮性至关重要。
net.ipv4.tcp_max_syn_backlog参数调优
- 这个参数决定了SYN队列的最大容量。如果服务器面临高并发的连接请求或SYN泛洪攻击，增加这个值可以为服务器提供更大的缓冲。
- 例如，通过sysctl -w net.ipv4.tcp_max_syn_backlog=4096可以将其设置为4096。
- 然而，过大的值会增加内核内存消耗，并可能导致在真正遭受攻击时消耗过多资源。Syncookies是更根本的解决方案。

总结SYN队列满载的影响：

对客户端：连接尝试失败，表现为连接超时。
对服务器：
- 如果syncookies关闭：合法连接被拒绝，服务器似乎“无响应”。
- 如果syncookies开启：服务器仍然可以建立连接，但可能会牺牲一些高级TCP特性。
- SYN泛洪攻击在这种情况下能够有效地阻止合法用户连接。

Accept队列：已建立连接的就绪区

Accept队列是用于存储那些已经完全完成三向握手（即服务器收到了最终的ACK报文，并已进入ESTABLISHED状态）但尚未被应用程序通过accept()系统调用取走的连接。这些连接由完整的struct sock结构体表示。

最终ACK报文的到达与处理流程

当客户端发送的最终ACK报文到达服务器时，内核会执行以下操作：

查找对应的request_sock：
- tcp_v4_rcv函数会根据传入ACK报文的源/目标IP和端口以及序列号，在SYN队列的哈希表中查找匹配的request_sock。
- 如果syncookies是激活的且SYN队列已满，内核会通过ACK报文的确认序列号验证Syncookie并重建连接状态。
验证ACK报文：
- tcp_check_req函数会验证ACK报文的合法性，确保其确认号与之前发送的SYN-ACK报文的序列号匹配。
创建完整的sock结构：
- 如果ACK报文有效，内核会从request_sock（或从Syncookie重建的状态）中获取所有必要信息，分配并初始化一个新的完整的struct sock结构体。这个新的sock代表了一个全新的、独立的TCP连接（子socket）。
- 这个新的sock的状态被设置为ESTABLISHED。
- 旧的request_sock（如果存在）会被从SYN队列中移除并释放。
添加到Accept队列：
- 新创建的、处于ESTABLISHED状态的sock结构体被添加到监听socket的Accept队列中。这个操作通常通过inet_csk_reqsk_queue_add -> sk_acceptq_add等函数完成。
- 此时，监听socket会收到一个事件通知，可以通过select/poll/epoll等机制通知应用程序有新的连接到来。

// 伪代码：内核函数 tcp_check_req_syn 简化版 (处理最终ACK)
// 这是在 tcp_v4_rcv 中，找到 req 后的处理逻辑
struct sock *tcp_check_req_syn(struct sock *sk, struct sk_buff *skb, struct request_sock *req) {
    // ... 验证ACK报文的合法性 ...

    // 1. 检查Accept队列是否满
    if (inet_csk_listen_backlog_is_full(sk)) {
        // Accept队列已满，执行拥塞策略
        tcp_reqsk_queue_drop(sk, req, skb); // 可能丢弃ACK或发送RST
        return NULL;
    }

    // 2. 从 request_sock 创建一个完整的 sock (子socket)
    struct sock *new_sk = tcp_create_listen_child(sk, req, skb);
    if (!new_sk) {
        // 创建失败
        inet_csk_reqsk_queue_drop(sk, req);
        return NULL;
    }

    // 3. 将新的 sock 添加到Accept队列
    // 这个函数会同时将 new_sk 放入 Accept 队列，并从 SYN 队列移除 req
    inet_csk_reqsk_queue_add(sk, req, new_sk);

    // ... 唤醒等待 accept() 的进程 ...
    return new_sk;
}

Accept队列满了会发生什么？

当Accept队列中的sock结构体数量达到listen()系统调用中backlog参数（受net.core.somaxconn限制）所设定的上限时，服务器将无法将新的ESTABLISHED连接放入Accept队列。此时，内核有几种处理策略：

默认行为：丢弃最终的ACK报文并重传SYN-ACK
- 这是Linux内核的默认行为（当net.ipv4.tcp_abort_on_overflow设置为0时）。服务器会丢弃客户端发送的最终ACK报文。
- 由于服务器没有收到ACK，它会认为客户端没有收到SYN-ACK，因此会重传SYN-ACK报文。
- 客户端收到重传的SYN-ACK后，会再次发送ACK报文。这个过程会持续，直到Accept队列有空间，或者客户端的重传次数达到上限（由net.ipv4.tcp_synack_retries控制），最终客户端会超时并关闭连接。
- 影响：这种行为会导致连接建立延迟，客户端可能会经历较长的等待时间甚至超时。服务器端，相应的request_sock会继续占用SYN队列（直到超时），浪费资源。
net.ipv4.tcp_abort_on_overflow参数
- 如果将net.ipv4.tcp_abort_on_overflow设置为1，当Accept队列满载时，服务器会发送一个RST（Reset）报文给客户端，主动终止该连接。
- 优点：服务器立即释放为该连接分配的资源（request_sock）。客户端也能更快地收到连接失败的通知，而不是长时间等待。
- 缺点：对于高并发场景，如果Accept队列只是暂时性满载，这种激进的策略可能会导致大量合法连接被无故拒绝。通常不建议在生产环境开启此选项，除非有明确的需求。
net.core.somaxconn参数调优
- 这个参数是系统级的，限制了所有监听socket的backlog参数的最大有效值。
- 如果服务器应用程序的listen(sockfd, backlog)中的backlog参数设置得很高，但net.core.somaxconn很小，那么实际的Accept队列大小会受net.core.somaxconn限制。
- 增加net.core.somaxconn（例如，sysctl -w net.core.somaxconn=1024甚至更高）可以允许应用程序配置更大的Accept队列，从而容纳更多的已建立连接，减少连接被拒绝的概率。
- 然而，过大的Accept队列会增加内核内存消耗，并可能导致应用程序在accept()调用时处理大量积压的连接，从而影响响应速度。

总结Accept队列满载的影响：

对客户端：连接建立延迟，最终可能超时。应用程序体验变差。
对服务器：
- 增加SYN-ACK重传，消耗网络带宽和CPU。
- request_sock在SYN队列中停留更长时间，占用资源。
- 如果tcp_abort_on_overflow开启，会发送大量RST，导致连接立即失败。
- 无法及时处理新的合法连接。

`accept()` 系统调用：消费连接

当应用程序准备好处理一个新的连接时，它会调用accept()系统调用。

// 伪代码：应用程序层
while (1) {
    new_socket_fd = accept(server_fd, (struct sockaddr *)&client_addr, &client_addr_len);
    if (new_socket_fd == -1) {
        // 处理错误
        continue;
    }
    // 处理新连接 new_socket_fd
}

在内核中，accept()函数主要完成以下工作：

等待连接：如果Accept队列为空，accept()通常会阻塞，直到队列中有新的连接到来（除非socket被设置为非阻塞模式）。
从队列中取出连接：一旦Accept队列中有连接，accept()会从队列头部取出一个已建立的sock结构体。
返回新的文件描述符：内核为这个新的sock结构体分配一个新的文件描述符，并将其返回给应用程序。应用程序此后通过这个新的文件描述符与客户端进行通信。
更新队列状态：Accept队列中的连接数减一。

// 伪代码：内核函数 sys_accept 简化版
SYSCALL_DEFINE3(accept, int, fd, struct sockaddr __user *, upeer_sockaddr, int __user *, upeer_addrlen) {
    // ... 获取监听socket ...

    // 1. 等待Accept队列中有连接 (如果队列为空且是阻塞模式)
    struct sock *sk = SYSC_SOCK_OPS_GET(listen_socket_fd);
    struct sock *new_sk = inet_csk_wait_for_connect(sk, wait_flags, &timeout);

    if (!new_sk) {
        // 超时或被中断
        return -EAGAIN; // 或其他错误
    }

    // 2. 从Accept队列中取出连接
    // inet_csk_wait_for_connect 内部已经完成了从队列中取出的操作，
    // 返回的 new_sk 就是从 accept 队列中移除的。

    // 3. 将 new_sk 关联到一个新的文件描述符
    int new_fd = sock_map_fd(new_sk, client_addr_info);

    // 4. 将客户端地址信息复制到用户空间
    // ... copy_to_user(upeer_sockaddr, ...) ...

    return new_fd;
}

内核参数与性能调优

理解这些队列的工作原理后，我们就可以对系统进行相应的调优，以应对不同的负载和攻击模式。

参数名称	作用	默认值/范围	建议调优方向	备注
`net.ipv4.tcp_max_syn_backlog`	SYN队列的最大长度。	1024	根据预期流量和SYN泛洪风险增加。	过高可能消耗内存，但Syncookies更重要。
`net.core.somaxconn`	Accept队列的最大长度（系统全局上限）。	128	根据应用程序预期并发连接数增加。	影响所有监听socket，需重启服务生效。
`net.ipv4.tcp_syncookies`	是否开启Syncookies机制。	1 (开启)	保持开启 (1)。	有效防御SYN泛洪，略微牺牲高级TCP特性。
`net.ipv4.tcp_abort_on_overflow`	Accept队列满时，是丢弃ACK还是发送RST。	0 (丢弃ACK)	保持默认 (0)，除非需要快速失败。	1 会导致连接快速失败，可能影响合法连接。
`net.ipv4.tcp_synack_retries`	服务器发送SYN-ACK的重试次数。	5	默认值通常足够。	影响`SYN_RCVD`状态连接的超时时间。
`net.ipv4.tcp_keepalive_time`	TCP Keepalive探测的空闲时间。	7200秒	根据应用需要调整，用于检测死连接。	与队列机制间接相关，用于清理长期不活跃连接。

调优示例：

# 查看当前值
sysctl net.ipv4.tcp_max_syn_backlog
sysctl net.core.somaxconn
sysctl net.ipv4.tcp_syncookies

# 临时设置（重启后失效）
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096
sudo sysctl -w net.core.somaxconn=16384

# 永久设置（编辑 /etc/sysctl.conf）
echo "net.ipv4.tcp_max_syn_backlog = 4096" | sudo tee -a /etc/sysctl.conf
echo "net.core.somaxconn = 16384" | sudo tee -a /etc/sysctl.conf
sudo sysctl -p # 使配置生效

实际应用与故障排除

在实际生产环境中，SYN队列和Accept队列的溢出是常见的性能瓶颈或DDoS攻击的迹象。

如何检测队列溢出？

netstat -s 或 ss -s：
- netstat -s可以查看TCP统计信息，其中包含SYNs to LISTEN sockets dropped（SYN队列溢出）和connections reset due to listener overflow（Accept队列溢出，当tcp_abort_on_overflow开启时）或SYNs currently in SYN queue。
- ss -lnt可以显示监听socket的详细信息，包括Recv-Q（Accept队列中的字节数或连接数）和Send-Q（backlog限制）。
```
State      Recv-Q Send-Q Local Address:Port   Peer Address:Port
LISTEN     0      128    0.0.0.0:80           0.0.0.0:*
```
  这里的Recv-Q对于监听socket表示Accept队列中当前有多少个已完成的连接等待accept()，Send-Q则表示listen()函数中backlog参数设置的上限（受net.core.somaxconn限制）。
/proc/net/snmp 和 /proc/net/netstat：
- 可以从中提取更详细的TCP统计信息，包括SYN队列和Accept队列相关的丢弃计数。
- 例如，TcpExtListenOverflows和TcpExtListenDrops字段可以指示Accept队列溢出和丢弃的连接数。

常见场景与解决方案

SYN泛洪攻击：攻击者发送大量SYN报文，但不回应SYN-ACK，导致SYN队列迅速被占满。
- 解决方案：确保net.ipv4.tcp_syncookies = 1。适当增加net.ipv4.tcp_max_syn_backlog。使用防火墙/IDS/IPS设备进行流量清洗和DDoS防护。
高并发连接请求：服务器应用程序处理accept()的速度跟不上客户端连接请求的速度。
- 解决方案：
  - 增加net.core.somaxconn和应用程序listen()的backlog参数，以扩大Accept队列容量。
  - 优化应用程序代码，提高accept()和后续连接处理的效率（例如，使用多线程/多进程模型，或异步I/O模型如epoll）。
  - 检查后端服务或数据库是否成为瓶颈，导致应用程序处理新连接变慢。
慢速客户端或网络不稳定：客户端因网络延迟或自身处理慢，导致ACK报文迟迟不发送或重传。
- 解决方案：调整net.ipv4.tcp_synack_retries可能会有帮助，但更根本的是解决网络或客户端问题。

总结与展望

TCP三向握手是连接建立的基础，而SYN队列和Accept队列则是Linux内核在服务器端高效、健壮地管理这些连接的关键机制。SYN队列通过request_sock管理半开连接，并借助Syncookies机制有效抵御SYN泛洪攻击。Accept队列则存储已完全建立但尚未被应用程序取走的连接。当这两个队列达到其容量上限时，会触发不同的内核行为，从默默丢弃报文到主动发送RST，这些行为直接影响着服务器的可用性和客户端的连接体验。深入理解这些机制以及相关的内核参数，对于系统管理员和开发人员来说，是优化网络服务性能、提升系统稳定性和应对DDoS攻击不可或缺的知识。通过合理的参数配置和应用程序优化，我们可以确保服务器在高负载下依然能够提供稳定可靠的服务。