在日常的开发过程中，经常会遇到端口占用冲突的问题。那是不是不同的进程不能同时监听同一个端口呢？这个小节就来介绍 SO_REUSEPORT 选项相关的内容。

通过阅读这个小节，你会学到如下知识。

• SO_REUSEPORT 选项是什么
• 什么是惊群效应
• SO_REUSEPORT 选项安全性相关的问题
• Linux 内核实现端口选择过程的源码分析

SO_REUSEPORT 是什么

默认情况下，一个 IP、端口组合只能被一个套接字绑定，Linux 内核从 3.9 版本开始引入一个新的 socket 选项 SO_REUSEPORT，又称为 port sharding，允许多个套接字监听同一个IP 和端口组合。

为了充分发挥多核 CPU 的性能，多进程的处理网络请求主要有下面两种方式

• 主进程 + 多个 worker 子进程监听相同的端口
• 多进程 + REUSEPORT

第一种方最常用的一种模式，Nginx 默认就采用这种方式。主进程执行 bind()、listen() 初始化套接字，然后 fork 新的子进程。在这些子进程中，通过 accept/epoll_wait 同一个套接字来进行请求处理，示意图如下所示。

这种方式看起来很完美，但是会带来著名的“惊群”问题（thundering herd）。

惊群问题（thundering herd）

在开始介绍惊群之前，我们下来看看一个现实世界中的惊群问题。假如你养了五条狗，一开始这五条狗都在睡觉，你过去扔了一块骨头，这五条狗都从睡梦中醒来，一起跑过来争抢这块骨头，最终只有第三条狗抢到了这块骨头，剩下的四条狗只好无奈的继续睡觉。如下图所示。

?从上面的例子可以看到，明明只有一块骨头只够一条小狗吃，五只小狗却一起从睡眠中醒来争抢，对于没有抢到小狗来说，浪费了很多精力。

计算机中的惊群问题指的是：多进程/多线程同时监听同一个套接字，当有网络事件发生时，所有等待的进程/线程同时被唤醒，但是只有其中一个进程/线程可以处理该网络事件，其它的进程/线程获取失败重新进入休眠。

惊群问题带来的是 CPU 资源的浪费和锁竞争的开销。根据使用方式的不同，Linux 上的网络惊群问题分为 accept 惊群和 epoll 惊群两种。

accept 惊群

Linux 在早期的版本中，多个进程 accept 同一个套接字会出现惊群问题，以下面的代码为例。

int main(void) {
  // ...
  servaddr.sin_port = htons (9090);
  bind(listenfd, (struct sockaddr *)&servaddr, sizeof(servaddr));
  listen(listenfd, 5);
  clilen = sizeof(cliaddr);

  for (int i = 0; i < 4; ++i) {
	if ((fork()) == 0) {
	  // 子进程
	  printf("child pid: %d\n", getpid());
	  while (1) {
		connfd = accept(listenfd, (struct sockaddr *)&cliaddr, &clilen);
		sleep(2);
		printf("processing, pid is %d\n", getpid());
	  }
	}
  }
  sleep(-1);
  return 1;
}

执行 nc -i 1 localhost 9090，输出结果如下。

child pid: 25050
child pid: 25051
child pid: 25052
child pid: 25053
processing, pid is 25050

可以看到当有网络请求到来时，只会唤醒了其中一个子进程，其他的进程继续休眠阻塞在 accept 调用上，没有被唤醒，这种情况下，accept 系统调用不存在惊群现象。这是因为 Linux 在 2.6 内核版本之前监听同一个 socket 的多个进程在事件发生时会唤醒所有等待的进程，在 2.6 版本中引入了 WQ_FLAG_EXCLUSIVE 选项解决了 accept 调用的惊群问题。

不幸的是现在高性能的服务基本上都使用 epoll 方案来处理非阻塞 IO，接下来我们来看 epoll 惊群。

epoll 惊群

epoll 典型的工作模式是父进程执行 bind、listen 以后 fork 出子进程，使用 epoll_wait 等待事件发生，模式如下图所示。

?以下面的代码为例。

