Linux 网络协议栈剖析：从网卡收包到 socket 读取的全链路

对于后端开发者和系统工程师而言，Linux 网络协议栈既是每天依赖的基础设施，也常常是一个“黑盒”。理解一个数据包从网卡到达应用程序 socket 的完整路径，不仅能帮助排查性能瓶颈，还能指导高并发场景下的架构设计。本文将沿着收包方向，逐层拆解这条链路。

一、网卡收包：DMA 与 Ring Buffer

当数据帧到达物理网卡时，第一步是DMA（直接内存访问）。网卡驱动在初始化阶段会在内存中分配一块环形缓冲区（Ring Buffer），并将描述符地址写入网卡寄存器。数据帧到达后，网卡通过 DMA 将数据直接写入内核预分配的内存区域，无需 CPU 逐字节搬运。

写入完成后，网卡触发硬件中断。在现代高吞吐场景下，几乎都使用 NAPI（New API） 机制：中断处理函数只做最少的唤醒工作，然后关闭该网卡的中断，转而由软中断以轮询方式批量处理 Ring Buffer 中的数据。这种“中断+轮询”的混合模式有效避免了高包速率下的中断风暴。

Ring Buffer 的大小可通过 ethtool -G 调整。过小会导致丢包，过大则增加延迟。

二、软中断与网络子系统入口

NAPI 的轮询函数最终调用 netif_receive_skb()，这是数据包进入协议栈核心的标志。在此之前，sk_buff（简称 skb）结构体已被分配并填充，它贯穿整个协议栈，承载数据指针、协议头偏移、路由信息等元数据。

在 netif_receive_skb() 中，数据包会经过 ptype_all 和 ptype_base 两个哈希链表。前者对应 tcpdump 等抓包工具注册的协议，后者对应具体的三层协议处理函数（如 IPv4 的 ip_rcv）。如果数据包是发给本机的，就继续向上传递；如果是转发流量，则进入 IP 转发路径。

三、IP 层：路由与分片处理

进入 ip_rcv() 后，首先进行合法性校验（版本号、校验和、长度等）。随后进入 ip_rcv_finish()，这里的关键是路由查找。内核通过 ip_route_input() 决定数据包的命运：

• 发往本机 → 交给上层传输层
• 需要转发 → 进入 ip_forward()
• 无法路由 → 丢弃并返回 ICMP 不可达

如果数据包被分片，会在 ip_defrag() 中尝试重组。重组需要维护分片队列，会消耗内存和 CPU，因此在高性能场景中应尽量通过 MTU 协商避免分片。

四、传输层：TCP/UDP 处理

对于 TCP 数据包，tcp_v4_rcv() 是入口。它首先检查数据包是否属于某个已建立的连接——通过四元组（源 IP、源端口、目的 IP、目的端口）在哈希表中查找对应的 sock 结构。

找到 socket 后，进入 tcp_rcv_established() 的快速路径处理。这里有一个关键机制：TCP 预排队（TCP Prelqueue）。在软中断上下文中，内核会先将数据拷贝到 socket 的接收队列，然后才唤醒用户进程。如果 socket 处于 TCP_ESTABLISHED 状态且没有乱序，数据会直接追加到 sk_receive_queue。

对于 UDP，udp_rcv() 同样查找对应的 socket，然后将 skb 放入接收队列。UDP 没有连接状态，处理更简单，但同样需要处理校验和与队列管理。

五、Socket 接收队列与唤醒

数据进入 socket 接收队列后，内核需要通知用户进程。这里有几种机制：

1. 直接唤醒：如果进程正在 epoll_wait 或 select 上阻塞，内核会调用 sk_data_ready 回调，唤醒等待队列上的进程。
2. 软中断延迟：如果进程没有阻塞等待，数据就留在队列中，直到进程下次调用 recv() 或 read()。

在 epoll 场景下，tcp_data_queue() 会调用 sk->sk_data_ready，进而触发 ep_poll_callback，将对应的 epitem 加入就绪链表。用户进程从 epoll_wait 返回后，就知道哪些 fd 可读。

六、用户态读取：recv 与零拷贝

当用户进程调用 recv(fd, buf, len, flags) 时，内核执行 tcp_recvmsg() 或 udp_recvmsg()。核心操作是从 sk_receive_queue 中取出 skb，将数据拷贝到用户空间缓冲区。

这个拷贝是传统路径上的主要开销之一。为了减少拷贝，Linux 提供了多种优化：

• MSG_ZEROCOPY：在发送方向实现零拷贝，接收方向仍需拷贝。
• AF_XDP：绕过协议栈，直接在用户态处理数据包，适合超高性能场景。
• io_uring：通过异步接口减少系统调用次数，但数据拷贝依然存在。

对于大多数应用，拷贝开销是可接受的。真正的瓶颈往往在于系统调用次数和上下文切换。使用 epoll 边缘触发模式配合非阻塞 socket，可以显著减少无效唤醒。

七、全链路性能关键点

回顾整条链路，性能敏感点包括：

1. Ring Buffer 大小：过小丢包，过大增加延迟。
2. NAPI 轮询预算：net.core.netdev_budget 控制单次软中断处理的最大包数。
3. 协议栈分层处理：每层都有校验和计算、哈希查找等开销。
4. Socket 接收队列：net.core.rmem_max 和 net.ipv4.tcp_rmem 决定缓冲区上限。
5. 进程唤醒机制：epoll 比 select 更高效，边缘触发比水平触发更省唤醒。
6. 数据拷贝：从内核到用户态的拷贝是不可避免的，但可以通过批量读取减少系统调用。

结语

从网卡 DMA 到 socket 读取，Linux 网络协议栈经历了一条精心设计的路径，兼顾了通用性与性能。理解这条链路，有助于我们在遇到丢包、延迟抖动或吞吐瓶颈时，快速定位问题层级。无论是调整内核参数、选择 I/O 模型，还是引入 XDP 等旁路技术，都需要以对协议栈的清晰认知为基础。

未经允许不得转载：任鹏个人博客 » Linux 网络协议栈剖析：从网卡收包到 socket 读取的全链路