每日一题--网络包如何唤醒WiFi路由器的CPU
记录时间：2026年04月15日 星期三 21时30分
一、问题
你的 WiFi 路由器，收到一个网络包后，CPU 是被谁叫醒的？
这个问题听起来简单，但它是理解WiFi 驱动开发、中断处理、内核调度的起点。
二、核心结论
硬中断负责通知，软中断负责搬运，队列负责中转。
三、整体流程梳理
3.1 基础要求
- 该设备有 WiFi 模块，且能够正常联网。
3.2 大体流程（概括版）
- 数据包 A 发向设备，被 WiFi 模块拦截。
- WiFi 模块拦截后，唤醒 CPU。
- CPU 唤醒后，解析数据包。
- 获得对应进程的端口号，触发中断，告知该进程。
- 进程接收到对应数据，进行处理。
3.3 详细流程（五步拆解）
第一步：硬件敲门（硬中断）
- WiFi 模块收到完整数据包，通过中断控制器向 CPU 发送硬件中断信号。
- CPU 执行网卡驱动中预先注册好的中断处理函数：
- 屏蔽网卡的中断（表示"已收到"）。
- 通过 DMA 将数据包从网卡硬件缓冲区，拷贝到内核
sk_buff缓冲区。
- 函数结束，CPU 还给内核调度。
第二步：内核"分拣"（软中断与 NAPI）
- 硬中断相当于给内核留下一张待办便条。
- 内核在适当时机（如系统调用返回、中断处理结束），触发软中断
NET_RX_SOFTIRQ。 - NAPI 机制：驱动通过
napi_schedule()把自己的 poll 函数挂到软中断处理队列中。
第三步：批量搬运（驱动轮询）
- 软中断处理线程
ksoftirqd被唤醒，调用驱动的 poll 函数。 - poll 函数按内核预算，循环从 Ring Buffer 取出数据包，送往协议栈。
第四步：协议栈拆包与数据交付
- 网络层：解析 IP 头，判断是发给本机还是转发。
- 传输层：解析 TCP/UDP 头，根据端口号找到对应的
struct sock。 - Socket 层：数据被放入该 Socket 的接收队列。
第五步：应用取件，唤醒进程
- 进程调用
read()或recv()等阻塞函数等待数据。 - 数据进入接收队列后，进程通过系统调用，将内核态数据拷贝到用户态内存中。
四、关键名词记录
| 名词 | 说明 |
|---|---|
| 硬中断 | 硬件控制器发出的信号，需立即处理 |
| 软中断 | OS 模拟的信号，通过内核调度管理 |
| 中断处理函数 | 网卡驱动预先注册的处理函数 |
| DMA | 直接内存访问 |
sk_buff | 内核中的数据包缓冲区结构 |
| NAPI | Linux 用于避免高流量下大量中断的机制 |
struct sock | 内核中的套接字结构 |
| 接收队列 | Socket 中存放接收数据的队列 |
五、套接字结构struct sock的核心组成
5.1 状态区（协议规范）
sk_state：TCP 连接状态（LISTEN / ESTABLISHED / CLOSE_WAIT 等）。sk_prot：函数指针表，实现协议多态。- TCP 执行
tcp_sendmsg()（复杂流量控制）。 - UDP 执行
udp_sendmsg()（简单发包）。
- TCP 执行
5.2 队列区（数据中转站）
sk_receive_queue：接收队列链表头，存放sk_buff。- 每个 Socket 有独立的
struct sock，只接收属于自己的数据。
- 每个 Socket 有独立的
sk_write_queue：发送队列，数据发出前在此排队。
5.3 资源管理区（性能与限制）
sk_rcvbuf/sk_sndbuf：接收/发送缓冲区大小限制。- 内核参数
net.core.rmem_default即调整此值。
- 内核参数
sk_wq：等待队列头。- 队列为空时，调用
recv的进程挂在此处休眠。 - 数据到达后，内核唤醒等待的进程。
- 队列为空时，调用
六、一个补充理解
网卡硬件有其私有内存，"从硬件拷贝到内核态"意味着：数据从网卡硬件的私有内存，搬运到内核程序可以访问和管理的内存区域。
七、写在最后
对我来说，从软中断到应用获得数据包这一段流程最为重要，硬件相关的细节可后续再深入。