第二章：低延迟网络架构：硬件选型、内核旁路与网络拓扑设计
做高频做市系统，网络就是你的生命线。我见过太多团队，算法写得再漂亮，结果在网络上多花了几个微秒，直接被对手吃掉。今天咱们就聊聊，怎么把这条生命线做到极致。
2.1 硬件选型：网卡与交换机的门道
先说网卡。很多人觉得网卡嘛，能通就行。但做高频，网卡就是你的第一道关卡。
网卡选型核心指标：
- PCIe 通道数：至少 x8，最好 x16。我见过有人用 x4 的卡，结果带宽直接卡脖子。
- 硬件时间戳：必须支持 PTP（IEEE 1588）。没有硬件时间戳，你的延迟数据全是假的。
- RSS 多队列：至少 8 队列以上，保证多核并行处理。
我个人推荐：Solarflare SFN8522 或 Mellanox ConnectX-5。这两款我都用过，Solarflare 的驱动生态更好，Mellanox 的吞吐量更猛。
交换机这块，其实更讲究。你想想看，交易所的行情数据进来，交换机是第一站。
| 交换机型号 | 端口延迟 | 适用场景 |
|---|---|---|
| Cisco Nexus 3548 | ~250ns | 中等规模做市 |
| Mellanox SN2700 | ~150ns | 高频交易核心 |
| Arista 7130 | ~100ns | 极限低延迟 |
嗯，这里要注意：交换机的端口延迟只是标称值，实际跑起来受背板带宽影响很大。我曾在项目中遇到 Cisco 3548 在满负载时延迟飙升到 1μs，排查了三天才发现是广播风暴。
2.2 内核旁路技术：DPDK 实战
为什么要用 DPDK？说白了，Linux 内核的网络栈太慢了。一次数据包从网卡到用户态，要经过中断处理、协议栈解析、socket 拷贝……光这些就花掉几微秒。
DPDK 的思路很简单：绕过内核，让用户态程序直接操作网卡。
// DPDK 初始化示例
int rte_eal_init(int argc, char **argv);
struct rte_mempool *mbuf_pool = rte_pktmbuf_pool_create("MBUF_POOL",
NUM_MBUFS, MBUF_CACHE_SIZE, 0, RTE_MBUF_DEFAULT_BUF_SIZE, rte_socket_id());
// 绑定网卡到用户态
rte_eth_dev_configure(port_id, nb_rx_queues, nb_tx_queues, &port_conf);
rte_eth_rx_queue_setup(port_id, 0, nb_rxd, rte_eth_dev_socket_id(port_id), NULL, mbuf_pool);这段代码看着简单，但坑不少。我曾经在绑定网卡时忘了设置 RSS 队列，结果所有流量都跑到一个核上，延迟直接翻倍。
避坑指南：DPDK 的 hugepage 配置一定要做。我见过有人没配 hugepage，结果内存分配失败，程序直接崩溃。建议至少分配 2GB 的 2MB hugepage。
DPDK 的核心优势在于：
- 零拷贝：数据直接从网卡到用户态缓冲区
- 轮询模式：没有中断开销
- CPU 亲和性：绑定特定核处理网络包
2.3 网络拓扑设计：物理布局的艺术
拓扑设计，说白了就是怎么把机器连起来。我见过最蠢的设计，是把行情服务器和交易服务器放在不同机柜，中间隔了三个交换机。
核心原则：
- 行情服务器和交易服务器必须在同一交换机下
- 物理距离越短越好，每米光纤增加约 5ns 延迟
- 避免使用中继器或光模块转换
注意：我曾经在项目中为了省成本，用了 10 米长的光纤连接两个机柜。结果发现延迟比预期多了 50ns。后来换成 1 米光纤，直接省了 40ns。
下面是我常用的拓扑结构图：
这个拓扑的关键点在于：行情和交易服务器共享同一个交换机，且物理距离控制在 1 米以内。我实测过，这种配置下从行情到达交易机，总延迟可以控制在 200ns 以内。
2.4 实战经验：一个真实的优化案例
记得有一次，我帮一家做市商优化系统。他们用的是标准 Linux 网络栈，延迟一直在 5μs 左右。我做了三件事：
- 换上 Solarflare 网卡 + DPDK
- 把服务器搬到交易所同一机柜
- 优化拓扑，去掉中间交换机
结果延迟从 5μs 降到了 800ns。客户当场就懵了，说「原来我们之前一直在用拖拉机跑 F1」。
核心结论：网络延迟优化，硬件选型占 30%，DPDK 占 40%，拓扑设计占 30%。三者缺一不可。
嗯，今天就聊这么多。记住一句话：在高频交易里，每一纳秒都是钱。你的网络架构，决定了你能赚多少钱。