第三章 网络延迟优化基础：从网卡到内核的极速之路
做量化交易的朋友都清楚，网络延迟就是真金白银。我见过太多团队，策略模型再牛，结果下单路径上慢了几个微秒，成交价就差了好几个tick。今天咱们就聊聊网络延迟优化的基本功——网络拓扑、网卡选型、还有内核协议栈那点事。
核心观点：网络延迟优化不是单一环节的事，而是从物理链路到软件栈的端到端工程。你想想看，光缆里的光速是固定的，但数据从网卡到应用程序的路径上，处处都是优化空间。
3.1 网络拓扑：物理距离就是延迟
先说个最基础的道理——光在光纤里跑，每公里大约增加5微秒的延迟。我在项目中遇到过，某家期货公司把服务器放在上海，结果交易所的撮合主机在北京，光缆绕来绕去，单程延迟就多了200微秒。这还没算交换机和路由器的处理时间。
所以，网络拓扑优化的第一原则：物理上尽可能靠近交易所。我个人习惯的做法是，先查清楚交易所的托管机房位置，然后直接在同一个机房或者相邻机柜部署服务器。说白了，就是“贴身肉搏”。
具体来说，有几种常见的拓扑方案：
- 同机房直连：服务器和交易所网关在同一机柜，用几米长的网线或光纤直连。延迟可以控制在1微秒以内。
- 同园区跨机柜：通过园区内的光纤网络连接，延迟通常在5-10微秒。
- 跨机房/跨城市：通过专线或公网连接，延迟从几十微秒到几百微秒不等。嗯，这种方案基本不适合高频交易。
这里有个避坑指南：我曾经见过一个团队，为了省托管费，把服务器放在交易所机房隔壁的大楼里，中间隔了一条马路。他们以为光纤直连没问题，结果发现光纤要绕行地下管道，实际距离多了两公里，延迟多了10微秒。所以，别只看直线距离，要看实际的光纤路由。
实战技巧：如果条件允许，用光时域反射仪（OTDR）实测一下光纤长度。别信图纸上的数字，图纸上画的是直线，实际走线可能绕了好几圈。
3.2 网卡选型与配置：Solarflare vs Mellanox
网卡是数据进入服务器的第一道关卡。普通消费级网卡延迟在几十微秒级别，而专业级网卡可以做到1-2微秒。目前量化交易圈里，主流的选择就是Solarflare和Mellanox两家。
我个人的经验是，这两家各有千秋，选哪个取决于你的具体场景。
| 特性 | Solarflare | Mellanox |
|---|---|---|
| 延迟表现 | 极致低延迟，典型值1-2微秒 | 低延迟，典型值2-3微秒 |
| 用户态网络栈 | OpenOnload（成熟稳定） | VMA（性能优秀） |
| 硬件时间戳 | 支持，精度高 | 支持，精度高 |
| 社区生态 | 金融领域应用广泛 | HPC和云计算领域更强 |
| 价格 | 较高 | 中等 |
为什么Solarflare在金融圈更流行？说白了，它的OpenOnload库可以直接绕过内核协议栈，把网络数据直接送到用户态应用程序。我刚开始用的时候，觉得这东西太神奇了——应用程序收包延迟直接从几十微秒降到了个位数微秒。
配置方面，有几个关键点要注意：
- 中断绑定：把网卡的中断绑定到特定的CPU核心上，避免中断在多个核心间迁移。我习惯用
irqbalance关闭，然后手动设置/proc/irq/xxx/smp_affinity。 - Ring Buffer大小：调大Ring Buffer可以减少丢包，但也会增加延迟。通常设置为4096或8192。
- 硬件卸载：开启TCP校验和卸载、TSO/GRO等特性，减少CPU负担。
# 示例：Solarflare网卡优化配置（ethtool）
ethtool -G eth0 rx 4096 tx 4096 # 调整Ring Buffer
ethtool -K eth0 tx-checksum-ipv4 on # 开启硬件校验和
ethtool -K eth0 tso on # 开启TCP分段卸载
ethtool -K eth0 gro on # 开启通用接收卸载
echo 2 > /proc/irq/$(cat /proc/interrupts | grep eth0 | awk '{print $1}' | head -1)/smp_affinity # 绑定到CPU核心2注意：调整Ring Buffer时，别设得太大。我曾经遇到过，把rx设为16384，结果内存占用飙升，反而因为内存访问延迟增加导致整体性能下降。嗯，凡事有个度。
3.3 内核网络协议栈优化：绕不过去的坎
即使你用了Solarflare这样的网卡，内核协议栈仍然是潜在的瓶颈。为什么？因为标准的内核网络栈是为通用场景设计的，做了很多“正确但慢”的事情——比如内存拷贝、上下文切换、锁竞争等等。
我个人习惯的做法是，从以下几个维度下手：
3.3.1 内核参数调优
先看一组常用的sysctl参数：
# 网络核心参数优化
net.core.rmem_max = 134217728 # 接收缓冲区最大值（128MB）
net.core.wmem_max = 134217728 # 发送缓冲区最大值（128MB）
net.core.rmem_default = 16777216 # 接收缓冲区默认值（16MB）
net.core.wmem_default = 16777216 # 发送缓冲区默认值（16MB）
net.core.netdev_budget = 600 # 每次轮询处理的数据包数量
net.core.netdev_budget_usecs = 1000 # 轮询时间上限（微秒）
# TCP参数优化
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.ipv4.tcp_sack = 0 # 关闭选择性确认（减少CPU开销）
net.ipv4.tcp_dsack = 0 # 关闭延迟确认
net.ipv4.tcp_fack = 0 # 关闭前向确认
net.ipv4.tcp_timestamps = 0 # 关闭时间戳（减少头部开销）你可能会问，为什么关闭SACK和Timestamps？因为这些特性虽然提高了可靠性，但增加了CPU处理开销。在低延迟场景下，我们更关心速度，而不是极端情况下的可靠性。说白了，就是“用空间换时间”。
3.3.2 中断与轮询模式
标准网卡驱动用的是中断模式——有数据来了，网卡发中断通知CPU。但中断本身就有开销，而且高频率中断会导致CPU频繁上下文切换。
解决方案是NAPI（New API）模式，也就是混合中断+轮询。网卡先发一个中断唤醒CPU，然后CPU进入轮询模式，一口气处理完所有数据包。我建议把net.core.netdev_budget设到600左右，这样每次轮询能处理足够多的包，又不会让其他任务饿死。
3.3.3 用户态网络栈
如果内核协议栈的优化还不够，那就得考虑用户态网络栈了。像Solarflare的OpenOnload、Mellanox的VMA，还有DPDK，都是把网络处理从内核搬到用户态。
我最早接触OpenOnload时，心里还犯嘀咕——绕过内核，安全吗？后来发现，人家做得相当成熟。应用程序只需要链接OpenOnload的库，然后正常使用socket API就行，底层自动绕过了内核协议栈。
# 使用OpenOnload运行你的交易程序
onload --profile=latency ./your_trading_app就这么一行命令，延迟能降一个数量级。当然，前提是你的网卡支持。
小技巧：如果用的是Mellanox网卡，可以试试VMA。配置方式类似，通过LD_PRELOAD加载VMA库即可。我实测过，在相同硬件条件下，VMA和OpenOnload的延迟表现非常接近，差距在0.5微秒以内。
3.4 知识体系总览
说了这么多，咱们用一张图来梳理一下本章的核心逻辑：
这张图把咱们今天讲的内容串起来了。从物理层到网卡层，再到内核层，每一层都有优化空间。但记住，瓶颈永远在最短的那块板。我见过有人花大价钱买了Solarflare网卡，结果服务器放在离交易所100公里外的地方，那点网卡优化根本弥补不了物理距离的延迟。
总结一下：网络延迟优化，先看物理拓扑，再选对网卡，最后调优内核。这三步走完，你的下单通道基本就具备了极速的基础。至于更高级的FPGA加速、硬件时间同步这些，那是后面章节的内容了。
好了，今天就聊到这儿。下一章咱们会深入讲讲应用层的优化，包括内存池、无锁队列这些实战技巧。嗯，到时候见。