kk Blog —— 通用基础

date [-d @int|str] [+%s|"+%F %T"]

reuseport使用

http://www.it165.net/os/html/201605/17066.html

Q&A

Q1:什么是reuseport?

A1:reuseport是一种套接字复用机制,它允许你将多个套接字bind在同一个IP地址/端口对上,这样一来,就可以建立多个服务来接受到同一个端口的连接。

Q2:当来了一个连接时,系统怎么决定到底是哪个套接字来处理它?

A2:对于不同的内核,处理机制是不一样的,总的说来,reuseport分为两种模式,即热备份模式和负载均衡模式,在早期的内核版本中,即便是加入对reuseport选项的支持,也仅仅为热备份模式,而在3.9内核之后,则全部改为了负载均衡模式,两种模式没有共存

Q3:什么是热备份模式和负载均衡模式呢?

A3: 热备份模式:即你创建了N个reuseport的套接字,然而工作的只有一个,其它的作为备份,只有当前一个套接字不再可用的时候,才会由后一个来取代,其投入工作的顺序取决于实现。

负载均衡模式:即你创建的所有N个reuseport的套接字均可以同时工作,当连接到来的时候,系统会取一个套接字来处理它。这样就可以达到负载均衡的目的,降低某一个服务的压力。

Q4:到底怎么取套接字呢?

A4:这个对于热备份模式和负载均衡模式是不同的。

热备份模式:一般而言,会将所有的reuseport同一个IP地址/端口的套接字挂在一个链表上,取第一个即可,如果该套接字挂了,它会被从链表删除,然后第二个便会成为第一个。

负载均衡模式:和热备份模式一样,所有reuseport同一个IP地址/端口的套接字会挂在一个链表上,你也可以认为是一个数组,这样会更加方便,当有连接到来时,用数据包的源IP/源端口作为一个HASH函数的输入,将结果对reuseport套接字数量取模,得到一个索引,该索引指示的数组位置对应的套接字便是工作套接字。

关于REUSEPORT的实现

Linux 4.5/4.6所谓的对reuseport的优化主要体现在查询速度上,在优化前,在HASH冲突链表上遍历所有的套接字之后才能知道到底取哪个(基于一种冒泡的score打分机制,不完成一轮冒泡遍历,不能确定谁的score最高),之所以如此低效是因为内核将reuseport的所有套接字和其它套接字混合在了一起,查找是平坦的,正常的做法应该是将它们分为一个组,进行分层查找,先找到这个组(这个很容易),然后再在组中找具体的套接字。Linux 4.5针对UDP做了上述优化,而Linux 4.6则将这个优化引入到了TCP。

设想系统中一共有10000个套接字被HASH到同一个冲突链表,其中9950个是reuseport的同一组套接字,如果按照老的算法,需要遍历10000个套接字,如果使用基于分组的算法,最多只需要遍历51个套接字即可,找到那个组之后,一步HASH就可以找到目标套接字的索引!

Linux 4.5之前的reuseport查找实现(4.3内核)

以下是未优化前的Linux 4.3内核的实现,可见是多么地不直观。它采用了遍历HASH冲突链表的方式进行reuseport套接字的精确定位:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
result = NULL;
badness = 0;
udp_portaddr_for_each_entry_rcu(sk, node, &hslot2->head) {
	score = compute_score2(sk, net, saddr, sport, daddr, hnum, dif);
	if (score > badness) { // 冒泡排序
		// 找到了更加合适的socket,需要重新hash
		result = sk;
		badness = score;
		reuseport = sk->sk_reuseport;
		if (reuseport) {
			hash = udp_ehashfn(net, daddr, hnum, saddr, sport);
			matches = 1;
		}
	} else if (score == badness && reuseport) { // reuseport套接字散列定位
		// 找到了同样reuseport的socket,进行定位
		matches++;
		if (reciprocal_scale(hash, matches) == 0)
			result = sk;
		hash = next_pseudo_random32(hash);
	}
}

之所以要遍历是因为所有的reuseport套接字和其它的套接字都被平坦地插入到同一个表中,事先并不知道有多少组reuseport套接字以及每一组中有多少个套接字

Linux 4.5(针对UDP)/4.6(针对TCP)的reuseport查找实现

我们来看看在4.5和4.6内核中对于reuseport的查找增加了一些什么神奇的新东西:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
result = NULL;
badness = 0;
udp_portaddr_for_each_entry_rcu(sk, node, &hslot2->head) {
	score = compute_score2(sk, net, saddr, sport, daddr, hnum, dif);
	if (score > badness) {
		// 在reuseport情形下,意味着找到了更加合适的socket组,需要重新hash
		result = sk;
		badness = score;
		reuseport = sk->sk_reuseport;
		if (reuseport) {
			hash = udp_ehashfn(net, daddr, hnum, saddr, sport);
			if (select_ok) {
				struct sock *sk2;
				// 找到了一个组,接着进行组内hash。
				sk2 = reuseport_select_sock(sk, hash, skb, sizeof(struct udphdr));
				if (sk2) {
					result = sk2;
					select_ok = false;
					goto found;
				}
			}
			matches = 1;
		}
	} else if (score == badness && reuseport) {
		// 这个else if分支的期待是,在分层查找不适用的时候,寻找更加匹配的reuseport组,注意4.5/4.6以后直接寻找的是一个reuseport组。
		// 在某种意义上,这回退到了4.5之前的算法。
		matches++;
		if (reciprocal_scale(hash, matches) == 0)
			result = sk;
		hash = next_pseudo_random32(hash);
	}
}

我们着重看一下reuseport_select_sock,这个函数是第二层组内查找的关键,其实不应该叫做查找,而应该叫做定位更加合适:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
struct sock *reuseport_select_sock(struct sock *sk, u32 hash, struct sk_buff *skb, int hdr_len)
{
	...
	prog = rcu_dereference(reuse->prog);
	socks = READ_ONCE(reuse->num_socks);
	if (likely(socks)) {
		/* paired with smp_wmb() in reuseport_add_sock() */
		smp_rmb();
 
		if (prog && skb) // 可以用BPF来从用户态注入自己的定位逻辑,更好实现基于策略的负载均衡
			sk2 = run_bpf(reuse, socks, prog, skb, hdr_len);
		else
			// reciprocal_scale简单地将结果限制在了[0,socks)这个区间内
			sk2 = reuse->socks[reciprocal_scale(hash, socks)];
	}
	...
}