发布于

F-Stack ff_rss_check()优化介绍

1. 概述

本文档旨在介绍 F-Stack 中对 ff_rss_check() 函数的一项重要优化。该优化通过引入一个预计算的静态端口查找表，显著提升了应用程序作为客户端主动发起大量短连接时的性能，解决了原 ff_rss_check() 函数在高并发场景下可能成为性能瓶颈的问题。

核心优化提交：e54aa4317b5d81f9f8643e491d8ec0ec1e72282a

2. 背景与问题分析

ff_rss_check() 函数在 F-Stack 中负责一个关键任务：当应用程序作为客户端发起新的 TCP 连接时，为其分配合适的本地源端口。

  • 原有实现机制： 每次需要建立新连接时，都会动态调用 ff_rss_check()。该函数会根据目标服务的 IP 和端口（4元组信息），通过一个哈希计算来选择一个 RSS（Receive Side Scaling）友好的本地端口，以确保数据包能被高效地分发到正确的 CPU 核心上处理。
  • 性能瓶颈： 在需要频繁创建短连接（例如，处理 HTTP 请求且未开启 keep-alive）的场景下，每次连接建立都需要执行一次或多次端口选择和冲突检查。这个过程涉及多次的toeplitz_hash计算(平均每次耗时约300+tsc，平均次数至少为该端口的总队列(进程)数)，在高并发压力下，会消耗可观的 CPU 资源，并成为限制连接建立速率的瓶颈。

3. 优化方案：静态 RSS 端口表

为了克服上述性能问题，优化方案的核心思想是：变“动态计算”为“静态查找”。

  1. 预初始化静态表：
    • 在应用程序启动阶段（ff_init() 时），根据配置文件中的预定义规则，预先计算并初始化一个静态的端口查找表（ff_rss_tbl），。
    • 该表包含了预先调用ff_rss_check()计算好的哪些本地端口发出去的包可以返回本进程对应的网卡队列，表中包含 {{远程地址，远程端口}:{本地地址, [所有可用本地端口]}}组合，以及一些辅助数据结构，如可用端口的起始、结束索引，上次选择的到的端口索引等。
  2. 高效的端口选择：
    • 当需要建立新连接时，首先尝试从这个预先生成的静态表中进行查找。
    • 如果能找到一个与当前连接目标地址/端口匹配且未被占用的本地端口，则直接使用它。这个过程几乎是无锁且开销极低的(平均耗时约100-250tsc)。
    • 最重要的是，静态查找表无需多次选择并计算RSS，只需要查找一次本地端口即可保证远程回包可以回到本进程的队列进行处理，极大提升了选择源端口的效率，进而提升总体的QPS性能。
  3. 优雅降级：
    • 如果静态表中所有符合条件的端口都已被占用或该四元组未配置静态查找表，系统会自动降级到原有的 ff_rss_check() 动态计算流程，确保功能的正确性。

4. 配置说明

此功能需要通过配置文件（例如 config.ini）手动开启和定义。相关配置段如下：

# 启用或禁用静态 ff_rss_check 表。
# 若启用，F-Stack 将在 APP 启动时初始化该表。
# 此后当 APP 作为客户端连接服务器时，会首先尝试从该表中选择本地端口。
[ff_rss_check_tbl]
# 启用开关：0-禁用，1-启用。默认为 0。
enable = 1
# 定义端口分配规则（4元组）。
# 格式：<网卡端口ID> <本地地址 daddr> <远程地址 saddr> <远程端口 sport>
# 单个四元组内用空格分隔，多个四元组之间用分号分隔。
# 注意：saddr/sport 二元组最多支持 16 个，同一 saddr/sport 下最多支持 4 个 daddr。
# 因此，最多支持 64 种组合，超出的配置将被忽略。
rss_tbl=0 192.168.1.10 192.168.2.10 80;0 192.168.1.10 192.168.2.11 80;0 192.168.1.10 192.168.2.12 80

配置参数详解：

  • enable: 总开关，必须设置为 1 才能启用此优化功能。
  • rss_tbl: 定义端口分配规则。每一条规则指定了网卡端口ID用于获取网卡的队列配置，对于特定的目标服务（saddr + sport），使用哪个预先分配好的本地地址（daddr）。

5. 性能提升

