内核网络栈的代价：系统调用、上下文切换、中断处理对延迟的影响
做低延迟回测系统，说白了就是在跟时间赛跑。我刚开始接触这个领域时，总觉得网络栈嘛，操作系统都封装好了，直接用就行。直到有一次，我在生产环境里发现一个奇怪的现象——同样的数据，有时候延迟能差出几十微秒。这让我意识到，内核网络栈远没有我们想象的那么「免费」。
今天我们就来扒一扒，内核网络栈到底在哪些地方「偷」了我们的时间。
系统调用：用户态到内核态的「过路费」
每次你调用 send() 或 recv()，CPU 都要从用户态切换到内核态。这个切换本身就有代价——保存寄存器、切换栈、检查权限……一套流程下来，几十个 CPU 周期就没了。
我做过一个测试：在 3GHz 的 CPU 上，一次空的系统调用（比如 getpid()）大约需要 70-100ns。你想想看，如果一次交易信号要经过 10 次系统调用，光这个开销就接近 1 微秒了。
关键数据：
- 一次系统调用：约 70-100ns（空调用）
- 实际网络系统调用（含数据拷贝）：约 200-500ns
- 高频交易场景下，系统调用占总延迟的 30%-50%
怎么优化？我个人习惯的做法是：
- 批量处理：把多个小包合并成一个大包发送，减少系统调用次数
- 使用零拷贝技术：比如
sendfile()、splice()，避免数据在用户态和内核态之间来回拷贝 - 考虑 DPDK：绕过内核，直接在用户态操作网卡——当然，这是后话了
上下文切换：被「打断」的代价
系统调用只是主动切换，还有更头疼的——被动上下文切换。当你的回测进程被调度器踢出去，换另一个进程进来跑，这就是一次完整的上下文切换。
一次上下文切换的代价有多大？
| 操作 | 延迟（典型值） |
|---|---|
| TLB 刷新 | 50-200 个周期 |
| 缓存污染 | 100-500 个周期 |
| 寄存器保存/恢复 | 50-100 个周期 |
| 调度器决策 | 100-300 个周期 |
| 总计 | 300-1100 个周期（约 100-370ns） |
嗯，这里要注意：上下文切换的代价不只是 CPU 周期。更致命的是缓存污染——你的热数据被踢出 L1/L2 缓存，等下次轮到你跑时，又要重新加载。这个「冷启动」的代价，可能比切换本身还大。
避坑指南：我曾经在一个回测系统里发现，把进程绑定到特定 CPU 核心（CPU affinity）后，延迟抖动从 ±50μs 降到了 ±5μs。原因很简单——避免了跨核心的上下文切换和缓存迁移。
中断处理：网卡的「敲门声」
数据包到达网卡时，网卡会触发一个硬件中断。CPU 收到中断后，暂停当前工作，去处理这个包。这个过程叫「中断处理」。
中断处理分两部分：
- 上半部（top half）：快速响应，把数据从网卡搬到内存，然后触发软中断。这部分必须快，通常只做最必要的事。
- 下半部（bottom half）：在软中断上下文里，真正处理网络协议栈。这部分可以慢一点，但也不能太慢。
问题出在哪？
每次中断，CPU 都要保存现场、跳转到中断处理函数、处理完再恢复现场。如果包来得太频繁（比如 10Gbps 线速下，每秒上千万个包），CPU 可能光处理中断就忙不过来了。
我记得有个项目，回测系统跑在 10G 网络上，结果 CPU 的软中断占用率高达 60%。这意味着只有 40% 的 CPU 在真正做回测计算。你说亏不亏？
注意：中断合并（interrupt coalescing）可以降低中断频率，但会增加单包延迟。在低延迟场景下，通常需要关闭中断合并，或者使用自适应中断节流（adaptive interrupt throttling）。
知识体系总览
下面这张图，把内核网络栈的三大延迟来源串起来了：
如何测量这些代价？
光说不练假把式。我建议你用 perf 工具来实际测量一下：
# 统计系统调用次数和耗时
perf stat -e syscalls:sys_enter_sendto,syscalls:sys_exit_sendto ./your_backtest
# 查看上下文切换次数
perf stat -e context-switches ./your_backtest
# 查看中断分布
cat /proc/interrupts | grep eth0跑一次你的回测程序，看看这些数字。我敢打赌，你会被系统调用的次数吓一跳——一个高频回测，每秒可能触发几十万次系统调用。
一个小技巧：用 strace -c 可以统计每个系统调用的耗时分布。我曾经用这个工具发现，某个回测模块里 write() 调用占了总时间的 40%。后来改成批量写入，性能直接翻倍。
总结一下
内核网络栈的三大延迟来源，说白了就是：
- 系统调用：用户态和内核态之间的「过路费」，每次 200-500ns
- 上下文切换：被调度器打断的代价，每次 100-370ns，加上缓存污染更致命
- 中断处理：网卡「敲门」带来的开销，每次 1-10μs
这三者加起来，一次简单的网络 I/O 操作，可能就要消耗 1-10 微秒。在低延迟回测系统里，这个数字是不可接受的。
怎么解决？后面我们会一步步深入。但今天你至少要知道——问题在哪，代价多大。有了这个基础，后面的优化才有方向。