如果在Linux中使用TCP，则listen的待办事项编号是否包括SYN接收的连接计数? [英] Does listen's backlog number include SYN-received connections count in case of TCP in Linux?

问题描述

我阅读了一些帖子，并检查了Linux内核代码，例如 inet_listen()-> inet_csk_listen_start() 似乎listen的backlog参数() syscall仅影响已接受的队列，但不影响SYN接收的队列:

I read some posts and checked Linux kernel code like inet_listen()->inet_csk_listen_start() and it seems that backlog argument of listen() syscall only affects on accepted queue, but not on SYN-received queue:

sk->sk_max_ack_backlog = backlog;

即 接受队列+ syn-received-queue！=待办事项 .我不知道发生了什么事.本文指出:

接受和SYN队列的最大允许长度从由传递给listen(2)系统调用的backlog参数应用程序.

The maximum allowed length of both the Accept and SYN Queues is taken from the backlog parameter passed to the listen(2) syscall by the application.

但是手册页中没有相似之处.

在Linux中也是如此: backlog 是如前所述的提示在这里还是真的限制了队列?

Also in case of Linux: Is backlog a hint as mentioned here or it really limits queues?

推荐答案

对于4.3内核，您指定的内容类似于:

In case of 4.3 kernel you specified it's something like:

tcp_v4_do_rcv()-> tcp_rcv_state_process()-> tcp_v4_conn_request()-> tcp_conn_request()-> inet_csk_reqsk_queue_is_full()

tcp_v4_do_rcv()->tcp_rcv_state_process()->tcp_v4_conn_request()->tcp_conn_request()->inet_csk_reqsk_queue_is_full()

此处，我们可以看到关于队列的最重要的细节:

Here we can see the most important details about queues:

/* TW buckets are converted to open requests without
 * limitations, they conserve resources and peer is
 * evidently real one.
 */
if ((sysctl_tcp_syncookies == 2 ||
     inet_csk_reqsk_queue_is_full(sk)) && !isn) {
    want_cookie = tcp_syn_flood_action(sk, skb, rsk_ops->slab_name);
    if (!want_cookie)
        goto drop;
}

/* 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 (sk_acceptq_is_full(sk) && inet_csk_reqsk_queue_young(sk) > 1) {
    NET_INC_STATS_BH(sock_net(sk), LINUX_MIB_LISTENOVERFLOWS);
    goto drop;
}

请注意 inet_csk_reqsk_queue_is_full():

static inline int inet_csk_reqsk_queue_is_full(const struct sock *sk)
{
    return inet_csk_reqsk_queue_len(sk) >= sk->sk_max_ack_backlog;
}

最后，它将当前队列 icsk_accept_queue 与先前由 inet_csk_listen_start()设置的 sk_max_ack_backlog 大小进行比较.所以， backlog 在当前情况下会影响传入队列.

Finally it compares current queue icsk_accept_queue with sk_max_ack_backlog size which was previously set by inet_csk_listen_start(). So yep, backlog affects incoming queue in current case.

您可以看到 sk_acceptq_is_full()和 inet_csk_reqsk_queue_is_full()都与通过设置的同一套接字的 sk_max_ack_backlog 进行了比较.> listen():

You can see that both sk_acceptq_is_full() and inet_csk_reqsk_queue_is_full() make comparison with the same socket's sk_max_ack_backlog which is set through the listen():

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

有用的链接: 1 ， 查看全文