根据内部测试数据，该优化带来了显著的性能提升：

  • 测试场景： 客户端(wrk)向F-Stack Nginx发起http请求，使用长连接。F-Stack Nginx设置反向代理，作为客户端，频繁向多个远程服务器发起短 TCP 连接（未使用 keep-alive）。示例图如下所示：
  • 测试数据：如下表所示
  • 常规 QPS 提升约 2-6%左右，且提升的比列会随着进程数的增加而增加，因为进程数越多，原有的ff_rss_check()需要计算的平均次数就越多。
  • 某些特殊场景下提升可以达到35%以上，主要是因为在某些进程数的配置下，原始动态计算方式，随机选择源端口的次数会远超数学期望的总进程数+少量次数，导致需要大量额外调用ff_rss_check()进行计算，消耗了大量CPU资源。
    • 【注意】不同的upstream服务器配置(数量、IP、端口等)可能会导致不同的进程数存在类似问题，在本测试场景下配置8或16进程时，会出现该问题。导致该问题的具体原因则尚未完全明确，查看相关静态表、端口是否正在被占用和请求测试都正常。
    • 如下表所示分别为8和12进程Nginx调用ff_rss_check()次数的统计，可以看到8核时的随机选择次数明显超出了数学期望的（应该在8-12次左右），16核同理。
      • 其中randomtime表示内核参数net.inet.ip.portrange.randomtime的设置，因为F-Stack框架的特性，作为客户端选择源端口时此时完全随机选择效果更好，且F-Stack对随机性要求并不高，早前已经替换了性能好好很多的伪随机函数。
  • perf top截图

8进程间歇性随机(大部分不随机)时ff_rss_check()调用次数太多，热点很高

8进程完全随机，ff_rss_check()调用次数热点有一定降低

12进程，ff_rss_check()的热点则大幅下降

  • 8进程间歇随机和完全随机选择源端口QPS性能对比

6. 其他参数优化调整

F-Stack对应调整了部分参数，具体如下，其他业务如何配置可以根据自己业务的具体特点灵活调整

[freebsd.sysctl]
net.inet.tcp.delayed_ack=1 # 可以提升大并发的吞吐量
net.inet.tcp.fast_finwait2_recycle=1
net.inet.tcp.finwait2_timeout=5000
net.inet.tcp.maxtcptw=128 # 尽快释放TIME_WAIT状态的端口，增加空闲端口，减少in_pcblookup_local()的调用次数，进而减少ff_rss_check()的调用次数
net.inet.ip.portrange.randomized=1
# Always do random while connect to remote server.
# In some scenarios of F-Stack application, the performance can be improved to a certain extent, ablout 5%.
net.inet.ip.portrange.randomtime=0 # 对某些特定配置条件下原动态计算ff_rss_check()方式有一定性能提升

7. 总结

本次对 ff_rss_check() 的优化是 F-Stack 追求性优化能的一个典型例子。它通过以下方式解决了核心瓶颈：

  1. 空间换时间： 使用预计算的静态表换取运行时动态计算的开销。
  2. 减少调用次数： 极大降低了端口选择时的ff_rss_check()和in_pcblookup_local()的重试调用次数，实现总体系统2-6%，特殊极限场景35%以上的总体系统性能提升。
  3. 保证兼容： 通过降级机制保障了在任何情况下的功能正确性。

建议启用此功能的场景： 所有使用 F-Stack 作为客户端、需要高频率创建新连接（特别是短连接）的应用程序。启用后，只需在配置文件中预先定义好常用的目标服务地址，即可获得显著的性能收益。

【AI使用声明】本文初始版本使用DeepSeek-V3.1生成，然后进行人工调整；示意图片由元宝根据人工提供的提示词生成和修改

发布于

F-Stack LD_PRELOAD 测试版介绍

跳票许久许久的LD_PRELOAD功能模块（后续以 libff_syscall.so 代替）在 F-Stack dev 分支的 adapter/sysctall 目录下已经提交，支持 hook 系统内核 socket 相关接口的代码，降低已有应用迁移到 F-Stack 的门槛。下面将分别进行具体介绍， 主要包括libff_syscall.so 相关的架构涉及其中的一些思考，支持的几种模式以及如何使用等内容。

