3. 数据包收发流程：从网卡到应用层的完整路径、中断处理与NAPI、DMA与Ring Buffer
各位好，我是老周。今天咱们聊聊数据包从网线插口一路跑到应用层的完整旅程。这章内容很关键，你搞懂了它，后面调优才能有的放矢。
很多做网络开发的朋友，写应用层代码一把好手，但一问到内核怎么把包递上来的，就含糊了。说白了，这就像开车不懂发动机原理——能开，但出毛病了你不知道从哪下手。
3.1 数据包收发的完整路径
一个数据包从物理介质到达应用层，大致要经过这么几个阶段：
- 物理层接收：网卡从网线上收到电信号/光信号，转换成数字比特流。
- MAC层处理：网卡检查目标MAC地址是否匹配，校验FCS（帧校验序列）。
- DMA传输：网卡通过DMA直接把数据写到内存的Ring Buffer里，不经过CPU。
- 中断/NAPI通知：网卡通知CPU“有包到了”。
- 驱动层处理：驱动程序从Ring Buffer取出数据，封装成sk_buff结构。
- 协议栈处理：IP层、TCP/UDP层逐层解析。
- Socket投递：数据放入对应Socket的接收队列。
- 应用层读取：用户态程序通过read/recv等系统调用拿到数据。
我当年刚接触这个流程时，觉得最神奇的就是DMA这一步——CPU居然可以完全不管数据搬运，自己干自己的活。你想想看，如果没有DMA，每来一个包CPU都要亲自去网卡寄存器里读数据，那服务器早卡死了。
核心要点：整个收包路径中，真正的“数据拷贝”只有两次——一次是网卡DMA到内核缓冲区，一次是内核态拷贝到用户态。其他环节都是指针操作和协议解析。
3.2 DMA与Ring Buffer：数据搬运的黄金搭档
DMA（Direct Memory Access）说白了就是一个硬件搬运工。网卡收到数据后，DMA控制器直接把数据写到内存里预先分配好的区域，完全绕过CPU。CPU只需要在DMA完成后处理数据就行。
那Ring Buffer是什么？它是一个环形的内存缓冲区，由驱动和网卡共享。网卡把数据写进去，驱动从中取出来。为什么用环形？因为内存地址是线性的，但数据流是循环的——写满了回到开头继续写，效率高。
我给你们画个图，一看就明白：
Ring Buffer里存的不是数据本身，而是描述符（descriptor）。每个描述符指向一个内存缓冲区，数据实际存在那里。这样做的好处是——描述符很小，操作快，数据可以分散在内存的不同位置。
我的经验：调优时，Ring Buffer的大小很关键。太小了，高并发下容易丢包；太大了，内存占用高，延迟也会增加。我一般从4096开始调，压测时观察丢包率，逐步调整。
3.3 中断处理与NAPI：告别“一包一中断”
早期网卡的工作方式是“一包一中断”——来一个包，触发一次中断，CPU停下手里的事去处理。这在低速网络下没问题，但到了千兆、万兆环境，每秒几十万个包，CPU光响应中断就忙不过来了。这就是所谓的中断风暴（Interrupt Storm）。
我记得有一次帮客户排查问题，一台48核的服务器，CPU全部花在中断处理上，业务吞吐量几乎为零。一看/proc/interrupts，好家伙，每秒上百万次中断。这就是典型的中毒症状。
NAPI（New API）就是来解决这个问题的。它的核心思想是：中断+轮询混合模式。
| 特性 | 传统中断模式 | NAPI模式 |
|---|---|---|
| 触发方式 | 每个包都触发中断 | 第一个包触发中断，后续轮询 |
| CPU开销 | 高（频繁上下文切换） | 低（批量处理） |
| 高吞吐场景 | 容易中断风暴 | 稳定高效 |
| 低延迟场景 | 响应快 | 略有增加（轮询间隔） |
| 实现复杂度 | 简单 | 中等 |
NAPI的工作流程是这样的：
- 第一个包到达，网卡触发中断。
- 中断处理程序关闭网卡中断，把网卡注册到CPU的poll列表中。
- 内核在软中断上下文中调用驱动的poll函数，批量从Ring Buffer收包。
- 直到Ring Buffer空了，或者达到预算（budget）上限，才重新开启中断。
你想想看，这就像你去食堂打饭——传统模式是来一个人就喊师傅，师傅跑一趟；NAPI是来一个人先喊师傅，然后师傅站在窗口前，后面来的人直接递盘子，直到没人了师傅才回去休息。效率高下立判。
避坑指南：我曾经在某个项目中，NAPI的budget设得太大（8192），结果导致软中断长时间占用CPU，用户态进程得不到调度，延迟飙升。后来我把budget降到64，配合RPS（Receive Packet Steering），效果好了很多。记住，NAPI不是越大越好，要结合你的业务场景来调。
3.4 从驱动到协议栈：sk_buff的诞生
驱动从Ring Buffer拿到数据后，会把它封装成内核网络子系统统一的数据结构——sk_buff（Socket Buffer）。这个结构体可以说是整个网络协议栈的“通用货币”，从驱动到应用层，所有模块都在操作它。
sk_buff里包含什么？我简单列一下关键字段：
- head/data/tail/end：四个指针，指向数据区的不同位置，用于协议头操作。
- len：当前数据长度。
- protocol：上层协议类型（ETH_P_IP、ETH_P_ARP等）。
- dev：接收/发送的网络设备。
- cb[]：控制块，各层协议用来存私有数据。
驱动填充好sk_buff后，调用netif_receive_skb()把它送入协议栈。协议栈根据sk_buff中的协议字段，逐层向上递交——IP层处理完传给TCP层，TCP层处理完放入Socket接收队列，最后应用层通过系统调用读走。
关键优化点：整个路径中，sk_buff的分配和释放是高频操作。内核使用kmem_cache（slab分配器）来管理sk_buff，避免频繁的全局内存分配。我在调优时，会检查/proc/slabinfo中skbuff相关缓存的使用情况，如果分配次数异常高，说明可能有内存泄漏或配置不当。
3.5 实战：如何观察数据包收发路径
光说不练假把式。我教你们几个实用命令，可以实时观察数据包在内核中的流转情况。
1. 查看中断分布
cat /proc/interrupts | grep eth0
# 输出示例：
# CPU0 CPU1 CPU2 CPU3
# 48: 12345 0 0 0 IR-PCI-MSI eth0
如果所有中断都落在同一个CPU上，说明没有做中断亲和性绑定。高负载下这个CPU会成为瓶颈。
2. 查看NAPI收包统计
cat /proc/net/softnet_stat
# 每列含义：CPU编号 | 处理包数 | 丢包数 | 压榨次数 | ...
第二列如果持续增长，说明NAPI的budget不够用，需要调大。
3. 查看Ring Buffer大小
ethtool -g eth0
# 输出示例：
# Ring parameters for eth0:
# Pre-set maximums:
# RX: 4096
# TX: 4096
# Current hardware settings:
# RX: 256
# TX: 256
看到没？当前只有256，最大支持4096。如果丢包率高，可以调大：
ethtool -G eth0 rx 4096 tx 4096
我的习惯：每次调完参数，我都会用perf top观察内核热点。如果看到handle_irq或net_rx_action占比过高，说明中断或NAPI处理还有优化空间。调优是个迭代过程，别指望一次搞定。
好了，这一章的内容就到这里。数据包从网卡到应用层的完整路径，说白了就是DMA搬运、Ring Buffer暂存、中断/NAPI通知、驱动封装、协议栈解析这么几步。每个环节都有优化空间，后面几章我们会逐个深入。