Linux内核TCP实现中sk_acceptq_is_full为何用>而非>=？

场景复现 #

你在Linux 4.4.0内核环境下做的测试场景很典型：

int listenfd = socket(PF_INET, SOCK_STREAM, 0);
bzero(&servaddr, sizeof(servaddr));
servaddr.sin_family = AF_INET;
servaddr.sin_addr.s_addr = htonl(INADDR_ANY);
servaddr.sin_port = htons(50001);
bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
listen(listenfd, 2); // 仅监听，从不调用accept
while(1) { sleep(1); }

按照listen的backlog参数的直观理解，你预期最多只能完成2次TCP三次握手（已完成握手但未被accept的连接数应该被限制为2），但实际测试结果却是能完成3次。

内核源码中的关键判断 #

你已经找到了问题的核心：内核tcp_input.c中的tcp_conn_request函数通过sk_acceptq_is_full判断accept队列是否已满：

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

这里再明确下两个变量的含义：

• sk->sk_ack_backlog：当前已完成三次握手、但还没被用户态accept取走的连接数量
• sk->sk_max_ack_backlog：就是你调用listen时传入的backlog参数值

为什么用>而非>=判断队列已满？ #

这个设计看似违反直觉，但它是Linux内核长期保留的实现逻辑（甚至到5.0.9版本依然如此），主要有这几个原因：

1. 实际队列容量的“隐性扩容” #

从代码逻辑来看，当sk_ack_backlog等于sk_max_ack_backlog时，sk_acceptq_is_full返回false——意味着队列还没满，仍能接受新的连接。只有当已完成连接数超过backlog值时，才会拒绝后续连接请求。

对应到你的测试场景：backlog=2时，前2次握手完成后sk_ack_backlog=2，此时2>2不成立，所以第三个连接的SYN请求会被正常处理，完成三次握手后sk_ack_backlog变为3；第四个连接请求才会触发3>2的判断，被拒绝。这就是你看到3次握手完成的原因。

2. 历史实现的延续 #

在Linux 2.2版本之前，backlog参数控制的是SYN队列（未完成握手的连接）和accept队列（已完成握手的连接）的总长度。后来内核将两个队列分开管理，但这个判断逻辑被保留了下来，以兼容依赖旧行为的应用程序。

3. 边界条件下的竞争避免 #

用>而不是>=的设计，能在用户态调用accept的临界时刻，减少不必要的连接拒绝。比如当accept队列刚好达到backlog长度时，用户态可能正在调用accept取出一个连接，此时新的连接请求进来，内核仍能接受它，避免因为短暂的队列满状态而拒绝合法请求。

内容的提问来源于stack exchange，提问作者beacon_uestc