总体结论：

  • 原有应用程序的接入门槛比原本的 F-Stack 有所降低，大部分情况下可以不修改原有的用户应用程序和 F-Stack lib 的代码，而是仅修改libff_syscall.so相关代码即可适配。
  • 可以支持多 F-Stack 实例（即原 F-Stack 应用程序进程），每个 F-Stack 实例可以对应 1 个或多个用户应用程序。
    • 为了达到最佳的性能，建议一个用户应用程序（进程或线程）对应一个 fstack 实例应用程序，即为一组应用实例。
  • 每组应用实例的性能会略高于系统内核的性能，与单个标准 F-Stack 应用进程互有高低；单机整体的性能相比系统内核仍有较大的优势，但与标准 F-Stack 仍有差距。
    • 新的每组应用实例需要运行在两个 CPU 核心上，而标准 F-Stack 应用进程只需要运行在一个 CPU 核心上，总体而言性价比不高，是否使用可以视各业务的具体情况而定。
    • Nginx 600 字节的 body 内存应答测试中，长连接中相同数量的新应用实例组略高于标准 F-Stack 应用进程，短连接中相同数量的新应用实例组则略低于标准 F-Stack 应用进程，见 Nginx 接入介绍章节，但使用的 CPU 几乎翻倍。

【注意】目前 libff_syscall.so 功能尚不完善，仅供测试使用，欢迎所有的开发者一起进行完善，存在一些问题，如下所示：

  • 进程结束时尚存在内存泄漏、容易死锁等问题。
  • 有些接口（如sendmsg、readv、readmsg等)因为尚未使用到，没有优化测试，还需进一步性能优化和测试。
  • 缺乏更长时间的运行验证，可能存在一些未知的隐藏问题尚未发现。
  • 多个f-stack实例运行的时候，暂时无法作为客户端使用，如Nginx的代理。参考修改方案如下：
    • @铁皮大爷：我之前有实现过一套逻辑，和现在坐着实现的类似，但是在 hook中 加入了 rss，从延迟 socket 建立（仅在确定目标、源以后才真正的选择使用哪一个 fstack 作为 worker 进程，要求在网卡接收时，也设置 rss 对称 hash，保证输出和输入能在同一个 fstack-worke r中）。 app -> sock -> hold一个sock操作，创建 fd(fd1)，返回给用户 app -> bind -> hold一个bind操作，将 bind 参数绑定在 fd1 上，返回给用户， app -> connect -> 加个connect参数绑定在 fd1 上面，根据 rss 对称 hash 计算，选择一个 fstack 进程（worker），并将 hold 的 sock、bind、connect一并交给 fstack 进程，并等待同步返回结果。

libff_syscall.so 的编译

先设置好FF_PATH和PKG_CONFIG_PATH环境变量

export FF_PATH=/data/f-stack
export PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/local/lib64/pkgconfig:/usr/lib/pkgconfig

在adapter/sysctall目录下直接编译即可得到ibff_syscall.so的相关功能组件

cd /data/f-stack/adapter/sysctall
make clean;make all
​
ls -lrt
fstack
libff_syscall.so
helloworld_stack
helloworld_stack_thread_socket
helloworld_stack_epoll
helloworld_stack_epoll_thread_socket
helloworld_stack_epoll_kernel

下面将分别进行介绍各个组件的主要作用

fstack 实例应用程序

fstack应用程序对标的是标准版 F-Stack 中的应用程序，其运行与普通的 F-Stack 应用程序完全相同，包括配置文件及其多进程（每进程即为一个实例）的运行方式等, 具体运行方式可以参考 F-Stack 主目录的 README， 在执行 LD_PRELOAD 的用户应用程序前必须先运行 fstack实例应用程序。

fstack 应用程序的作用主要是底层对接 F-Stack API，其主函数ff_handle_each_context即为普通 F-Stack 应用的用户层 loop 函数，非空闲时或每间隔 10ms (受 HZ参数影响) 时会调用该函数去循环处理与 APP 对接的上下文，如果 APP 有对应的 API 请求，则调用实际的 F-Stack API 进行处理。

与 libff_syscall.so用户应用进程间通信使用 DPDK 的 rte_malloc 分配的 Hugepage 共享内存进行。

该函数对 libff_syscall.so 的整体性能有至关重要的影响，目前是复用了 F-Stack 主配置文件（config.ini）中的 pkt_tx_dalay参数，死循环并延迟该参数指定的值后才会回到 F-Stack 的其他处理流程中。

