网络栈优化：内核网络参数调优（net.core.*）、RPS/RFS、XDP与DPDK入门对比
做量化交易系统，网络延迟就是真金白银。我见过太多团队，算法写得再漂亮，结果网络栈一跑，延迟直接多出几十微秒。今天咱们就聊聊怎么把这部分优化到极致。
一、内核网络参数调优：net.core.* 系列
Linux 内核默认的网络参数，其实是为通用场景设计的。做交易系统，你得手动拧一拧这些旋钮。我个人习惯，先把 /etc/sysctl.conf 里的这几个参数调了。
核心参数速查表
| 参数 | 默认值 | 推荐值 | 说明 |
|---|---|---|---|
| net.core.rmem_default | 212992 | 26214400 | 接收缓冲区默认大小，调大能减少丢包 |
| net.core.rmem_max | 212992 | 67108864 | 接收缓冲区最大值，我建议直接拉到 64MB |
| net.core.wmem_default | 212992 | 26214400 | 发送缓冲区默认大小 |
| net.core.wmem_max | 212992 | 67108864 | 发送缓冲区最大值 |
| net.core.netdev_budget | 300 | 600 | 一次轮询处理的数据包数量 |
| net.core.somaxconn | 128 | 65535 | TCP 连接队列长度 |
为什么调这些？说白了，交易系统在行情爆发时，数据包是井喷的。默认的缓冲区太小，内核会直接丢包。我曾经在实盘环境里遇到过，行情一快，系统就莫名其妙丢 tick 数据。查了半天，发现是 rmem_max 太小了。
我的调优习惯：改完参数后，用 sysctl -p 立即生效。但别在生产环境直接改，先压测验证。
二、RPS/RFS：软中断的负载均衡
多核 CPU 时代，网络中断都挤在一个核上，那就是浪费。RPS（Receive Packet Steering）和 RFS（Receive Flow Steering）就是解决这个问题的。
RPS 的原理：把收到的数据包，通过哈希算法分散到多个 CPU 核心上处理。说白了，就是让软中断不再只压在一个核上。
RFS 更进一步：它不光分散，还考虑数据包应该去哪个核上处理最合适。比如某个连接的应用线程在 CPU2 上跑，RFS 就把这个连接的数据包尽量发到 CPU2 上处理，减少缓存失效。
配置示例：
# 开启 RPS，将 eth0 的队列 0 映射到 CPU 0-3
echo 'f' > /sys/class/net/eth0/queues/rx-0/rps_cpus
# 开启 RFS，设置流表大小
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
echo 2048 > /sys/class/net/eth0/queues/rx-0/rps_flow_cnt嗯，这里要注意：RPS/RFS 不是万能的。如果你的网卡本身就支持多队列（RSS），那硬件级别的分流比软件更高效。我建议先看网卡是否支持 RSS，不支持再用 RPS 兜底。
避坑指南：我曾经在 40 核的机器上，把 RPS 映射到所有核。结果上下文切换开销反而增加了。后来发现，映射到一半的核效果最好。这个得根据你的业务压测来定。
三、XDP 与 DPDK：用户态网络处理的两种路径
聊到极致优化，就绕不开 XDP 和 DPDK。它们的目标一样——绕过内核协议栈，但路径完全不同。
3.1 XDP：内核里的快车道
XDP（eXpress Data Path）是在内核的网卡驱动层，挂载一个 BPF 程序。数据包还没进协议栈，就被处理了。你可以用它做：
- DDoS 防御：直接在网卡层面丢弃恶意包
- 负载均衡：根据源 IP 快速分发
- 自定义过滤：只保留你关心的行情数据
XDP 的好处是：不需要修改应用代码，通过 ip link 命令就能挂载。而且它和内核协议栈可以共存——处理不了的包，还能放回协议栈继续走。
3.2 DPDK：完全的用户态接管
DPDK（Data Plane Development Kit）更激进。它直接接管网卡，把数据包从硬件 DMA 到用户态内存，完全绕过内核。代价是什么？你得自己写驱动、自己管理内存池、自己处理轮询。
我见过一个做高频交易的朋友，用 DPDK 把行情接收延迟压到了 1 微秒以内。但代价是开发周期长了三倍。
3.3 对比表格
| 维度 | XDP | DPDK |
|---|---|---|
| 延迟 | 亚微秒级（约 0.5-2μs） | 亚微秒级（约 0.2-1μs） |
| 开发难度 | 中等（BPF 编程） | 高（需要写用户态驱动） |
| 与内核共存 | 可以 | 不能，独占网卡 |
| 适用场景 | 快速过滤、监控 | 极致性能、全栈控制 |
| 社区生态 | Linux 内核原生支持 | Intel 主导，生态成熟 |
四、知识体系总览
下面这张图，是我梳理的网络栈优化知识体系。你可以把它当作一个检查清单。
五、选型建议
你想想看，你的交易系统到底需要多低的延迟？
- 如果延迟要求 10μs 以上：调内核参数 + RPS/RFS 就够了。别折腾 XDP/DPDK，开发成本不划算。
- 如果延迟要求 1-5μs：可以考虑 XDP。用 BPF 做行情过滤，把不需要的数据包直接扔掉。
- 如果延迟要求 1μs 以下：那就得上 DPDK 了。但要做好心理准备，开发周期和运维成本都会翻倍。
我的经验：大多数交易系统，调好内核参数 + 用上 RPS，延迟就能降 30%-50%。先做低成本优化，再考虑上重武器。
最后说一句：网络栈优化没有银弹。每个参数、每个技术，都要结合你的业务场景来调。我曾经见过一个团队，花了两周搞 DPDK，结果发现瓶颈在数据库查询上。嗯，先 profiling，再优化，这个顺序不能乱。
公众号:蓝海资料掘金营，微信deep3321