int main(void) {
  // ...
  sock_fd = create_and_bind("9090");
  listen(sock_fd, SOMAXCONN);

  epoll_fd = epoll_create(1);
  event.data.fd = sock_fd;
  event.events = EPOLLIN;
  epoll_ctl(epoll_fd, EPOLL_CTL_ADD, sock_fd, &event);
  events = calloc(MAXEVENTS, sizeof(event));

  for (int i = 0; i < 4; i++) {
	if (fork() == 0) {
	  while (1) {
		int n = epoll_wait(epoll_fd, events, MAXEVENTS, -1);
		printf("return from epoll_wait, pid is %d\n", getpid());
		sleep(2);
		for (int j = 0; j < n; j++) {
          if ((events[i].events & EPOLLERR) || (events[i].events & EPOLLHUP) ||
              (!(events[i].events & EPOLLIN))) {
            close(events[i].data.fd);
            continue;
          } else if (sock_fd == events[j].data.fd) {
            struct sockaddr sock_addr;
            socklen_t sock_len;
            int conn_fd;
            sock_len = sizeof(sock_addr);
            conn_fd = accept(sock_fd, &sock_addr, &sock_len);
            if (conn_fd == -1) {
              printf("accept failed, pid is %d\n", getpid());
              break;
            }
            printf("accept success, pid is %d\n", getpid());
            close(conn_fd);
          }
      }
    }
  }
}

上面代码运行以后，使用 ls -l /proc/your_pid/fd 命令可以查看主进程打开的所有 fd 文件，如果 pid 为 24735，执行的结果如下。

ls -l /proc/24735/fd

lrwx------. 1 ya ya 64 Jan 28 06:20 0 -> /dev/pts/2
lrwx------. 1 ya ya 64 Jan 28 06:20 1 -> /dev/pts/2
lrwx------. 1 ya ya 64 Jan 28 00:10 2 -> /dev/pts/2
lrwx------. 1 ya ya 64 Jan 28 06:20 3 -> 'socket:[72919]'
lrwx------. 1 ya ya 64 Jan 28 06:20 4 -> 'anon_inode:[eventpoll]'

可以看到主进程会生成 5 个 fd，0~2 分别是 stdin、stdout、stderr，fd 为 3 的描述符是 socket 套接字文件，fd 为 4 的是 epoll 的 fd。

为了表示打开文件，linux 内核维护了三种数据结构，分别是：

• 内核为每个进程维护了一个其打开文件的「描述符表」（file descriptor table），我们熟知的 fd 为 0 的 stdin 就是属于文件描述符表。
• 内核为所有打开文件维护了一个系统级的「打开文件表」（open file table），这个打开文件表存储了当前文件的偏移量，状态信息和对 inode 的指针等信息，父子进程的 fd 可以指向同一个打开文件表项。
• 最后一个是文件系统的 inode 表（i-node table）

经过 for 循环的 fork，会生成 4 个子进程，这 4 个子进程会继承父进程的 fd。在这种情况下，对应的进程文件描述符表、打开文件表和 inode 表的关系如下图所示。

?子进程的 epoll_wait 等待同一个底层的 open file table 项，当有事件发送时，会通知到所有的子进程。

编译运行上面的，使用 nc -i 1 localhost 9090 发起网络请求，输出结果如下所示。

return from epoll_wait, pid is 25410
return from epoll_wait, pid is 25411
return from epoll_wait, pid is 25409
return from epoll_wait, pid is 25412
accept success, pid is 25410
accept failed, pid is 25411
accept failed, pid is 25409
accept failed, pid is 25412

可以看到当有新的网络事件发生时，阻塞在 epoll_wait 的多个进程同时被唤醒。在这种情况下，epoll 的惊群还是存在，有不少的措施可以解决 epoll 的惊群。Nginx 为了处理惊群问题，在应用层增加了 accept_mutex 锁，这里不再展开，有兴趣的读者可以再深入学习一下这部分的知识。

为了解决惊群问题，比较省力省心的方式是使用 SO_REUSEPORT 选项，接下来开始介绍这部分的内容。

相关视频推荐：

epoll实战揭秘-支撑亿级io的底层基石【c++后台开发】

《tcpip详解卷一》：150行代码拉开协议栈实现的篇章

学习地址：C/C++Linux服务器开发/后台架构师【零声教育】-学习视频教程-腾讯课堂

需要C/C++ Linux服务器架构师学习资料加qun812855908获取（资料包括C/C++，Linux，golang技术，Nginx，ZeroMQ，MySQL，Redis，fastdfs，MongoDB，ZK，流媒体，CDN，P2P，K8S，Docker，TCP/IP，协程，DPDK，ffmpeg等），免费分享

SO_REUSEPORT 选项基本使用

以下面的 test.c 代码为例。

int main() {
  struct sockaddr_in serv_addr;
  int sock_fd = socket(AF_INET, SOCK_STREAM, 0);
  setsockopt(sock_fd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));
  bzero((char *)&serv_addr, sizeof(serv_addr));
  serv_addr.sin_family = AF_INET;
  serv_addr.sin_addr.s_addr = htonl(INADDR_ANY);
  serv_addr.sin_port = htons(9090);
  int ret = bind(sock_fd, (struct sockaddr *)&serv_addr, sizeof(serv_addr));
  if (ret < 0) {
	printf("bind error, code is %d\n", ret);
	exit(1);
  }
  sleep(-1);
  return 0;
}

