从Linux源码看Socket(TCP)的listen及链接队列

从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里面常常看到的

Possible SYN flooding on port 8080

就是因为半链接队列满之后，Kernel发送cookie校验而致使。

总结

TCP做为一个古老而又流行的协议，在演化了几十年后，其设计变的至关复杂。从而在出问题的时候变的难于分析，这时候就要reading the fucking source code!而笔者也正是写这篇博客而详细阅读源码的时候偶然间灵光一闪，找到了最近一个诡异问题的根因。这个诡异问题的分析过程将会在近期写出来分享给你们。
欢迎你们关注我公众号，里面有各类干货，还有大礼包相送哦!