第三章：低延迟网络架构
做高频交易这些年，我最大的感触就是——网络延迟是硬骨头。你算法再牛，策略再精，数据还在路上跑，一切都白搭。今天咱们就聊聊怎么把网络延迟从微秒级压到纳秒级。
3.1 物理层优化：从线缆开始较真
很多人觉得物理层没啥好优化的，买根好网线不就完了？其实不然。我见过太多团队在软件层面死磕，结果问题出在一根劣质跳线上。
3.1.1 光纤 vs 铜缆
先说结论：短距离（<10米）用铜缆，长距离用光纤。为什么？
- 铜缆（DAC直连铜缆）：延迟约5ns/米，成本低，功耗小
- 单模光纤：延迟约4.9ns/米，抗干扰强，但需要光模块
- 多模光纤：延迟约5.1ns/米，适合数据中心内部
我个人习惯，机柜内部互联全用DAC铜缆。便宜、稳定、延迟低。但跨机柜、跨机房，必须上单模光纤。
3.1.2 连接器与端接
连接器这块，LC接口是主流。但要注意端接质量。我见过有人用便宜的快速连接器，结果回波损耗大得吓人。
建议：
- 使用预端接光纤，工厂打磨好的那种
- 现场熔接必须用OTDR测试
- 连接器清洁——每次插拔前都要擦
3.2 网络拓扑设计：少跳一跳，快一微秒
拓扑设计说白了就是——让数据走最短的路。你想想看，每多一个交换机跳点，延迟就增加几百纳秒。
3.2.1 扁平化拓扑
传统三层架构（接入-汇聚-核心）在高频交易领域已经过时了。我们用的是Spine-Leaf架构，也叫叶脊架构。
核心思想：
- 每个Leaf交换机连接到所有Spine交换机
- 任意两个Leaf之间最多两跳
- 带宽可以水平扩展
我参与过的一个项目，从传统三层改成Spine-Leaf后，端到端延迟从3.2μs降到了1.8μs。效果立竿见影。
3.2.2 交易机房内的特殊设计
交易所的机房，那才是真正的高频战场。我记得有一次去参观某交易所的托管机房，发现他们的网络设计很有意思：
- 交易服务器直接连接到交易所的接入交换机
- 中间不经过任何汇聚层
- 使用专用光纤通道，不走共享链路
说白了，就是物理上把路径缩到最短。有些交易所甚至允许你把服务器放在交换机旁边，用0.5米的跳线直连。
3.3 FPGA加速：把逻辑烧进硬件
FPGA在高频交易里有多火？这么说吧，现在稍微有点规模的交易团队，都在用FPGA做行情解析和订单处理。
3.3.1 为什么是FPGA？
CPU处理网络包，要走协议栈、中断、上下文切换。这一套下来，几十微秒就没了。FPGA呢？数据进来，直接硬件逻辑处理，纳秒级响应。
我举个例子：
// CPU处理UDP包的大致流程
1. 网卡接收数据 -> 中断CPU
2. CPU保存上下文 -> 进入中断处理
3. 协议栈解析 -> 拷贝到用户空间
4. 应用程序处理 -> 生成订单
5. 协议栈封装 -> 发送
// FPGA处理流程
1. 网卡接收数据 -> 硬件解析
2. 匹配规则 -> 生成订单
3. 直接发送
看到了吗？FPGA把5步压缩成了3步，而且每一步都是硬件级处理。
3.3.2 典型应用场景
| 场景 | CPU延迟 | FPGA延迟 | 提升倍数 |
|---|---|---|---|
| 行情解析 | 5-10μs | 100-200ns | 50x |
| 订单校验 | 3-5μs | 50-100ns | 50x |
| 风险检查 | 10-20μs | 200-500ns | 40x |
3.4 内核旁路技术：绕过操作系统
操作系统是延迟的敌人。中断、调度、锁——每一个都是延迟的制造者。内核旁路技术，说白了就是让应用程序直接跟网卡对话，跳过操作系统。
3.4.1 DPDK
DPDK（Data Plane Development Kit）是目前最主流的内核旁路方案。它的核心思想：
- 网卡驱动运行在用户态
- 使用轮询模式代替中断
- 大页内存减少TLB miss
- 无锁队列传递数据
我刚开始用DPDK时，最头疼的是内存管理。DPDK要求从大页内存池里分配，不能随便malloc。后来习惯了，发现性能确实好。
// DPDK初始化示例
int main(int argc, char *argv[]) {
// 初始化环境抽象层
rte_eal_init(argc, argv);
// 分配内存池
struct rte_mempool *mbuf_pool;
mbuf_pool = rte_pktmbuf_pool_create("MBUF_POOL",
NUM_MBUFS,
256,
0,
RTE_MBUF_DEFAULT_BUF_SIZE,
rte_socket_id());
// 初始化网卡
rte_eth_dev_configure(port_id, 1, 1, &port_conf);
// 启动轮询模式
while (1) {
struct rte_mbuf *bufs[BURST_SIZE];
uint16_t nb_rx = rte_eth_rx_burst(port_id, 0, bufs, BURST_SIZE);
// 处理数据包
}
}
3.4.2 Solarflare的OpenOnload
除了DPDK，还有另一种思路——内核旁路但保持API兼容。Solarflare的OpenOnload就是这么干的。
它的做法：
- 在用户态实现TCP/IP协议栈
- 拦截socket API调用，重定向到用户态协议栈
- 应用程序不需要改代码
嗯，这里要注意：OpenOnload虽然方便，但性能不如DPDK。它适合那些不想改代码、又想降低延迟的场景。
3.4.3 RDMA
RDMA（Remote Direct Memory Access）是另一个方向。它允许一台机器的应用程序直接读写另一台机器的内存，不需要CPU参与。
延迟有多低？
- 传统TCP：10-50μs
- DPDK：1-5μs
- RDMA：1-3μs
但RDMA的部署成本高，需要专用网卡和交换机。我建议只在最关键的交易链路上使用。
3.5 知识体系总览
下面这张图，是我对低延迟网络架构的总结。你可以看到，从物理层到应用层，每一层都有优化空间。
这张图展示了低延迟网络架构的四个层次。每一层都建立在前一层的基础上，层层递进。物理层是基础，拓扑层决定路径，FPGA层加速处理，内核旁路层消除软件开销。
在实际项目中，我建议从物理层开始排查。很多时候，延迟问题就出在一根劣质网线或者一个松动的连接器上。先把基础打牢，再谈上层优化。
好了，这一章的内容就到这里。低延迟网络架构是个系统工程，需要从硬件到软件全面考虑。希望这些经验对你有帮助。