传统网络协议栈的瓶颈：内核协议栈处理流程、上下文切换开销、中断与轮询的权衡

做量化交易的朋友都知道，行情数据从网卡到交易策略手里，这中间每一步都可能是延迟的陷阱。今天我们就来聊聊传统内核协议栈，它到底慢在哪。

我个人习惯把内核协议栈比作一个「层层审批的衙门」。数据包进来，得经过好几道手续才能到应用程序手里。每一道手续，都是延迟。

内核协议栈处理流程：一场漫长的旅行

一个数据包从网卡到用户态应用，大概要走这么几步：

1. 网卡接收：数据包到达网卡，被DMA到内核内存的ring buffer。
2. 硬中断：网卡触发硬中断，告诉CPU「有数据来了」。
3. 软中断：硬中断处理函数唤醒软中断（ksoftirqd），开始处理数据包。
4. 协议栈处理：数据包依次经过链路层（检查MAC）、网络层（IP校验、路由查找）、传输层（TCP/UDP端口匹配）。
5. socket缓冲区：数据被拷贝到socket的接收缓冲区。
6. 唤醒用户进程：用户态进程从recv()系统调用中返回，数据从内核拷贝到用户态。

你想想看，这一圈下来，光数据拷贝就至少两次：一次DMA到内核，一次从内核拷贝到用户态。更别提那些路由查找、连接跟踪、防火墙规则检查了。

我在项目中遇到过这样的情况：同样的行情数据，用内核协议栈处理，延迟在10微秒级别；换成DPDK旁路内核后，直接降到了1微秒以内。差距就是这么明显。

上下文切换开销：看不见的杀手

上下文切换，说白了就是CPU从一个任务切换到另一个任务。每次切换，CPU都得保存当前任务的寄存器状态、加载新任务的状态、刷新TLB……

一次上下文切换大概要花多少时间？

操作	耗时（纳秒）	备注
系统调用（如recv）	100-200	用户态到内核态的切换
线程上下文切换	1000-3000	保存/恢复寄存器、TLB刷新
进程上下文切换	3000-10000	还要切换虚拟地址空间

嗯，这里要注意：一次上下文切换看起来也就几微秒，但在高频交易场景下，一个微秒可能就是几百万的盈亏。而且，上下文切换还会污染CPU缓存——你辛辛苦苦预热好的数据，切换一次就全没了。

为什么会这样？因为内核协议栈的处理路径上，中断、软中断、用户态进程之间频繁切换。每一次切换，CPU都得「换脑子」。你想想看，一个交易系统每秒处理几十万笔订单，每笔订单都要经历几次上下文切换，这开销能不大吗？

中断与轮询的权衡：鱼和熊掌

传统网卡用中断通知CPU有数据到了。中断的好处是「有数据才通知」，CPU空闲时可以睡觉。但坏处也很明显：

• 中断风暴：高流量下，每秒几十万次中断，CPU光处理中断就忙不过来了。
• 中断延迟：从网卡触发中断到CPU开始处理，中间有不可预测的延迟。
• 缓存污染：中断处理会打乱CPU的指令流水线和数据缓存。

轮询呢？就是CPU不停地去问网卡「有数据吗？有数据吗？」。好处是延迟低、可预测。坏处是CPU占用率100%，哪怕没数据也在空转。

那怎么选？

内核其实也提供了折中方案——NAPI（New API）。它结合了中断和轮询：

1. 数据包到达时，先触发一次中断。
2. 中断处理函数关闭中断，切换到轮询模式。
3. CPU持续从网卡收包，直到没有数据了，再重新开启中断。

NAPI在高流量下表现不错，但它仍然跑在内核态，仍然有系统调用和上下文切换的开销。说白了，它只是缓解了中断风暴的问题，并没有解决协议栈本身的瓶颈。

所以，对于真正的低延迟交易系统，内核协议栈的这三个瓶颈——处理流程长、上下文切换多、中断开销大——必须用旁路技术来解决。这就是后面要讲的内容了。

最后，我画了一张图，帮你直观理解传统内核协议栈的瓶颈所在：

说白了，传统内核协议栈是为通用场景设计的，它要兼顾公平性、安全性、兼容性。但在量化交易这种极端场景下，这些「兼顾」就成了累赘。我们需要的是「直通车」，而不是「层层审批」。

---

公众号:蓝海数据掘金营，微信deep3321