地址：
北京市朝阳区广顺北大街33号院1号楼1单元6685号
工作时间
周一至周五: 9AM - 7PM
周末: 10AM - 5PM
背景
在高频交易（HFT）系统中，订单从收到行情到下发撮合的全过程延迟只有几微秒乃至几十纳秒的空间。传统的 Linux 内核网络栈为通用性而设计，需进行系统调用、拷贝和上下文切换，单机难以稳定处理超过百万包每秒的消息。
为了消除这些开销，业内出现了内核旁路（kernel bypass）技术：通过将网卡缓冲区直接映射到用户态，实现零拷贝、忙轮询和无锁环形队列，完全绕过内核网络协议栈。Databento 的微观结构指南指出，使用内核旁路可以跳过系统调用，减少内核在网络收发上的干扰，进而实现 10 Gbps 以上的线速处理以及百万级包率。
内核旁路的实现原理
- 用户态网络栈：在应用内部实现 TCP/UDP 栈或直接基于原始以太帧处理，完全绕过内核 socket 接口，例如 Solarflare Onload/TCPDirect 或 Mellanox VMA。
- 零拷贝 / lock-free 环形缓冲：将网卡的 RX/TX 环映射到用户态内存，应用直接从环形队列取包并写入，无需中断、拷贝和系统调用。
- 忙轮询：为了消除中断延迟，采用 busy‑poll 方式不断轮询队列。
- Hardware offload与 DMA：现代网卡实现分段合并、检查和重试等功能，并通过硬件时间戳和 PTP 提供纳秒级同步。
- 协议裁剪与并行化：将流分类、行情解码等处理前移至网卡或 FPGA，进一步缩短“软件路程”。
主流技术对比
Solarflare Onload / TCPDirect
原理：Onload 在用户空间实现了与 BSD socket 兼容的 TCP/UDP 栈，通过 ef_vi API 直接访问 Solarflare 网卡的队列。应用无需改写大量代码即可启用旁路。TCPDirect 是面向交易网关的更轻量版。
优点：对应用几乎透明；支持标准 socket API；延迟极低。Fujitsu 与 Solarflare 的测试报告显示，64 字节消息在启用 Onload 时端到端平均延迟约 4.5 µs，最小延迟 3.96 µs。相比普通内核栈，Onload 不仅降低了延迟，还显著减小尾部抖动，因为省去了上下文切换和内存拷贝。
缺点：依赖特定硬件（Solarflare/Xilinx X2 系列）；对 UDP 多播支持有限；仅适用于单机收发，跨主机仍需标准协议；许可模式较为商业化。
Mellanox VMA / RDMA (InfiniBand & RoCE)
原理：NVIDIA Mellanox的 VMA（Messaging Accelerator）是用户空间库，利用 RDMA 方式让数据从网卡直接读写用户内存；协议处理也在用户空间实现。InfiniBand 或 RoCE 通过硬件切换实现极低延迟。
优点：官方白皮书指出，InfiniBand 模式应用延迟可低至 1.0 µs，10 GbE 模式下约 1.3 µs，交换机端口‑端口延迟分别小于 100 ns/250 ns。同时支持每秒处理三百万个数据包。RDMA 消除了 CPU 拷贝，适合跨主机低延迟通信。
缺点：部署成本高，需要特定的 InfiniBand 或 RoCE 交换网络；编程模型与传统 socket 差异较大；在不支持 RDMA 的环境下无法发挥性能优势。
DPDK（Data Plane Development Kit）
原理：DPDK 由 Intel 发起，提供用户态驱动和库，绕过内核直接处理以太网帧。应用使用rte_eth_rx_burst 等接口忙轮询获取数据包，具备零拷贝和 NUMA 优化。
优点：具有高度可定制性和开源社区支持。实测表明，相比经过优化的 Linux 内核 HTTP 服务器，DPDK 版本的服务器将平均延迟从 318–711 µs 降至 205 µs，在开启写合并优化后更降至 154 µs；吞吐量从 0.79M req/s 提升至 1.19–1.51M req/s。UDP 通信中，DPDK‑based UDPDK 将往返延迟从 95 µs 降至 29 µs（降低 69%）。
缺点：需要重写网络处理逻辑，开发成本高；采用忙轮询会占用专用 CPU 核心并耗电；操作系统网络协议栈隔离，无法直接复用现有 socket 应用。
PF_RING ZC 与 Netmap
原理：PF_RING ZC 和 Netmap 均属于轻量级旁路框架，通过修改驱动和内核模块，使用户态应用直接访问网卡缓冲区。PF_RING ZC 提供零拷贝 (ZeroCopy) 通道，Netmap 将每个端口映射为 ring-buffer，应用可在用户态批量处理。
优点：相比标准内核易于集成。研究比较表明，DPDK 与 PF_RING ZC 在 10 GbE 上能将单包延迟降至 9 µs（批量 16），而 Netmap 需要 34 µs（批量 256）；Linux 软件路由在不丢包情况下延迟 15–80 µs，而满载时延迟达到毫秒级。PF_RING ZC 还支持与传统 socket 协同，便于平滑过渡。
缺点：相比 DPDK 性能稍低；仍需内核模块支持；Netmap 对多核扩展性有限；PF_RING 商业支持付费。
XDP 与 eBPF
原理：XDP (eXpress Data Path) 是 Linux 内核中基于 eBPF 的高速数据通道，运行在驱动与内核网络栈之间。通过 eBPF 程序实现快速过滤、重定向或转发，避免了内核协议栈的复杂流程。
优点：部署简单，无需修改应用；继承 Linux 安全机制；可在千兆/万兆环境下实现几微秒级的包处理延迟；适合实现流量过滤、DOS 防护等功能。作为内核内的“旁路”，不需要忙轮询，节能友好。
缺点：目前功能以过滤/负载均衡为主，不适合实现完整的用户态协议栈；与用户空间程序数据交互仍需走 AF_XDP 或映射内存，延迟略高于完全旁路；调试较复杂。
各方面优缺点比较
总结了几种常用旁路技术与 Linux 内核栈在延迟、吞吐上的差异及优缺点。
| 技术方案 | 技术原理与特性 | 定量性能 (参考值) | 优点 | 缺点 |
|---|---|---|---|---|
| 标准 Linux 内核栈 | 通用网络协议栈，通过系统调用和拷贝处理；支持 TCP/UDP、TCP offload、软中断 | 优化前平均延迟约 700 µs，适当调优后约 320–350 µs，吞吐量 0.36–0.79M req/s | 通用兼容、稳定、易用 | 延迟高，需上下文切换；难以处理>1M pps |
| Solarflare Onload/TCPDirect | 用户态 TCP/UDP 栈与 BSD API 兼容，直接访问网卡队列 | 64B TCP 消息延迟 3.96–4.5 µs | 透明使用原有 socket；延迟极低；抖动小 | 仅适用于 Solarflare/Xilinx NIC；商业授权；跨主机无 RDMA |
| Mellanox VMA/RDMA | 利用 RDMA 在硬件级别实现内存到内存数据传输；用户态协议栈 | InfiniBand 应用延迟 ≈1.0 µs，10 GbE ≈1.3 µs；交换延迟 <100 ns | 最低延迟；支持三百万包/秒；跨主机互连 | 部署成本高；需专用交换机；编程模型复杂 |
| DPDK | 用户态驱动；忙轮询；零拷贝；批量收发 | HTTP 服务平均延迟 154–205 µs；UDP 往返延迟 29 µs；吞吐 1.2–1.5M req/s | 开源、灵活；高吞吐、高可定制性 | 需重写应用；核心需忙轮询，CPU 占用高；代码复杂 |
| PF_RING ZC | 改写驱动+内核模块；零拷贝环形缓冲；支持 socket 协作 | 单包延迟约 9 µs | 较低门槛；支持混合模式；易于集成 | 性能不如 DPDK；商业授权 |
| Netmap | 驱动/内核模块提供数据平面访问；用户态批处理 | 延迟 34 µs | 简单 API，易于移植 | 延迟较高；多核扩展性弱 |
| XDP/eBPF | 内核中的高速数据通路，通过 eBPF 程序快速处理 | 单包几微秒级（视驱动实现和程序复杂度而定） | 易部署；节能；可用于防护和流量调度 | 功能受限；无法完全代替用户态协议栈 |
总结与选型建议
内核旁路技术通过绕开内核网络栈、启用零拷贝和忙轮询，大幅降低了交易链路的延迟，并提高吞吐量和稳定性。与经过优化的 Linux 栈相比，DPDK 能将延迟减少约 70%，吞吐提升两倍以上；UDP 应用采用 DPDK 将往返延迟从 95 µs 降至 29 µs。Solarflare Onload 在 64B 消息测试中仅需 4 µs 左右；Mellanox RDMA 则能实现亚微秒级延迟。然而，这些技术通常依赖特定硬件，并需要开发人员在忙轮询和能耗之间做取舍。
选择适合的技术需结合场景：
- 行情接收与撮合前风控：若希望保留 BSD socket API、快速集成，可选 Solarflare。
- 交易网关与数据总线：对吞吐和灵活性要求高，并愿意重写应用的，可采用 DPDK；若需要与内核栈协作并简化移植，PF_RING ZC 是折中方案。
- 监控与流量过滤：不需要完整旁路，仅需快速丢弃或转发的场景可使用 XDP 或 eBPF；要求简单且跨平台兼容时可考虑 Netmap。
综合来看，内核旁路技术已成为高频交易系统构建低延迟网络的关键组成部分。开发者应在性能、功耗、生态与开发成本之间权衡，选择合适的技术为策略抢占先机。