使用 GCC 编译上面的代码，在两个终端中运行这个可执行文件，第二次运行会 bind 端口失败，提示如下。

bind error, code is -1

修改上面的代码，给 socket 增加 SO_REUSEPORT 选项，如下所示。

#define BUF_SIZE 256

int main(void) {
  int sock_fd, connect_fd;
  char buffer[BUF_SIZE];
  struct sockaddr_in serv_addr, cli_addr;
  int cli_addr_len = sizeof(cli_addr);
  int n;

  sock_fd = socket(AF_INET, SOCK_STREAM, 0);
  int optval = 1;

  setsockopt(sock_fd, SOL_SOCKET, SO_REUSEADDR, &optval, sizeof(optval));
  setsockopt(sock_fd, SOL_SOCKET, SO_REUSEPORT, &optval, sizeof(optval));
  bzero((char *)&serv_addr, sizeof(serv_addr));
  serv_addr.sin_family = AF_INET;
  serv_addr.sin_addr.s_addr = INADDR_ANY;
  serv_addr.sin_port = htons(9090);

  int ret = bind(sock_fd, (struct sockaddr *)&serv_addr, sizeof(serv_addr));
  if (ret < 0) {
    printf("bind error, code is %d\n", ret);
    exit(1);
  }

  listen(sock_fd, 5);

  while (1) {
    connect_fd = accept(sock_fd, (struct sockaddr *)&cli_addr, &cli_addr_len);
    printf("process new request\n");
    n = read(connect_fd, buffer, BUF_SIZE);
    write(connect_fd, buffer, n);
    close(connect_fd);
  }
  return 0;
}

重新编译上面的代码，在两个终端中分别运行这个可执行文件，这次不会出现 bind 失败的情况。使用 ss 命令来查看当前的套接字

ss -tlnpe | grep -i 9090
State      Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN     0      5            *:9090 *:*                   users:(("reuse_port",pid=26897,fd=3)) uid:1000 ino:2168508 sk:ffff880079033e00 <->
LISTEN     0      5            *:9090 *:*                   users:(("reuse_port",pid=26855,fd=3)) uid:1000 ino:2168453 sk:ffff880079037440 <->

注意到最后一列中的信息，可以看到监听 9090 端口的是两个不同的 socket，它们的 inode 号分别是 2168508 和 2168453。

ss 是一个非常有用的命令，它的选项解释如下。

-t, --tcp
    显示 TCP 的 socket
-l, --listening
    只显示 listening 状态的 socket，默认情况下是不显示的。
-n, --numeric
    显示端口号而不是映射的服务名
-p, --processes
    显示进程名
-e, --extended
    显示 socket 的详细信息

写一段 shell 脚本请求 10 次 9090 端口的服务，脚本内容如下。

for i in {1..10} ; do
   echo "hello" | nc -i 1 localhost 9090
done

执行脚本，终端 1 中的进程处理了四次请求，终端 2 中的进程处理了六次请求，如下图所示。

?这个处理过程如下图所示。

?当一个新请求到来，内核是如何确定应该由哪个 LISTEN socket 来处理？接下来我们来看 SO_REUSEPORT 底层实现原理，

SO_REUSEPORT 源码分析

