Linux 网络发包的极致之路：从普通模式到 AF_XDP ZeroCopy

【内核深红】Linux 网络发包的极致之路：从普通模式到 AF_XDP ZeroCopy

在高性能网络开发中，发送数据包（TX）和接收数据包（RX）是两个截然不同的战场。接收是被动的，受限于中断和调度；而发送是主动的，受限于内存拷贝、锁竞争和硬件队列的填充速度。

本文将深入 Linux 内核，追踪一个数据包从用户态内存出发，直到被网卡 DMA 读取的完整生命周期，对比 普通模式 、AF_PACKET ZeroCopy 、AF_XDP Native 以及 AF_XDP ZeroCopy 四种路径的差异。

------ 层层关卡的标准流程

这是我们使用 send()、sendto() 或 write() 时的默认路径。它的特点是功能全、兼容性好，但路径最长，开销最大。

用户调用 ：用户程序准备好数据 buffer，调用 sendto() 系统调用。
系统调用开销：CPU 从用户态切换到内核态（Context Switch）。
内存拷贝 (性能杀手 #1) ：内核执行 copy_from_user，将数据从用户空间的堆内存拷贝到内核空间的缓冲区。
sk_buff 分配 (性能杀手 #2) ：内核 Slab 分配器分配 sk_buff 结构体（Linux 网络核心元数据），用来承载这份数据。
协议栈处理 ：
- L4：TCP/UDP 处理，计算校验和，封装头部。
- L3：IP 路由查找（决定走哪个网卡），Netfilter (Output 链) 过滤，IP 分片。
- L2：邻居子系统（ARP 查询 MAC 地址），封装以太网头。
流控 (Qdisc)：数据包进入排队规则（如 pfifo_fast 或 fq_codel）。如果队列满，可能丢包；如果有复杂流控，消耗 CPU。
驱动发送 ：驱动程序的 ndo_start_xmit 函数被调用。
映射 DMA ：驱动将 sk_buff 的数据地址映射给 DMA。
硬件发送：网卡通过 DMA 读取数据，通过物理线路发送。
释放内存 ：发送完成后，触发中断或回调，内核释放 sk_buff 内存。

📝 总结 ：1次内存拷贝 （用户->内核），1次昂贵的元数据分配 (sk_buff)，完整的协议栈和流控开销。

------ 减少了拷贝，但没减负担

这是 AF_PACKET 的发包优化模式。用户通过 mmap 申请一块共享内存环（TX_RING），直接在里面填数据。

数据填充 ：用户程序直接将数据写入 mmap 的共享 Ring Buffer 中。（注意：如果数据源在 Go/Java 堆里，这里其实用户还得自己拷贝一次进去）。
触发发送 ：用户调用 sendto()（通常参数为 NULL），或者使用 poll() 告知内核"我有数据要发"。
sk_buff 分配 (依然存在) ：
- 内核网络子系统（packet_sendmsg）收到通知。
- 关键点 ：内核依然会分配一个 sk_buff。
关联数据 (伪零拷贝) ：
- 内核不需要 执行 copy_from_user，而是直接让 sk_buff 的碎片指针（frags）指向 mmap 共享区域的物理地址。
- 注：这一步省去了数据拷贝，但 sk_buff 这个结构体本身的分配和初始化开销逃不掉。
绕过部分协议栈 ：
- 通常 AF_PACKET 用于发送 Raw Packet（已经包含以太网头），所以会跳过 L3/L4 处理。
流控 (Qdisc)：依然要经过流控队列（可能发生锁竞争）。
驱动发送 ：驱动将 sk_buff（指向共享内存）映射给 DMA。
硬件发送：网卡 DMA 读取。

📝 总结 ：消除了 copy_from_user，但依然需要分配 sk_buff，依然要走流控层。性能提升有限。

------ 告别 sk_buff 的轻量级发送

进入 XDP 时代，发包路径发生了质变。Native 模式需要驱动支持，但不需要网卡硬件支持高级零拷贝特性。

数据填充 ：用户程序将数据写入 UMEM（用户态注册的共享内存区域）。
触发发送 ：用户更新发送环（Tx Ring）的生产者指针，并调用 sendto()（或 poll()，如果配置了 Busy Poll 甚至不需要系统调用）。
驱动接管 (绕过内核栈) ：
- 内核直接调用驱动程序的 XDP 发送函数。
- 关键点 ：完全绕过了 Linux 协议栈（无 L2/L3/L4）和流控层（无 Qdisc）。
- 无 sk_buff ：内核不需要分配 sk_buff，直接处理原始数据描述符。
驱动层拷贝 (性能损耗点) ：
- 因为是 Native 模式（非 ZeroCopy），网卡硬件可能无法直接 DMA 访问用户的 UMEM 内存（或者没有建立映射）。
- 动作：驱动程序申请一块自己的 DMA 发送缓冲区（Bounce Buffer），将数据从用户的 UMEM CPU Copy 到驱动的 DMA 缓冲区。
硬件发送：网卡 DMA 读取驱动缓冲区的数据发送。

📝 总结 ：干掉了 sk_buff ，干掉了协议栈和流控 。虽然引入了一次 驱动层 CPU 拷贝，但因为路径极短，性能依然远超 AF_PACKET。

------ 物理直通的王者

这是 Linux 发包的终极形态。它要求网卡硬件、驱动和内存管理高度协同，实现用户内存直接透传给网卡。

数据填充 ：用户程序将数据写入 UMEM。
触发发送 ：用户更新 Tx Ring，调用 sendto() / poll()（配合 Busy Poll 可实现纯用户态驱动）。
驱动接管：驱动程序检测到有新数据。
描述符填充 (True ZeroCopy) ：
- 驱动程序直接将 UMEM 的物理地址填入网卡的 TX Descriptor Ring（硬件发送描述符环）。
- 关键点 ：没有任何数据拷贝。驱动只是告诉网卡："数据在用户那块内存里，你自己去拿。"
硬件发送 ：
- 网卡芯片发起 DMA 请求。
- DMA 控制器直接从用户态的 UMEM 内存读取数据，通过物理线路发出。
回收：发送完成后，网卡回写完成记录，用户态重用该 UMEM 块。

📝 总结 ：无 sk_buff ，无协议栈 ，无流控 ，无 CPU 数据拷贝。CPU 仅仅负责通知网卡干活，性能仅受限于 PCIe 带宽和 DDIO 效率。

特性	普通模式 (send)	AF_PACKET ZeroCopy	AF_XDP Native	AF_XDP ZeroCopy
核心路径	完整协议栈	协议栈 (部分绕过)	驱动直通	驱动直通
sk_buff 分配	✅ 有 (重)	✅ 有 (重)	❌ 无	❌ 无
CPU 数据拷贝	✅ 1次 (用户->内核)	❌ 0次 (映射)	✅ 1次 (UMEM->驱动)	❌ 0次 (纯DMA)
协议栈/流控	全套 (L2-L4 + Qdisc)	部分 (Qdisc)	无	无
典型性能 (单核)	< 1M pps	1M - 2M pps	10M+ pps	14M - 20M+ pps
适用场景	业务应用 (Nginx/Redis)	传统发包器 (TrafficGen)	通用高性能网关	极限发包测试、防火墙