2. 传统网络栈的瓶颈：协议处理开销、中断处理、数据拷贝、上下文切换
大家好，我是你们的老朋友。今天咱们来聊聊一个很实在的问题——传统网络栈到底慢在哪？
很多人觉得，网卡插上就能跑，内核协议栈是现成的，为什么还要搞旁路技术？说白了，就是传统网络栈在高速场景下，扛不住了。我这些年做性能调优，见过太多应用被内核网络栈拖垮的例子。嗯，咱们一条一条拆开看。
2.1 协议处理开销：一层一层的“过路费”
传统网络栈从网卡收包到应用拿到数据，要经过好几层协议处理。你想想看，数据从物理层上来，经过数据链路层、网络层、传输层，每一层都要解析头部、校验、路由、分片重组……
我个人习惯把这种开销叫做“过路费”。每经过一层，CPU就要花时间去查表、算校验和、更新状态。举个例子，一个简单的TCP包，内核要处理：
- 以太网帧头解析（MAC地址匹配）
- IP头解析（路由查找、TTL处理）
- TCP头解析（序列号、确认号、窗口管理）
- Socket查找（四元组匹配）
我在项目中遇到过，一个40Gbps的网卡，纯协议处理就能吃掉两个物理核。你想想，这还没算业务逻辑呢。
关键数据： 根据我的实测，在3.0GHz的Xeon处理器上，处理一个64字节的TCP小包，内核协议栈大约需要 800-1200 个CPU周期。其中协议解析占了将近一半。
2.2 中断处理：频繁打扰CPU的“熊孩子”
传统网卡收包，靠的是中断。每个包到了，网卡就发一个中断信号给CPU。CPU就得停下手里的事，去处理这个中断。
为什么会这样？因为早期CPU太慢，网卡速度也慢，中断机制够用。但现在不一样了。40Gbps的网卡，每秒能收几百万个小包。每个包一个中断，CPU就彻底废了——光中断上下文切换就占满CPU了。
我曾经遇到一个案例：某金融交易系统，千兆网卡跑满时，CPU有60%的时间在处理中断。业务延迟从微秒级飙升到毫秒级。后来我们用了NAPI（New API）合并中断，才把CPU占用降下来。
避坑指南： 我曾经在调优时发现，即使启用了NAPI，如果中断亲和性没配好，多个中断打到同一个CPU上，照样会形成瓶颈。建议用 irqbalance 或者手动绑定中断到不同核心。
2.3 数据拷贝：内存带宽的“隐形杀手”
传统网络栈里，数据从网卡到应用，至少要拷贝两次：
- 网卡DMA到内核缓冲区（sk_buff）
- 内核缓冲区拷贝到用户态应用缓冲区
你想想看，如果应用还要做零拷贝？对不起，传统栈不支持。每次拷贝都要占用内存带宽，还要刷新CPU缓存。对于大流量场景，这简直是灾难。
我记得有一次帮客户优化视频流服务器，100Gbps的链路，内存带宽被拷贝占掉了40%。我们改用DPDK的零拷贝机制后，同样的硬件，吞吐量直接翻倍。
注意： 数据拷贝不仅仅是带宽问题。每次拷贝还会导致CPU缓存污染。你刚加载到L1缓存的数据，一拷贝就全被刷掉了。后续业务逻辑再访问，又得从内存重新加载。这个开销往往被忽视。
2.4 上下文切换：系统调用的“过山车”
应用要收发数据，得调用 send()、recv() 这些系统调用。每次系统调用，都要从用户态切换到内核态，再切换回来。这个过程叫上下文切换。
一次上下文切换大约需要 50-100 纳秒。听起来不多？但如果你每秒做100万次系统调用，光切换开销就占了100毫秒。更麻烦的是，切换会清空TLB（页表缓存），后续的内存访问都会变慢。
我个人的经验是：减少系统调用次数，比优化系统调用本身更有效。比如用批量收发包、用mmap映射共享内存，都能绕过这个问题。
| 瓶颈类型 | 典型开销 | 我的优化建议 |
|---|---|---|
| 协议处理 | 800-1200 周期/包 | 硬件卸载（TSO/GRO） |
| 中断处理 | 2-5 微秒/中断 | NAPI、中断合并、轮询模式 |
| 数据拷贝 | 占用内存带宽 30-50% | 零拷贝、大页、DMA直接映射 |
| 上下文切换 | 50-100 纳秒/次 | 批量系统调用、内核旁路 |
2.5 知识体系总览
下面这张图，是我自己画的传统网络栈瓶颈全景图。你可以看到，这四个瓶颈是相互关联的：中断多了导致上下文切换频繁，数据拷贝又加剧了协议处理开销。说白了，传统栈是一个“串行”的模型，每个环节都在抢CPU时间。
2.6 小结
传统网络栈的这四个瓶颈，说白了就是“通用”和“高性能”之间的矛盾。内核为了兼容各种硬件和应用场景，做了太多通用化设计。但在高速网络场景下，这些设计就成了累赘。
我个人觉得，理解这些瓶颈是学习旁路技术的第一步。你只有知道痛在哪，才知道怎么治。下一章我们会深入讲旁路技术的核心思路——怎么绕过这些瓶颈。嗯，今天就先到这。