内核为处于 LISTEN 状态的 socket 分配了大小为 32 哈希桶。监听的端口号经过哈希算法运算打散到这些哈希桶中，相同哈希的端口采用拉链法解决冲突。当收到客户端的 SYN 握手报文以后，会根据目标端口号的哈希值计算出哈希冲突链表，然后遍历这条哈希链表得到最匹配的得分最高的 Socket。对于使用 SO_REUSEPORT 选项的 socket，可能会有多个 socket 得分最高，这个时候经过随机算法选择一个进行处理。

假设有 127.0.0.1:2222、127.0.0.1:9998、10.211.55.17:9966、10.211.55.10:2222 这几个监听套接字，这几个套接字被哈希到同一个链表中，当有 127.0.0.1:2222 套接字的 SYN 包到来时，会遍历这个哈希链表，查找得分最高的两个 socket，然后通过随机选择其中的一个。

如下图所示。

?reuse-port-hash

以 4.4 内核版本为例，这部分源码如下所示。

struct sock *__inet_lookup_listener(struct net *net,
				    struct inet_hashinfo *hashinfo,
				    const __be32 saddr, __be16 sport,
				    const __be32 daddr, const unsigned short hnum,
				    const int dif)
{
	struct sock *sk, *result;
	struct hlist_nulls_node *node;
	// 根据目标端口号生成哈希表的槽位值，这个函数返回 [0-31] 之间的值
	unsigned int hash = inet_lhashfn(net, hnum);
	// 根据哈希槽位得到当前 LISTEN 套接字的链表
	struct inet_listen_hashbucket *ilb = &hashinfo->listening_hash[hash];
	// 接下来查找最符合条件的 LISTEN 状态的 socket
	int score, hiscore, matches = 0, reuseport = 0;
	u32 phash = 0;

	rcu_read_lock();
begin:
	result = NULL;
	hiscore = 0;
	// 遍历链表中的所有套接字，给每个套接字匹配程度打分
	sk_nulls_for_each_rcu(sk, node, &ilb->head) {

	struct inet_sock *inet_me = inet_sk(sk);
	int xx = inet_me->inet_num;

	score = compute_score(sk, net, hnum, daddr, dif);
		if (score > hiscore) {
			result = sk;
			hiscore = score;
			reuseport = sk->sk_reuseport;
			// 如果 socket 启用了 SO_REUSEPORT 选项，通过源地址、源端口号、目标地址、目标端口号再次计算哈希值
			if (reuseport) {
				phash = inet_ehashfn(net, daddr, hnum,
						     saddr, sport);
				matches = 1;
			}
		} else if (score == hiscore && reuseport) { // 如果启用了 SO_REUSEPORT，则根据哈希值计算随机值
		    // matches 表示当前已经查找到多少个相同得分的 socket
			matches++;
			// 通过 phash 计算 [0, matches-1] 之间的值
			int res = reciprocal_scale(phash, matches);
			if (res == 0)
				result = sk;
			// 根据 phash 计算下一轮计算的 phash 随机值
			phash = next_pseudo_random32(phash);
		}
	}
	/*
	 * if the nulls value we got at the end of this lookup is
	 * not the expected one, we must restart lookup.
	 * We probably met an item that was moved to another chain.
	 */
	if (get_nulls_value(node) != hash + LISTENING_NULLS_BASE)
		goto begin;
	if (result) {
		if (unlikely(!atomic_inc_not_zero(&result->sk_refcnt)))
			result = NULL;
		else if (unlikely(compute_score(result, net, hnum, daddr,
				  dif) < hiscore)) {
			sock_put(result);
			goto begin;
		}
	}
	rcu_read_unlock();
	return result;
}

从上面的代码可以看出当收到 SYN 包以后，内核需要遍历整条冲突链查找得分最高的 socket，非常低效。Linux 内核在 4.5 和 4.6 版本中分别为 UDP 和 TCP 引入了 SO_REUSEPORT group 的概念，在查找匹配的 socket 时，就不用遍历整条冲突链，对于设置了 SO_REUSEPORT 选项的 socket 经过二次哈希找到对应的 SO_REUSEPORT group，从中随机选择一个进行处理。以 4.6 内核代码为例。

