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 端口表
为了克服上述性能问题，优化方案的核心思想是：变“动态计算”为“静态查找”。
- 预初始化静态表：
- 在应用程序启动阶段（
ff_init()时），根据配置文件中的预定义规则，预先计算并初始化一个静态的端口查找表（ff_rss_tbl），。 - 该表包含了预先调用ff_rss_check()计算好的哪些本地端口发出去的包可以返回本进程对应的网卡队列，表中包含 {{远程地址，远程端口}:{本地地址, [所有可用本地端口]}}组合，以及一些辅助数据结构，如可用端口的起始、结束索引，上次选择的到的端口索引等。
- 在应用程序启动阶段（
- 高效的端口选择：
- 当需要建立新连接时，首先尝试从这个预先生成的静态表中进行查找。
- 如果能找到一个与当前连接目标地址/端口匹配且未被占用的本地端口，则直接使用它。这个过程几乎是无锁且开销极低的(平均耗时约100-250tsc)。
- 最重要的是，静态查找表无需多次选择并计算RSS，只需要查找一次本地端口即可保证远程回包可以回到本进程的队列进行处理，极大提升了选择源端口的效率，进而提升总体的QPS性能。
- 优雅降级：
- 如果静态表中所有符合条件的端口都已被占用或该四元组未配置静态查找表，系统会自动降级到原有的
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 追求性优化能的一个典型例子。它通过以下方式解决了核心瓶颈：
- 空间换时间： 使用预计算的静态表换取运行时动态计算的开销。
- 减少调用次数： 极大降低了端口选择时的ff_rss_check()和in_pcblookup_local()的重试调用次数，实现总体系统2-6%，特殊极限场景35%以上的总体系统性能提升。
- 保证兼容： 通过降级机制保障了在任何情况下的功能正确性。
建议启用此功能的场景： 所有使用 F-Stack 作为客户端、需要高频率创建新连接（特别是短连接）的应用程序。启用后，只需在配置文件中预先定义好常用的目标服务地址，即可获得显著的性能收益。
【AI使用声明】本文初始版本使用DeepSeek-V3.1生成，然后进行人工调整；示意图片由元宝根据人工提供的提示词生成和修改