如果想提高 libff_syscall.so的整体性能，那么fstack实例应用程序与 APP 应用程序的匹配十分重要，只有当一个ff_handle_each_context循环中尽量匹配一次循环的所有事件时才能达到最优的性能，这里需要调十分精细的调优，但是目前还是粗略的使用 pkt_tx_dalay参数值。

【提示】pkt_tx_dalay参数的默认值为 100us， 较适合长连接的场景。如果是 Nginx 短链接的场景，则应考虑设置为 50us，可以可获得更好的性能。当然不同的用用场景如果想达到最优的性能，可能需要业务自行调整及测试。复用该参数也只是临时方案，后续如果有更优的方案，则随时可能进行调整。

libff_syscall.so

该动态库主要作用是劫持系统的 socket 相关接口，根据 fd 参数判断是调用 F-Stack的相关接口（通过上下文 sc 与 fsack 实例应用程序交互）还是系统内核的相关接口。

与fstack实例应用进程间通信使用 DPDK 的 rte_malloc 分配的 Hugepage 共享内存进行。

【注意】在第一次调用相关接口时分配相关内存，不再释放，进程退出时存在内存泄漏的问题，待修复。

F-Stack用户的应用程序 （如 helloworl 或 Nginx）设置 LD_PRELOAD劫持系统的 socket 相关 API 时使用，即可直接接入 F-Stack 开发框架，可以参考如下命令：

export LD_PRELOAD=/data/f-stack/adapter/syscall/libff_syscall.so

确保 fstack实例应用程序已经正确运行的前提下，然后启动用户应用程序。

当然如果是改造用户的 APP 使用 kqueue代替 Linux 的 epoll 相关事件接口时，也可以在用户 APP 中直接链接该运行库， 可以参考相关示例程序helloworld_stack和helloworld_stack_thread_socket对应的源文件main_stack.c和main_stack_thread_socket.c，因为不是使用的LD_PRELOAD, 所以本文档不再详细介绍。

【重要提示】一组对应的fstack应用程序和用户应用程序最好运行在同一个 CPU NUMA 节点的不同物理核上，其他场景（运行在同一个CPU核心、两个 CPU 核心跨 NUMA 节点，物理核和超线程核混用）都无法达到一组实例的最佳性能。

  • 特别的，如果 CPU 物理核心比较缺乏，可以考虑一组实例分别运行在对应的一组 CPU 的物理核心和 HT 核心上，虽然单组实例性能会有所下降（约 20% 左右），但可以使用更多的 CPU 核心，单机总性能可能会有所提升。

DEMO 演示程序 helloworld_stack*

其他编译生成的hello_world开头的可执行文件为当前libff_syscall.so支持的几种不同运行模式的相关演示程序，下一节进行具体介绍。

F-Stack LD_PRELOAD 支持的几种模式

为了适应不同应用对 socket 接口的不同使用方式，降低已有应用迁移到 F-Stack 的门槛，并尽量提高较高的性能，目前 F-Stack 的 libff_syscall.so 主要支持以下几种模式，支持多线程的 PIPELINE 模式、线程（进程）内的 RTC（run to completion）模式、同时支持 F-Stack 和内核 socket 接口的 FF_KERNEL_EVENT 模式和类似内核 SO_REUSEPORT 的 FF_MULTI_SC 模式。

支持多线程的 PIPELINE 模式

该模式为默认模式，无需额外设置任何参数直接编译libff_syscall.so即可。

在此模式下，socket 相关接口返回的 fd 可以在不同线程交叉调用，即支持 PIPELINE 模式，对已有应用的移植接入更友好，但性能上相应也会有更多的损失。

该模式除了单进程运行方式外，同时可以支持用户应用程序多进程方式运行，每个用户进程对应一个fstack实例应用程序的实例，更多信息可以参考附录的运行参数介绍。

【注意】以此默认方式接入 F-Stack 的应用程序只能使用 F-Stack 的 socket 网络接口，而不能使用系统的 socket 接口。

hook 系统 epoll 接口

对于已有的 Linux 下的应用，事件接口都是一般使用的是epoll相关接口，对于没有更多特殊要求的应用程序，可以直接使用默认的编译参数编译libff_syscall.so后使用，参考 DEMO 程序helloworld_stack_epoll， 代码文件为main_stack_epoll.c。