struct sock *__inet_lookup_listener(struct net *net,
				    struct inet_hashinfo *hashinfo,
				    struct sk_buff *skb, int doff,
				    const __be32 saddr, __be16 sport,
				    const __be32 daddr, const unsigned short hnum,
				    const int dif)
{
	struct sock *sk, *result;
	struct hlist_nulls_node *node;

	// 根据目标端口号计算 listening_hash 的哈希槽位，hash 是一个 [0, 31] 之间的值
	unsigned int hash = inet_lhashfn(net, hnum);
	// 根据哈希槽位找到冲突链
	struct inet_listen_hashbucket *ilb = &hashinfo->listening_hash[hash];
	int score, hiscore, matches = 0, reuseport = 0;
	bool select_ok = true;
	u32 phash = 0;

begin:
	result = NULL;
	// 当前遍历过程中的最高得分
	hiscore = 0;
	sk_nulls_for_each_rcu(sk, node, &ilb->head) {
	   // 根据匹配程度计算每个得分
		score = compute_score(sk, net, hnum, daddr, dif);
		if (score > hiscore) {
			result = sk;
			hiscore = score;
			reuseport = sk->sk_reuseport;

			// 有更合适的 reuseport 组，则根据 daddr、hnum、saddr、sport 再次计算哈希值
			if (reuseport) {
				phash = inet_ehashfn(net, daddr, hnum,
						     saddr, sport);
				if (select_ok) {
					struct sock *sk2;
					// 根据这个哈希值从 SO_REUSEPORT group 中选择一个 socket
					sk2 = reuseport_select_sock(sk, phash, skb, doff);
					if (sk2) {
						result = sk2;
						goto found;
					}
				}
				matches = 1;
			}
		} else if (score == hiscore && reuseport) {
		   // 当前面的 SO_REUSEPORT group 查找不适用时，退化为 4.5 版本之前的算法。
			matches++;
			if (reciprocal_scale(phash, matches) == 0)
				result = sk;
			phash = next_pseudo_random32(phash);
		}
	}
	/*
	 * if the nulls value we got at the end of this lookup is
	 * not the expected one, we must restart lookup.
	 * We probably met an item that was moved to another chain.
	 */
	if (get_nulls_value(node) != hash + LISTENING_NULLS_BASE)
		goto begin;
	if (result) {
found:
		if (unlikely(!atomic_inc_not_zero(&result->sk_refcnt)))
			result = NULL;
		else if (unlikely(compute_score(result, net, hnum, daddr,
				  dif) < hiscore)) {
			sock_put(result);
			select_ok = false;
			goto begin;
		}
	}
	rcu_read_unlock();
	return result;
}

从 SO_REUSEPORT group 中查找的逻辑如下所示。

struct sock *reuseport_select_sock(struct sock *sk,
				   u32 hash,
				   struct sk_buff *skb,
				   int hdr_len)
{
	struct sock_reuseport *reuse = sk->sk_reuseport_cb;
    // 当前 group 中 socket 的数量
	u16 socks = reuse->num_socks;
	// reciprocal_scale 函数根据 hash 生成 [0, socks-1] 之间的随机数
	// 根据哈希索引选择命中的 socket
	struct sock *sk2 = reuse->socks[reciprocal_scale(hash, socks)];
	return sk2;
}

过程如下图所示。

SO_REUSEPORT 与安全性

试想下面的场景，你的进程进程监听了某个端口，不怀好意的其他人也可以监听相同的端口来“窃取”流量信息，这种方式被称为端口劫持（port hijacking）。SO_REUSEPORT 在安全性方面的考虑主要是下面这两点。

1、只有第一个启动的进程启用了 SO_REUSEPORT 选项，后面启动的进程才可以绑定同一个端口。2、后启动的进程必须与第一个进程的有效用户ID（effective user ID）匹配才可以绑定成功。

SO_REUSEPORT 的应用

SO_REUSEPORT 带来了两个明显的好处：

• 实现了内核级的负载均衡
• 支持滚动升级（Rolling updates）

内核级的负载均衡在前面的 Nginx 的例子中已经介绍过了，这里不再赘述。使用 SO_REUSEPORT 做滚动升级的过程如下图所示。

?步骤如下所示。

1. 新启动一个新版本 v2 ，监听同一个端口，与 v1 旧版本一起处理请求。
2. 发送信号给 v1 版本的进程，让它不再接受新的请求
3. 等待一段时间，等 v1 版本的用户请求都已经处理完毕时，v1 版本的进程退出，留下 v2 版本继续服务

小结

这个小节主要介绍了 SO_REUSEPORT 参数相关的知识，本来是一个很简单的参数选项，为了讲清楚来龙去脉，还是挺复杂的。