怎么从Linux源码看Socket TCP的Listen及连接队列

84次阅读

共计 5592 个字符，预计需要花费 14 分钟才能阅读完成。

怎么从 Linux 源码看 Socket TCP 的 Listen 及连接队列，很多新手对此不是很清楚，为了帮助大家解决这个难题，下面丸趣 TV 小编将为大家详细讲解，有这方面需求的人可以来学习下，希望你能有所收获。

从 Linux 源码看 Socket(TCP) 的 listen 及连接队列前言笔者一直觉得如果能知道从应用到框架再到操作系统的每一处代码，是一件 Exciting 的事情。今天笔者就来从 Linux 源码的角度看下 Server 端的 Socket 在进行 listen 的时候到底做了哪些事情 (基于 Linux 3.10 内核)，当然由于 listen 的 backlog 参数和半连接 hash 表以及全连接队列都相关，在这一篇博客里也一块讲了。

Server 端 Socket 需要 Listen

众所周知，一个 Server 端 Socket 的建立，需要 socket、bind、listen、accept 四个步骤。今天笔者就聚焦于 Listen 这个步骤。

代码如下:

void start_server(){ // server fd int sockfd_server; // accept fd int sockfd; int call_err; struct sockaddr_in sock_addr; ...... call_err=bind(sockfd_server,(struct sockaddr*)(sock_addr),sizeof(sock_addr)); if(call_err == -1){ fprintf(stdout, bind error!\n  exit(1); } //  这边就是我们今天的聚焦点 listen call_err=listen(sockfd_server,MAX_BACK_LOG); if(call_err == -1){ fprintf(stdout, listen error!\n  exit(1); } }

首先我们通过 socket 系统调用创建了一个 socket，其中指定了 SOCK_STREAM, 而且最后一个参数为 0，也就是建立了一个通常所有的 TCP Socket。在这里，我们直接给出 TCP Socket 所对应的 ops 也就是操作函数。

如果你想知道上图中的结构是怎么来的，可以看下笔者以前的博客:

https://my.oschina.net/alchemystar/blog/1791017

Listen 系统调用好了，现在我们直接进入 Listen 系统调用吧。

#include  sys/socket.h  //  成功返回 0, 错误返回 -1, 同时错误码设置在 errno int listen(int sockfd, int backlog);

注意，这边的 listen 调用是被 glibc 的 INLINE_SYSCALL 装过一层，其将返回值修正为只有 0 和 - 1 这两个选择，同时将错误码的绝对值设置在 errno 内。这里面的 backlog 是个非常重要的参数，如果设置不好，是个很隐蔽的坑。

对于 java 开发者而言，基本用的现成的框架，而 java 本身默认的 backlog 设置大小只有 50。这就会引起一些微妙的现象，这个在本文中会进行讲解。

接下来，我们就进入 Linux 内核源码栈吧

listen |- INLINE_SYSCALL(listen......) |- SYSCALL_DEFINE2(listen, int, fd, int, backlog) /*  检测对应的描述符 fd 是否存在，不存在，返回 -BADF |- sockfd_lookup_light /*  限定传过来的 backlog 最大值不超出  /proc/sys/net/core/somaxconn |- if ((unsigned int)backlog   somaxconn) backlog = somaxconn |- sock- ops- listen(sock, backlog)  =  inet_listen

值得注意的是，Kernel 对于我们传进来的 backlog 值做了一次调整，让其无法内核参数设置中的 somaxconn。

inet_listen

接下来就是核心调用程序 inet_listen 了。

int inet_listen(struct socket *sock, int backlog) { /* Really, if the socket is already in listen state * we can only allow the backlog to be adjusted. *if ((sysctl_tcp_fastopen   TFO_SERVER_ENABLE) != 0   inet_csk(sk)- icsk_accept_queue.fastopenq == NULL) { // fastopen 的逻辑  if ((sysctl_tcp_fastopen   TFO_SERVER_WO_SOCKOPT1) != 0) err = fastopen_init_queue(sk, backlog); else if ((sysctl_tcp_fastopen   TFO_SERVER_WO_SOCKOPT2) != 0) err = fastopen_init_queue(sk, ((uint)sysctl_tcp_fastopen)   16); else err = 0; if (err) goto out; } if(old_state != TCP_LISTEN) { err = inet_csk_listen_start(sk, backlog); } sk- sk_max_ack_backlog =backlog; ...... }

从这段代码中，第一个有意思的地方就是,listen 这个系统调用可以重复调用! 第二次调用的时候仅仅只能修改其 backlog 队列长度 (虽然感觉没啥必要)。

首先，我们看下除 fastopen 之外的逻辑 (fastopen 以后开单章详细讨论)。也就是最后的 inet_csk_listen_start 调用。

int inet_csk_listen_start(struct sock *sk, const int nr_table_entries) { ...... //  这里的 nr_table_entries 即为调整过后的 backlog //  但是在此函数内部会进一步将 nr_table_entries = min(backlog,sysctl_max_syn_backlog) 这个逻辑  int rc = reqsk_queue_alloc(icsk- icsk_accept_queue, nr_table_entries); ...... inet_csk_delack_init(sk); //  设置 socket 为 listen 状态  sk- sk_state = TCP_LISTEN; //  检查端口号  if (!sk- sk_prot- get_port(sk, inet- inet_num)){ //  清除掉 dst cache sk_dst_reset(sk); //  将当前 sock 链入 listening_hash //  这样，当 SYN 到来的时候就能通过__inet_lookup_listen 函数找到这个 listen 中的 sock sk- sk_prot- hash(sk); } sk- sk_state = TCP_CLOSE; __reqsk_queue_destroy(icsk- icsk_accept_queue); //  端口已经被占用，返回错误码 -EADDRINUSE return -EADDRINUSE; }

这里最重要的一个调用 sk- sk_prot- hash(sk), 也就是 inet_hash, 其将当前 sock 链入全局的 listen hash 表，这样就可以在 SYN 包到来的时候寻找到对应的 listen sock 了。如下图所示:

如图中所示，如果开启了 SO_REUSEPORT 的话，可以让不同的 Socket listen(监听) 同一个端口，这样就能在内核进行创建连接的负载均衡。在 Nginx 1.9.1 版本开启了之后，其压测性能达到 3 倍!

半连接队列 hash 表和全连接队列

在笔者一开始翻阅的资料里面, 都提到。tcp 的连接队列有两个，一个是 sync_queue, 另一个 accept_queue。但笔者仔细阅读了一下源码，其实并非如此。事实上，sync_queue 其实是个 hash 表 (syn_table)。另一个队列是 icsk_accept_queue。

所以在本篇文章里面，将其称为 reqsk_queue(request_socket_queue 的简称)。在这里，笔者先给出这两个 queue 在三次握手时候的出现时机。如下图所示:

当然了，除了上面提到的 qlen 和 sk_ack_backlog 这两个计数器之外，还有一个 qlen_young, 其作用如下:

qlen_young:  记录的是刚有 SYN 到达，  没有被 SYN_ACK 重传定时器重传过 SYN_ACK  同时也没有完成过三次握手的 sock 数量

如下图所示:

至于 SYN_ACK 的重传定时器在内核中的代码为下面所示:

static void tcp_synack_timer(struct sock *sk) { inet_csk_reqsk_queue_prune(sk, TCP_SYNQ_INTERVAL, TCP_TIMEOUT_INIT, TCP_RTO_MAX); }

这个定时器在半连接队列不为空的情况下，以 200ms(TCP_SYNQ_INTERVAL) 为间隔运行一次。限于篇幅，笔者就在这里不多讨论了。

为什么要存在半连接队列

因为根据 TCP 协议的特点，会存在半连接这样的网络攻击存在，即不停的发 SYN 包，而从不回应 SYN_ACK。如果发一个 SYN 包就让 Kernel 建立一个消耗极大的 sock，那么很容易就内存耗尽。所以内核在三次握手成功之前，只分配一个占用内存极小的 request_sock，以防止这种攻击的现象，再配合 syn_cookie 机制，尽量抵御这种半连接攻击的风险。

半连接 hash 表和全连接队列的限制

由于全连接队列里面保存的是占用内存很大的普通 sock，所以 Kernel 给其加了一个最大长度的限制。这个限制为:

 下面三者中的最小值  1.listen 系统调用中传进去的 backlog 2./proc/sys/inet/ipv4/tcp_max_syn_backlog 3./proc/sys/net/core/somaxconn  即 min(backlog,tcp_ma_syn_backlog,somaxcon)

如果超过这个 somaxconn 会被内核丢弃，如下图所示:

这种情况的连接丢弃会发生比较诡异的现象。在不设置 tcp_abort_on_overflow 的时候,client 端无法感知，就会导致即在第一笔调用的时候才会知道对端连接丢弃了。

那么，怎么让 client 端在这种情况下感知呢，我们可以设置一下 tcp_abort_on_overflow

echo  1    tcp_abort_on_overflow

设置后，如下图所示:

当然了，最直接的还是调大 backlog!

listen(fd,2048) echo  2048    /proc/sys/inet/ipv4/tcp_max_syn_backlog echo  2048    /proc/sys/net/core/somaxconn

backlog 对半连接队列的影响

这个 backlog 对半连接队列也有影响，如下代码所示:

/* TW buckets are converted to open requests without * limitations, they conserve resources and peer is * evidently real one. */ //  在开启 SYN cookie 的情况下，如果半连接队列长度超过 backlog，则发送 cookie //  否则丢弃  if (inet_csk_reqsk_queue_is_full(sk)   !isn) { want_cookie = tcp_syn_flood_action(sk, skb,  TCP  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. */ //  在全连接队列满的情况下，如果有 young_ack，那么直接丢弃  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; }

我们在 dmesg 里面经常看到的