【注意】F-Stack 的epoll接口依然为kqueue接口的封装，使用上依然与系统标准的epoll事件接口有一定区别，主要是事件触发方式和multi accept的区别。

使用 kqueue

当然libff_syscall.so除了支持使用LD_PRELOAD方式 hook 系统的 socket 接口的方式使用，也支持普通的链接方式使用，此时除了可以使用系统的epoll事件接口之外，还可以使用 F-Stack(FreeBSD)具有的kqueue事件接口，参考 DEMO 程序helloworld_stack， 代码文件为main_stack.c。

该使用方式的性能比LD_PRELOALD使用系统epoll接口的方式有略微的性能提升。

线程（进程）内的 RTC（run to completion）模式

该模式需要设置额外的编译参数后来编译libff_syscall.so才能开启，可以在adapter/sysctall/Makefile中使能FF_THREAD_SOCKET或执行以下 shell 命令来开启。

export FF_THREAD_SOCKET=1
make clean;make all

在此模式下，socket 相关接口返回的 fd 仅可以在本线程内调用，即仅支持线程内的 RTC 模式，对已有应用的移植接入门槛稍高，但性能上相应也会有一定的提升，适合原本就以 RTC 模式运行的应用移植。

同样的，该模式除了单进程运行方式外，同时可以支持用户应用程序多进程方式运行，每个用户进程对应一个fstack实例应用程序的实例，更多信息可以参考附录的运行参数介绍。

【注意】以此默认方式接入 F-Stack 的应用程序同样只能使用 F-Stack 的 socket 网络接口，而不能使用系统的 socket 接口。

hook 系统 epoll 接口

其他同默认的 PIPELINE 模式，可以参考 DEMO 程序helloworld_stack_epoll_thread_socket， 代码文件为main_stack_epoll_thread_socket.c。

使用 kqueue

其他同默认的 PIPELINE 模式，可以参考 DEMO 程序helloworld_stack_thread_socket， 代码文件为main_stack_thread_socket.c。

FF_KERNEL_EVENT 模式

该模式可以同时支持 F-Stack 和系统内核的 socket 接口，需要设置额外的编译参数后来编译libff_syscall.so才能开启，可以在adapter/sysctall/Makefile中使能FF_KERNEL_EVENT或执行以下 shell 命令来开启。

export FF_KERNEL_EVENT=1
make clean;make all

在此模式下，epoll相关接口在调用 F-Stack 接口的同时会调用系统内核的相关接口，并将 F-Stack 返回的 fd 与系统内核返回的 fd 建立映射关系，主要为了支持两个场景：

  • 用户应用程序中有控制 fd 与 数据 fd 使用相同的 epoll fd， 如 Nginx。
  • 希望本机也可以同时访问用户应用程序监听的网络接口。
    • 如果希望单独与本机系统内核进行普通网络通信，需要额外调用socket接口，并需要指定type | SOCK_KERNEL参数，并为返回的 fd 单独调用 bind()、listen()、epoll_ctl()等接口，参考 DEMO 程序helloworld_stack_epoll_kernel， 代码文件为main_stack_epoll_kernel.c

【注意1】F-Stack 中 FreeBSD 的内核参数 kern.maxfiles不应该大于 65536（原默认值为 33554432），以保证 F-Stack 的 epoll fd 到系统内核的 epoll fd 的正确映射。

【注意2】Nginx 的无缝接入需要开启此模式，因为在 Nginx 中有多个控制 fd 与 数据 fd 使用相同的 epoll fd。

FF_MULTI_SC 模式

该模式为 Nginx 等使用内核SO_REUSEPORT且fork子进程 worker 运行等特殊的设置为设置，需要设置额外的编译参数后来编译libff_syscall.so才能开启，可以在adapter/sysctall/Makefile中使能FF_MULTI_SC或执行以下 shell 命令来开启。

export FF_MULTI_SC=1
make clean;make all

在此模式下，用户应用程序与fstack实例相关联的上下文sc除了保存在全局变量sc中之外，会额外保存在全局的scs数组中，在fork()子进程 worker 时会使用 current_worker_id设置sc变量为对应 worker 进程 fd 对应的 sc，供子进程复制及使用。

