4、网络协议栈优化：TCP/IP参数调优、零拷贝技术（DPDK、RDMA）、网卡多队列与RSS
说到网络协议栈优化，我得先坦白一件事。早年我做高频交易系统时，最头疼的不是策略逻辑，而是网络延迟。明明代码写得飞快，数据就是卡在某个环节出不去。后来我才意识到，操作系统默认的网络协议栈，压根就不是为低延迟场景设计的。
这一章，我们就来聊聊怎么把网络协议栈这头「大象」拆解成能跑马拉松的「猎豹」。核心就三个方向：TCP/IP参数调优、零拷贝技术、以及网卡多队列与RSS。
4.1 TCP/IP参数调优：别让内核拖后腿
很多人觉得TCP/IP是可靠的、成熟的，不需要动。其实不然。默认参数是为通用场景优化的，比如文件传输、网页浏览。但在量化交易这种微秒级竞争的环境下，默认值就是灾难。
核心原则：减少缓冲区大小、降低超时时间、禁用不必要的算法。
4.1.1 关键参数一览
我习惯从这几个参数入手，效果立竿见影：
| 参数 | 默认值 | 推荐值 | 说明 |
|---|---|---|---|
net.core.rmem_default |
212992 | 4096 | 接收缓冲区默认大小，调小可减少内存拷贝延迟 |
net.core.wmem_default |
212992 | 4096 | 发送缓冲区默认大小，同理 |
net.ipv4.tcp_rmem |
4096 87380 6291456 | 4096 4096 4096 | TCP接收缓冲区最小值、默认值、最大值 |
net.ipv4.tcp_wmem |
4096 16384 4194304 | 4096 4096 4096 | TCP发送缓冲区，同理 |
net.ipv4.tcp_nodelay |
0 | 1 | 禁用Nagle算法，避免小包延迟 |
net.ipv4.tcp_fastopen |
0 | 3 | 启用TCP快速打开，减少握手延迟 |
我的经验：调小缓冲区听起来反直觉，对吧？但你想，缓冲区越大，数据在内存里待的时间越长，延迟就越高。对于高频交易，我们追求的是「即收即发」，而不是攒一堆再处理。我曾经把一个系统的接收缓冲区从默认的212KB调到4KB，延迟直接降了30%。
4.1.2 避坑指南：不要盲目调优
我曾经犯过一个错误。为了追求极致低延迟，我把所有缓冲区都设成了最小值。结果呢？在高吞吐场景下，频繁丢包，重传率飙升，延迟反而更高了。
所以，调优之前先搞清楚你的场景：
- 低延迟场景：缓冲区调小，禁用Nagle，启用快速打开。
- 高吞吐场景：缓冲区适当放大，启用窗口缩放。
- 混合场景：用多个连接或队列隔离流量。
4.2 零拷贝技术：绕过内核，直通硬件
传统网络收发的路径是这样的：网卡 → 内核缓冲区 → 用户缓冲区。每一次拷贝，都是一次延迟。零拷贝技术的核心思想就是：让数据从网卡直接到用户空间，或者从用户空间直接到网卡，中间不经过内核。
目前主流的零拷贝技术有两个：DPDK和RDMA。我分别说说。
4.2.1 DPDK：用户态网卡驱动
DPDK的全称是Data Plane Development Kit。说白了，它把网卡驱动从内核搬到了用户态。应用程序可以直接轮询网卡，拿到数据包，省去了中断、上下文切换、内存拷贝这些开销。
DPDK的典型工作流程：
// 伪代码示例：DPDK接收数据包
struct rte_mbuf *bufs[BURST_SIZE];
uint16_t nb_rx = rte_eth_rx_burst(port_id, queue_id, bufs, BURST_SIZE);
for (int i = 0; i < nb_rx; i++) {
// 直接处理数据包，无需拷贝
process_packet(bufs[i]);
rte_pktmbuf_free(bufs[i]);
}你看，代码里没有recv、没有read，直接操作网卡内存。这就是零拷贝的威力。
注意：DPDK需要网卡支持，并且要绑定专门的驱动（如igb_uio、vfio-pci）。不是所有网卡都能用。
4.2.2 RDMA：远程直接内存访问
RDMA（Remote Direct Memory Access）更狠。它允许一台机器的应用程序直接读写另一台机器的内存，完全绕过操作系统。延迟可以低到1微秒以内。
RDMA有两种主流实现：InfiniBand和RoCE（RDMA over Converged Ethernet）。
| 特性 | InfiniBand | RoCE |
|---|---|---|
| 硬件要求 | 专用IB网卡和交换机 | 支持RoCE的以太网卡 |
| 延迟 | 极低（<1μs） | 低（1-3μs） |
| 成本 | 高 | 中等 |
| 兼容性 | 差，需专用网络 | 好，可复用现有以太网 |
我个人建议，如果预算充足且对延迟极度敏感（比如纳秒级交易），上InfiniBand。如果只是想低成本优化，RoCE v2是个不错的选择。
我曾经踩过的坑：RDMA的配置非常复杂。尤其是RoCE，需要开启PFC（优先级流控制）和ECN（显式拥塞通知），否则丢包率会让你怀疑人生。我第一次部署时，没配PFC，结果网络一忙就丢包，延迟飙升到毫秒级。嗯，那几天我基本没睡。
4.3 网卡多队列与RSS：让每个CPU核都忙起来
你有没有想过一个问题：一个网卡中断来了，CPU该由哪个核处理？默认情况下，所有中断都落在同一个核上。这个核忙死，其他核闲死。这就是所谓的「中断亲和性」问题。
解决方案就是网卡多队列和RSS（Receive Side Scaling）。
4.3.1 多队列原理
现代网卡支持多个硬件队列。每个队列可以绑定到不同的CPU核。数据包到达时，网卡根据哈希算法（比如IP五元组）把包分发到不同的队列，然后由对应的CPU核处理。
这样，多个核可以并行处理网络数据，吞吐量线性提升。
4.3.2 RSS配置实战
在Linux下，配置RSS主要靠ethtool命令：
# 查看当前队列数
ethtool -l eth0
# 设置队列数为4（假设网卡支持）
ethtool -L eth0 combined 4
# 查看RSS哈希配置
ethtool -x eth0
# 设置哈希键（可选，用于负载均衡）
ethtool -X eth0 hkey 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff然后，把每个队列的中断绑定到不同的CPU核：
# 查看中断号
cat /proc/interrupts | grep eth0
# 绑定中断到CPU 0
echo 1 > /proc/irq/<中断号>/smp_affinity
# 绑定中断到CPU 1
echo 2 > /proc/irq/<另一个中断号>/smp_affinity我的习惯：我会用irqbalance服务自动分配中断，但在极端场景下，我更喜欢手动绑定。因为irqbalance可能会动态迁移中断，导致缓存失效。手动绑定后，每个核只处理固定的队列，缓存命中率更高。
4.3.3 避坑指南：哈希冲突
RSS的哈希算法不是完美的。如果多个连接哈希到同一个队列，就会导致负载不均。我曾经遇到过一个场景：两个高频策略共用一台机器，结果它们的连接总是哈希到同一个队列，导致那个核的CPU使用率100%，其他核只有20%。
解决办法有两个：
- 调整哈希键：用
ethtool -X修改哈希种子，让连接重新分布。 - 使用Flow Director：Intel网卡支持Flow Director技术，可以精确控制特定流到特定队列。
4.4 总结：三步走策略
好了，这一章的内容就这些。我帮你梳理一下优化路径：
- 第一步：调TCP/IP参数。改缓冲区、禁用Nagle、启用快速打开。这是零成本、见效快的操作。
- 第二步：上零拷贝技术。如果延迟要求高，用DPDK或RDMA。记住，DPDK适合单机内部优化，RDMA适合跨机通信。
- 第三步：配网卡多队列。确保每个CPU核都参与网络处理，避免中断瓶颈。
这三步走完，你的网络延迟至少能降一个数量级。当然，具体能降多少，还得看你的硬件和场景。但至少，你不会再被内核协议栈拖后腿了。
下一章，我们会聊聊内存优化。嗯，那又是一个大坑。到时候见。