教你使用 SO_REUSEPORT 套接字选项提升服务性能
前言
Linux 网络栈中有一个相对较新的特性——SO_REUSEPORT 套接字选项，可以使用它来提升你的服务性能。
图 1: 上面的服务是使用并行监听器来避免请求连接瓶颈，而下面的服务只使用一个监听器来接收连接
概要
HAProxy 和 NGINX 是少数几个使用 Linux 网络栈中 TCP 的 SO_REUSEPORT 套接字选项[1]的应用程序。这个选项最初是在 4.4 BSD 中引入的，帮助在现在大型多核系统中实现高性能服务。本文的前几节将解释 TCP/IP 套接字的一些基本概念，其余部分将使用这些知识描述 SO_REUSEPORT 套接字选项的基本原理、用法和实现。
问题陈述
当运行在多核系统上时，高性能服务采用的传统方法是使用单个监听器进程接受连接，并将这些连接传递给工作进程进行处理。但在高连接负载下，监听过程成为瓶颈。服务经常使用的另一种方法是打开一个监听套接字，然后分多个进程，每个进程调用 accept() 来处理套接字上的接入的连接，同时自己执行工作。这种方法的问题是，开始拾取连接的过程往往会获得高度倾斜的连接。在本文中，我们将讨论第三种替代方法——打开多个监听套接字，使用SO_REUSEPORT 处理传入的连接，这既解决了单个进程瓶颈问题，也解决了进程之间的连接倾斜问题。
TCP 连接基础
一个 TCP 连接是由唯一的一个 5 元组来定义描述 [2]:
[ Protocol, Source IP address, Source Port, Destination IP address, Destination Port ]
客户端和服务端以不同的方式指定各个元组内元素。下面一起来了解应用程序是如何初始化每个元组元素的。
客户端应用
Protocol：该字段在根据应用程序提供的参数在创建套接字时初始化。在本文中，协议始终是 TCP。例如, socket(AF_INET SOCK_STREAM 0); /* 创建TCP套接字 */
源 IP 地址和端口：这些通常在应用程序调用 connect() 时由内核设置，而无需事先调用 bind()。内核为会选择一个合适的IP地址与目标服务通信，并从临时端口范围 (sysctl net.ipv4.ip_local_port_range) 中选择一个源端口。
目的 IP 地址和端口：由应用程序通过调用 connect() 设置。例如:
服务端应用
协议：初始化方式与客户端应用相同。
源 IP 地址和端口：由应用程序调用 bind() 时设置，例如:
目的 IP 地址及端口：客户端通过 TCP 三次握手连接服务端[3]。服务端的 TCP/IP 协议栈创建一个新的套接字来跟踪管理客户端连接，并从传入的客户端连接参数设置它的源 IP:port 和目的 IP:port。新的套接字的状态被转换为 ESTABLISHED 状态，而服务端的 LISTEN 套接字则保持不变。此时，服务端应用程序对 LISTEN 套接字上的 accept() 的调用返回对新建立的套接字的引用。有关客户端和服务端应用程序的示例实现，请参阅本文末尾的源代码清单。
【文章福利】小编推荐自己的Linux内核技术交流群:【891587639】整理了一些个人觉得比较好的学习书籍、视频资料共享在群文件里面，有需要的可以自行添加哦！！！（含视频教程、电子书、实战项目及代码)
TIME-WAIT 套接字
一个 TIME-WAIT [4]套接字是在应用程序首先关闭它的 TCP 连接时创建的。这导致 TCP 4 次握手的启动，在此过程中，套接字状态从 ESTABLISHED 变为 FIN-WAIT1、FIN-WAIT2 到 TIME-WAIT，然后套接字被关闭。由于协议原因，TIME-WAIT 状态是一种延迟状态。应用程序可以通过发送 TCP RST 包来指示 TCP/IP 栈不让连接延迟。这样一来，连接就会立即终止，而不需要经过TCP 4 次握手。下面的代码片段通过指定套接字逗留时间为 0 秒来实现连接的重置：
理解服务器套接字的不同状态
服务端通常在启动时执行以下系统调用：
任何通过 socket() 或 accept() 系统调用创建的新套接字，都会在内核中使用 struct sock 结构[5]进行跟踪管理。在上面的代码片段中，在步骤 1 中创建了一个套接字，并在步骤 2 中绑定了一个明确的地址。这个套接字在步骤 3 中被转换为 LISTEN 状态。步骤 4 中调用 accept()，阻塞直到有客户端连接到这个 IP:port。客户端完成TCP 3 次握手后，内核创建一个套接字，并返回对该套接字的引用。新套接字的状态设置为 ESTABLISHED，而 server_fd 套接字保持 LISTEN 状态。
SO_REUSEADDR 套接字选项
TCP 套接字的 SO_REUSEADDR 选项可以从以下两个用例中更好地理解:
案例 #1. 服务端应用程序重新启动分为两个步骤—退出之后再启动。在退出期间，服务端的 LISTEN 套接字立即关闭。让我们看看因为服务端的存在连接而可能出现的两种情况。
所有已建立的连接都被这个濒死的服务端进程关闭，并且那些套接字转换到 TIME-WAIT 状态。
所有已建立连接将被移交给子进程，并继续保持 ESTABLISHED 状态。
当服务端随后启动时，它尝试使用 EADDRINUSE 参数绑定到它监听端口时会失败，因为系统上的一些套接字已经绑定到这个 IP:port 组合(例如，处于 TIME-WAIT 或 ESTABLISHED 状态的套接字)。这个问题的演示如下:
此清单显示前面已经是 ESTABLISHED 状态的套接字与现在在 TIME-WAIT 状态下的套接字相同。由于这个绑定到本地地址- 10.20.1.1:45000 的套接字的存在，阻止了接下来服务为它的 LISTEN 套接字 bind() 到相同的 IP:port 组合。
用例 # 2 如果两个进程试图 bind() 到相同的 IP:port 组合，先执行 bind() 的进程会成功，而后执行 bind() 的进程会由于EADDRINUSE 而失败。此用例的另一个实例涉及到一个绑定到特定 IP:port (例如，192.168.100.1:80)的应用程序，以及另一个试图绑定到具有相同端口号的通配符 IP 地址的应用程序(例如，0.0.0.0:80)；同样，后一个 bind() 调用失败，因为它试图绑定到使用与第一个进程使用的相同端口号的所有地址。如果两个进程都在它们的套接字上设置了 SO_REUSEADDR 选项，那么两个套接字都可以成功绑定。但是，请注意一点——如果第一个进程调用了 bind() 和 listen() ，第二个进程仍然无法成功执行 bind() ，因为第一个套接字处于 LISTEN 状态。因此，这个用例的实现通常用于那些想在连接到不同服务之前绑定到特定 IP:port 的客户端。
SO_REUSEADDR 如何帮助解决这个问题的呢？当服务重新启动并在设置了 SO_REUSEADDR 的套接字上调用 bind() 时，内核忽略所有绑定到相同 IP:port 组合的非 LISTEN 套接字。Richard Stevens 在他的**《Unix网络编程[6]》** 一书 中这样描述这个特性：“ SO_REUSEADDR 允许监听服务启动并绑定它的已知端口，即使创建的这个链接之前已经把这个端口作为它的本地端口”。
但是，我们需要 SO_REUSEPORT 选项来让两个或多个进程成功地在同一个端口上调用 listen() 。这个选项将在后面的部分中进行更详细的说明。
SO_REUSEPORT 套接字选项
当现有的套接字在 ESTABLISHED 或 TIME-WAIT 状态时，SO_REUSEADDR 选项允许套接字 bind() 到相同的 IP:port 组合，而当现有的套接字在 LISTEN 状态时 SO_REUSEPORT 选项允许绑定到相同的 IP:port 。当应用程序在启用SO_REUSEPORT 的套接字上调用 bind() 或 listen() 时，内核会忽略所有套接字，包括处于 LISTEN 状态的套接字。这允许多次调用服务进程，允许多个进程监听连接。下一节我们来研究一下内核怎么实现 SO_REUSEPORT 的。
如何在多个监听器之间分配连接?
当多个套接字处于 LISTEN 状态时，内核如何决定哪个套接字——以及哪个应用程序进程——接收传入连接？还是使用了轮训、最少连接、随机或者其他方法决定的？我们来更深入地研究一下 TCP/IP 代码，以理解套接字选择是如何执行的。
注意:
为了清晰起见，本节中的数据结构和代码片段进行了大量简化——删除了一些结构体元素、函数参数、变量和不必要的代码——但又不失正确性。为了更好地理解，清单的某些部分是伪代码。
sk 表示 “struct sock” 类型的内核套接字数据结构。
skb，即套接字缓冲区，表示 “struct sk_buff” 类型的网络包。
src_addr、src_port 和 dst_addr, dst_port 分别表示：源IP:端口和目的IP:端口。
如果需要，读者可以将代码片段与实际内核源代码[5]关联起来一起看。
当传入网络数据包 skb 在提交到 TCP/IP 协议栈中时，IP 子系统就会调用 TCP 的数据包接收处理函数 tcp_v4_rcv()，并提供 skb 作为参数。tcp_v4_rcv() 会尝试寻找与此 skb 相关的套接字:
tcp_hashinfo 是一个类型为 “struct inet_hashinfo” 的全局变量，其中包含了 ESTABLISHED 和 LISTEN 套接字的两个哈希表。LISTEN 哈希表的大小为 32 个桶，如下所示:
__inet_lookup_skb() 从传入的 skb 中提取源和目的 IP 地址，并将这些地址与源和目的端口一起传递给__inet_lookup() 以查找相关的 ESTABLISHED 或 LISTEN 状态的套接字，如下所示:
__inet_lookup()_ looks in tcp_hashinfo->ehash hash-table for an already established socket matching the client 4-tuple parameters. In the absence of an established socket, it looks in tcp_hashinfo->listening_hash hash-table for a LISTEN socket. __inet_lookup() 在 tcp_hashinfo->ehash 哈希表中查找已经建立成功的套接字，匹配客户端4元组参数。如果没有找到，它将在 tcp_hashinfo->listening_hash 哈希表中查找 LISTEN 套接字。
__inet_lookup_listener() 函数进行已经存在的 LISTEN 套接字的选择：
由 reuseport_select_sock() 负责从 SO_REUSEPORT 组中选择套接字：
我们需要退一步来理解这是如何实现的。当第一个进程在启用了 SO_REUSEPORT 的套接字上调用 listen() 时，会分配它的 “struct sock” 结构中的指针- sk_reuseport_cb。该结构定义为:
该结构的最后一个元素是“灵活数组成员”[7]。整个结构是这样分配的：socks[] 数组有128个类型为“struct sock *”的元素。注意，当监听器的数量超过 128 时，这个结构会被重新分配，这个 socks[] 数组的大小就会翻倍。
调用 listen() 的第一个套接字 sk1 会被缓存在它自己的 socks[] 数组的第一个槽位中，例如： sk1->sk_reuseport_cb->socks[0] = sk1;
当随后在绑定到相同 IP:port 的其他套接字(sk2，…)上调用 listen() 时，会执行两个操作:
新套接字(sk2，…)的地址被附加到第一个套接字(sk1)的 sk_reuseport_cb->socks[] 。
新套接字的 sk_reuseport_cb 指针指向第一个套接字的 sk_reuseport_cb 指针。这确保同一组的所有 LISTEN 套接字引用相同的 sk_reuseport_cb 指针。
这两个步骤的执行如下图所示
图 2: LISTEN 套接字的 SO_REUSEPORT组
在此图中，sk1 是第一个 LISTEN 套接字，而 sk2 和sk3 是随后调用 listen() 的套接字。上面描述的两个步骤在下面的代码片段中执行，并通过 listen() 调用链执行:
现在让我们了解 reuseport_select_sock() 如何选择 LISTEN 套接字。reuseport_select_sock() 通过调用_reciprocal_scale()_ 简单地索引到 ' socks[] ' 数组中，如下所示：
reciprocal_scale() [8] 是一个优化的函数，它使用乘法和移位操作实现伪模运算
如前面所看到的， ‘phash’ 是在 __inet_lookup_listener() 函数中计算,
' num_socks ‘ 是 socks[] 数组中的套接字个数。函数 reciprocal_scale(phash, num_socks) 计算一个索引，索引>= 0，但是 < num_socks。该索引用于从 SO_REUSEPOR T套接字组中获取套接字。因此，我们看到内核通过对客户 IP:port 和服务 IP:port 计算哈希值来选择套接字。该方法对不同的 LISTEN 套接字上的连接可以做到较好的分配。
来看如何实际使用 SO_REUSEPORT 选项
让我们通过两个测试来看看 SO_REUSEPORT 的影响
一个应用程序打开一个套接字用于监听，并创建两个进程。应用程序代码路径： socket(); bind (); listen(); fork ()；
一个应用程序创建两个进程，每个进程在设置 SO_REUSEPORT 后创建一个 LISTEN 套接字。应用程序代码路径:fork();socket();setsockopt (SO_REUSEPORT);bind ();listen()；
先看看没有 SO_REUSEPORT 的套接字状态：
字符串 “ino:3854904087 sk:37d5a0” 就描述一个内核套接字。
再来看看有 SO_REUSEPORT 的套接字状态：
现在我们看到了两个不同的内核套接字——注意不同的 inode 号。
使用多个进程接受单个 LISTEN 套接字上的连接的应用程序可能会遇到严重的性能问题，因为每个进程在 accept() 中争夺相同的套接字锁，如下面的简化伪代码所示:
ock_sock() 和 release_sock() 都在内部获取并释放嵌入在’ sk ‘中的自旋锁。参见本文后面的图4观察自旋锁竞争用造成的开销。
Benchmarking SO_REUSEPORT
以下设置用于测量 SO_REUSEPORT 性能：
内核版本：4.17.13。
客户端和服务端系统都有 48 个超线程核心，并通过交换机使用一个 40g NIC 相互连接。
服务端有以下两种启动方式：
创建一个 LISTEN 套接字和 fork 48 次;或
Fork 48 次，每个子进程在启用 SO_REUSEPORT 后创建一个 LISTEN 套接字。
客户端创建 48 个进程。每个进程依次连接和断开与服务器的连接 100 万次。
客户端和服务端应用程序的源代码在本文的末尾。
SO_REUSEPORT 的性能分析
让我们使用 perf [9] 工具查看以上两个测试的性能数据。图 3 和图 4 显示了在不使用 SO_REUSEPORT 的情况下进行上述测试的硬件性能统计和内核性能。
图 3. 没有设置 SO_REUSEPORT 时硬件性能统计
图 4. 没有设置 SO_REUSEPORT 时 top 25 个函数的性能数据
图 5 和图 6 显示了使用 SO_REUSEPORT 进行上述测试的硬件性能统计和内核性能。
图 5. 设置了 SO_REUSEPORT 时硬件性能统计
图 6. 设置了 SO_REUSEPORT 时的 top 25 函数性能
客户端和服务端应用程序的源代码：
下面实现了一个用于 SO_REUSEPORT 性能测试的服务端和客户端应用程序。
服务端程序:
客户端程序
原文作者：黑光信息