Nginx 的reuseport模式的主要流程为，主进程为每个 worker 分别调用 socket()、bind()、listen()等接口，并复制到 worker 进程，而后 woker 进程各自调用epoll相关接口处理各自的 fd, 需要各自 fd 对应的上下文 sc 才能正确运行。

【注意】Nginx 的无缝接入需要同时开启 FF_THREAD_SOCKET 和 FF_MULTI_SC 模式。

Nginx 接入libff_syscall.so介绍

Nginx(以 F-Stack 默认携带的 Nginx-1.16.1 为例)目前可以不修改任何代码直接以LD_PRELOAD动态库libff_syscall.so的方式接入 F-Stack，以下为主要步骤及效果。

编译libff_syscall.so

需要同时开启 FF_THREAD_SOCKET 和 FF_MULTI_SC 模式进行编译

export FF_PATH=/data/f-stack
export PKG_CONFIG_PATH=/usr/lib64/pkgconfig:/usr/local/lib64/pkgconfig:/usr/lib/pkgconfig
​
cd /data/f-stack/adapter/sysctall
export FF_KERNEL_EVENT=1
export FF_MULTI_SC=1
make clean;make all

配置nginx.conf

以下为主要需要注意及修改的相关配置参数示例（非全量参数）：

user  root;
worker_processes  4; # worker 数量
worker_cpu_affinity 10000 100000 1000000 10000000; # 设置 CPU 亲和性
​
events {
    worker_connections  1024;
    multi_accept on; # epoll 是封装 kqueue 接口，必须要开启
    use epoll;
}
​
http {
    access_log  off; # 关闭访问日志，用于提高测试时的网络性能，否则每次请求都需要额外调用系统的 write() 接口记录访问日志
​
    sendfile        off; # 使用 F-Stack 时需要关闭
    
    keepalive_timeout  0; # 视长连接/短链接的业务需要调整
    #keepalive_timeout  65;
    #keepalive_requests 200; # 默认每个长连接最多 100 个请求，视业务需要调整，长连接时适当提高此值可以略微提高性能
    
    server {
        listen       80 reuseport; # 应该设置 reuseport，与使用系统的内核的 reuseport 行为不太一致，但都可以提高性能
​
        access_log off;
        
        location / {
            #root   html;
            #index  index.html index.htm;
            return 200 "0123456789abcdefghijklmnopqrstuvwxyz"; # 直接返回数据用以测试单纯的网络性能
        }
    ｝
}

【注意】此处的 reuseport作用是使用多个不同的 socket fd, 而每个 fd 可以对接不同的fstack实例应用程序的上下文sc来分散请求，从而达到提高性能的目的。与系统内核的reuseport行为异曲同工。

运行

假设运行4组 Nginx – fstack 实例应用程序，可以简单按照以下步骤进行

  • 运行 fstack 实例
  • 设置config.ini中的lcore_mask=f00，即使用 CPU 核心 9-11， 其他配置按照标准 F-Stack 配置进行。
  • 参考以下命令启动 fstack 实例，并等待一段时间待 fstack 主进程和子进程都启动完成
  cd /data/f-stack
  bash ./start.sh -b adapter/syscall/fstack
  • 运行 Nginx
  • 参考以下命令配置libff_syscall.so所需的环境变量
  export LD_PRELOAD=/data/f-stack/adapter/syscall/libff_syscall.so # 设置 LD_PRELOAD libff_syscall.so
  export FF_NB_FSTACK_INSTANCE=4 # 设置有 4 个 fstack 实例应用程序，前面 nginx.conf 中也配置了 4 个worker
  • 启动 Nginx
  /usr/local/nginx/sbin/nginx # 启动 Nginx

性能对比

测试环境

CPU：Intel(R) Xeon(R) CPU E5-2670 v3 @ 2.30GHz * 2

网卡：Intel Corporation Ethernet Controller 10-Gigabit X540-AT2

OS ：TencentOS Server 3.2 (Final)

内核：5.4.119-1-tlinux4-0009.1 #1 SMP Sun Jan 23 22:20:03 CST 2022 x86_64 x86_64 x86_64 GNU/Linux

Nginx长连接

  • body 大小为 602 字节(不包括 http 头等)。
  • LD_PRELOAD 实际使用的 CPU 为几乎横轴 CPU 核心数的双倍，系统内核均衡软中断实际使用的 CPU 也远高于 worker 数量对应的 CPU 核心数量。
  • 限于时间所限，其中 LD_PRELOAD 的测试数据为以上测试环境的数据，其他为历史 40G 测试环境的数据，后续会更新为相同测试环境的数据。
  • 受网卡硬件所限，8核 LD_PRELOAD 测试带宽已经接近 10G 网卡线速(服务端出带宽9.xG，148万 RPS), 导致的与标准 F-Stack 的数据差异，实际CPU尚有一些空闲，后续应使用 40G/100G 网卡进行对比测试
  • pkt_tx_delay 参数为 100us。

Nginx短链接

  • body 大小为 602 字节(不包括 http 头等)。
  • LD_PRELOAD 实际使用的 CPU 为几乎横轴 CPU 核心数的双倍，系统内核均衡软中断实际使用的 CPU 也远高于 worker 数量对应的 CPU 核心数量。
  • 受 CPU 硬件所限（12C24HT * 2），LD_PRELOAD 测试只能测试12组应用实例组，即使用了全部 CPU 的物理核心，无法进行更多实例组的测试。
  • 8核之后 LD_PRELOAD 的性能不如标准 F-Stack 的性能，最主要是受用户应用程序和fstack应用程序的匹配度不高(ff_handle_each_context的循环次数及时间等)影响很大，并未完全达到性能极致，如果持续的精细化调整可以进一步提高性能，但是通用性也不高。
  • pkt_tx_delay 参数由 100us 调整到 50us。

附录：详细参数介绍

编译参数

本段总体介绍各个编译选项，所有参数都可以在adapter/sysctall/Makefile中开启或通过 shell 命令设置环境变量来开启。

DEBUG

开启或关闭 DEBUG 模式，主要影响优化和日志输出等， 默认关闭。

export DEBUG=-O0 -gdwarf-2 -g3

默认的优化参数为

-g -O2 -DNDEBUG

FF_THREAD_SOCKET

是否开启线程级上下文sc变量，如果开启，则 socket 相关 fd 只能在本线程中调用，一般可以略微提高性能， 默认关闭。

export FF_THREAD_SOCKET=1

FF_KERNEL_EVENT

是否开启epoll相关接口在调用 F-Stack 接口的同时调用系统内核的相关接口，并将 F-Stack 返回的 fd 与系统内核返回的 fd 建立映射关系， 默认关闭，主要为了支持两个场景：

  • 用户应用程序中有控制 fd 与 数据 fd 使用相同的 epoll fd， 如 Nginx。
  • 希望本机也可以同时访问用户应用程序监听的网络接口。
export FF_KERNEL_EVENT=1

FF_MULTI_SC

在此模式下，用户应用程序与fstack实例相关联的上下文sc除了保存在全局变量sc中之外，会额外保存在全局的scs数组中，在fork()子进程 worker 时会使用 current_worker_id设置sc变量为对应 worker 进程 fd 对应的 sc，供子进程复制及使用。 默认关闭。

export FF_KERNEL_EVENT=1

运行参数

通过设置环境变量设置一些用户应用程序需要的参数值，如果后续通过配置文件配置的话可能需要修改原有应用，所以暂时使用设置环境变量的方式。

LD_PRELOAD

设置 LD_PRELOAD 的运行库，再运行实际的应用程序，可以参考以下命令

export LD_PRELOAD=/data/f-stack/adapter/syscall/libff_syscall.so

如果想通过gdb调试应用程序，则可以参考以下命令

export LD_PRELOAD=
gdb ./helloworld_stack_epoll
(gdb) set exec-wrapper env 'LD_PRELOAD=/data/f-stack/adapter/syscall/libff_syscall.so'

FF_NB_FSTACK_INSTANCE

设置fstack实例应用程序的实例数，用于和用户应用程序的进程/线程等 worker 数量相匹配，默认1。

export FF_NB_FSTACK_INSTANCE=4

建议用户应用程序 worker 数量与fstack实例应用程序尽量 1:1 配置，可以达到更好的性能。

FF_INITIAL_LCORE_ID

配置用户应用程序的 CPU 亲和性绑定的起始 CPU 逻辑 ID，16进制，默认0x4（0b0100），即 CPU 2。

export FF_INITIAL_LCORE_ID=0x4

如果用于应用程序可以配置 CPU 亲和性，则可以忽略该参数，如 Nginx 配置文件中的worker_cpu_affinity参数。

FF_PROC_ID

配置用户应用程序的进程 ID，可以配合FF_INITIAL_LCORE_ID参数设置 CPU 亲和性的绑定，10进制递增，默认0。

export FF_PROC_ID=1

如果用于应用程序可以配置 CPU 亲和性，则可以忽略该参数，如 Nginx 配置文件中的worker_cpu_affinity参数。

发布于

Nginx TCP 多证书透明代理及 Linux/F-Stack(FreeBSD) 路由相关设置

某个 TCP 服务对外有多个域名提供相同的服务，且每个域名都是基于 TLS 的，需要通过 Nginx 对 TLS 进行卸载后转发到实际的上游服务，且上游服务必须使用客户端的源 IP，所以 Nginx 需要使用透明代理。分别需要对Nginx 和系统路由进行配置。

Nginx 配置

需要 Nginx 1.15.9 以上版本，简化配置如下所示，

stream {       
    upstream up_server {
        server 192.168.1.3:8081;
    }
    
    # 通过 map 配置不同域名(SNI)使用不同的证书文件
    # 证书为泛解析证书, 匹配泛解析域名
    # 会降低性能
    map $ssl_server_name $targetCert {
        ~*domain1.com$ /usr/local/cert/domain1.crt;
        ~*domain2.com$ /usr/local/cert/domain2.crt;
        ~*domain2.com$ /usr/local/cert/domain3.crt;
        default /usr/local/cert/domain1.crt;
    }
    
    map $ssl_server_name $targetCertKey {
        ~*domain1.com$ /usr/local/cert/domain1.key;
        ~*domain2.com$ /usr/local/cert/domain2.key;
        ~*domain2.com$ /usr/local/cert/domain3.key;
        default /usr/local/cert/domain1.key;
    }
    
    server {
        listen 8080 ssl reuseport;
    
        ssl_certificate $targetCert;
        ssl_certificate_key $targetCertKey;
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_session_tickets off;
​
        proxy_pass up_server;
        proxy_bind $remote_addr transparent; # 透明代理
    }
}

Linux 系统路由配置

因为透明代理的源 IP 是实际客户的 IP，在实际服务接受处理完响应包返回时会返回给实际的客户 IP，所以需要配置将回包发到 Nginx 进行处理，这里的上游服务为本机服务，需进行如下配置。如上游在其他服务器上，可以查看参考资料中文章并进行对应配置。

# 新建一个 DIVERT 给包打标签
iptables -t mangle -N DIVERT;
iptables -t mangle -A DIVERT -j MARK --set-mark 1;
iptables -t mangle -A DIVERT -j ACCEPT;
​
# 把本机 TCP 服务的回包给 DIVERT 处理
iptables -t mangle -A OUTPUT -p tcp -m tcp --sport 8081 -j DIVERT
​
# 有标签的包去查名为 100 的路由表
ip rule add fwmark 1 lookup 100
​
# 100的路由表里就一条默认路由，把所有包都扔到lo网卡上去
ip route add local 0.0.0.0/0 dev lo table 100

F-Stack(FreeBSD) 路由配置

F-Stack(FreeBSD) 上游回包路由配置，

# upstream 为本机时
# 假设 f-stack-0 的 IP 为 192.168.1.3，将 upstream 往外发的所有出包都转发到 F-Stack Nginx 监听的 IP 和端口即可
# 因为转发到本机地址时目的端口会被忽略，可不设置端口
ff_ipfw add 100 fwd 192.168.1.3,8080 tcp from 192.168.1.2 8081 to any out
​
# upstream 为其他机器时
# 将 upstream 通过设置网关或者 IP 隧道（需额外进行隧道配置）等方式发过来的所有入包都转发到 F-Stack Nginx 监听的 IP 和端口即可
# 因为转发到本机地址时目的端口会被忽略，可不设置端口
ff_ipfw add 100 fwd 192.168.1.3 tcp from 192.168.1.2 8081 to any in via f-stack-0

参考资料

  1. nginx TLS SNI routing, based on subdomain pattern
  2. 使用nginx的proxy_bind选项配置透明的反向代理
  3. [sslh] Using sslh transparent proxy on FreeBSD?