搞网络内核的人都绕不开一个结构体就是struct sk_buff通常简称 SKB。如果你只是写写应用层代码可能对它的印象停留在“内核里有个包缓冲区”但真正做过驱动、调过协议栈、排查过网络问题的工程师基本都会承认SKB 就是Linux网络子系统的灵魂一个数据包从网卡收进来再到应用层或者从应用层发出去再到网卡每一步都离不开它。甚至可以说理解了 SKB你就掌握了Linux网络收发的半壁江山。这篇文章我会从 SKB 的设计初衷开始聊逐步拆解它的内存布局、核心操作 API、克隆与共享机制再用实际收发包路径走一遍最后附上调试和避坑经验。内容偏底层但我会尽量说得像面对面交流一样直白适合做嵌入式 Linux、驱动开发、网络协议栈优化甚至是刚入门内核但想知道“网络包到底怎么在内核里溜达”的朋友。1. 为什么说 SKB 是网络包的灵魂1.1 一次网络收发SKB 串起了所有环节先抛开枯燥的源码我拿一次最简单的 TCP 收包来说。数据帧从网线进来网卡通过 DMA 把数据写到内存里的一个 ring buffer然后触发中断或者轮询NAPI驱动从 ring buffer 里取出数据这时候就得有一个数据结构来“接住”这包数据并把它向上送。这个结构就是sk_buff。接着驱动把填好的sk_buff挂入协议栈链路层处理完 Ethernet header 后会剥掉帧头IP 层看到 IP 头再做路由决策TCP 层根据四元组找到对应的 socket最后把 payload 拷贝到用户态的接收 buffer。这个过程里无论是头部的逐层剥离、控制信息的附带传递还是可能发生的分片重组、克隆复制全都发生在这同一个sk_buff上。反过来的发送路径也一样应用层调用 write 或 sendmsg数据进到内核协议栈逐层加 TCP 头、IP 头、Ethernet 头最后通过驱动把数据交给网卡 DMA 发送出去。这个过程仍然是同一个sk_buff在“变形”。所以你看SKB 不只是“一个缓冲区”它是网络包在内核中流转的容器和载体。协议栈的每一层都往里面加东西或者从里面拿东西每一层都可以附着一些自己的私有状态比如 TCP 的序列号、IP 的分片信息。没有这样一个统一的、贯穿始终的数据结构整个网络子系统就得靠无数零散的参数传递来沟通那代码早就乱成一锅粥了。1.2 为什么内核要专门设计一套 buffer 管理很多人刚接触 SKB 时会觉得很奇怪一个结构体搞得这么复杂有 head、data、tail、end 一堆指针又有 len、data_len、truesize 这些长度字段还有 control block、shared info、frag 列表看着就头大。为什么不直接用一块连续内存加一个长度字段就完事如果你自己写过简单的协议解析用连续 buffer 确实最省事但内核场景完全不一样。首先网络包在每一层都要加头encap或者去头decap。如果用固定起始地址的 buffer每层加一个头就得整体把数据往后搬这是极大浪费。SKB 的设计允许通过简单调整 data、tail 指针实现在同一块内存空间里前后腾挪。你可以理解为快递货车有一个可调节的“车厢前挡板”和“车厢后挡板”货物没变但你能随时在前面腾出空间放新的包装箱或在后面腾出空间放新货物。其次硬件 DMA 对地址对齐有要求比如某些网卡要求 IP 层四字节对齐驱动通常希望在数据开头预留一段能塞下多协议头的空间headroom这样后续每层加头都不用搬数据。再比如大包需要分片或聚合数据可能并不是一块连续的内存而是分布在多个内存页上fragments。这些都促使内核必须设计一个更高级的 data structure而不是简单的一块内存。2. SKB 的核心数据结构逐段拆解2.1 四大指针head、data、tail、end 的关系struct sk_buff里最核心的就是那四个指针我把它们的关系先画出来不用流程图直接文字描述。每个sk_buff会管理一块内存区域这块区域的起始地址叫head结束地址叫end。在这块区域内data指向当前网络包实际数据区的起始位置tail指向数据区的结束位置。因此几个关键的概念数值headroom data - head也就是当前数据区前面预留的空间tailroom end - tail当前数据区后面的可用空间len tail - data这是线性数据区的长度data_len表示非线性区分片的数据长度所以整个包的实际总长度是len data_len为什么非要有head和end因为一块内存不管被用了多少总得知道边界在哪否则数据区往后推到data len之后就失控了。而head和end定义的就是这块内存的边界。data和tail则随着协议栈的处理不断移动。收包方向链路层剥完头驱动调用skb_pulldata后移发送方向每层加头协议栈调用skb_pushdata前移。这种设计让“加头”和“去头”都成为 O(1) 操作效率极好。truesize也是一个很容易被忽略但很重要的字段。它表示整个sk_buff结构占用的真实内存大小包括sk_buff结构体本身、数据区、分片页引用、skb_shared_info 等等。做内存统计时大家通常看这个而不是看len。如果报文的 payload 很小但 headroom 很大truesize会比len大不少这会直接影响 socket 的接收队列内存阈值进而影响接收性能。2.2 控制块 cb每一层自己的小黑板sk_buff里有一个大小为sizeof(unsigned long) * 40左右的数组叫cb[]全称 control block。它最妙的地方在于不同协议层可以复用这块空间往里塞各自需要的状态信息。比如 TCP 层用它保存序列号、NAGLE 状态、快重传相关标记IP 层用它存路由信息、分片参数netfilter 甚至用它暂存 conntrack 信息。我第一次看这段代码时也很奇怪各层往里写数据那不会互相覆盖吗答案是内核严格约定不同层在使用 cb 的时候并不交叉比如 TCP 层只在 TCP 处理路径写IP 层只在 IP 处理路径写。真正写网络协议栈代码时如果你想在 hook 点传一点自定义状态cb 通常是有空间可用的。这也是为什么说 SKB 是“灵魂”因为它还附带了一块“各层通用的黑板”。使用 cb 的约束是不要在里面存放什么大的结构体放几个索引、指针、标志位就行更不要在异步上下文里乱用因为同一个 skb 可能被多个上下文触碰。我看到过因为不要命地把一个 mutex 塞进 cb 导致死锁的案例这个真要避免。2.3 非线性区与 skb_shared_info如果一个网络包的数据不是一块连续的内存而是散落在多个页里那data_len就不为零了分片信息记录在skb_shared_info结构里。这个结构位于head指向的内存的末尾通常紧接着end之后。它内部有一个frags[]数组每个 frag 保存一个页指针、偏移量和长度还有一个frag_list指向另一个sk_buff用来串联分片包。这里要提到 GRO/GSO 场景。比如收到一堆 TCP 小包通过 GRO 合并成一个逻辑大包这个大 SKB 的数据区可能还保留着第一个分片的线性数据其余分片挂在frags[]上。发送方向做 GSO 时分片信息也是模拟出来的硬件如果支持 TSO 就整包给网卡不支持就软件分成多个包再发送。理解非线性区这一点特别重要因为它直接影响“拷贝”。如果你写一个功能想抓包或者修改包内容只修改data指向的线性区往往不够还要遍历frags[]和frag_list否则你就只改了一半数据另一半还是旧内容做 NAT 或者抓包分析时就会出诡异问题。3. 一个数据包在内核中的完整旅程3.1 收包路径驱动网卡到协议栈入口看懂了结构体字段我们再走一遍实际路径。I219 这种老网卡的驱动在收包时中断处理函数或者 NAPI poll 函数会从 ring buffer 拿到 DMA 完成的数据然后调用napi_alloc_frag或netdev_alloc_skb来创建一个 SKB把 DMA buffer 里的数据拷贝到 SKB 数据区或者直接对skb_copy_to_linear_data做一次拷贝。接着调用eth_type_trans识别协议类型设置skb-protocol最后把 SKB 送进netif_receive_skb。netif_receive_skb会走到__netif_receive_core这里的逻辑也很讲究。先是 ptype_all 链上的协议比如 AF_PACKET 抓包逻辑先拿到一份 clone再往 ptype_base 上按 protocol 分发比如 IP 包就会进入ip_rcv。链路层在eth_type_trans阶段已经把 Ethernet header 视为“已处理”进入 IP 层时skb_pull会移动 data 指针越过链路层头部。如果数据包还有 VLAN tag 或者多标签驱动的处理也发生在链路层VLAN 头剥除依然是指针调整。IP 层处理里有一个关键点如果包的 IP header 和 payload 不连续比如硬件已经帮我们把 payload DMA 到多个缓冲区那ip_rcv里会调用pskb_may_pull来确保 IP 头在线性区。这个函数是很典型的“按需拷贝”需要多少头就确保多少数据在线性区不会把整个 payload 都拷贝一遍除非没办法。TCP 层入口tcp_v4_rcv则更复杂。它要根据四元组查找 socket如果 socket 处于 ESTABLISHED 状态数据会排入 receive queue。这时候如果开启了 GRO进来的可能是个聚合大包内核要做 EOR 或者直接进行 GRO 流程。再往后用户态的recvfrom会通过tcp_recvmsg把 SKB 的 payload 拷贝到用户 buffer然后视情况释放或回收这个 SKB。这段路径确实很长但每一步都可以通过 tracepoint 观测到。3.2 发送路径从 socket 到网卡 DMA发送方向用户态调用write数据先被拷贝到内核的 socket send buffer 里组成 SKB。对于 TCP这个 SKB 会先进入发送队列等待 TCP 拥塞控制调度对于 UDP通常直接通过ip_append_data或udp_sendmsg组包。之后SKB 进入 IP 层写 IP 头并计算校验和再交给邻居子系统neighbor最终到dev_queue_xmit。这里注意如果设备启用了 qdiscdev_queue_xmit会把 SKB 压进队列排队规则可能是 FIFO、pfifo_fast 或者 HTB 等。如果 qdisc 没启用就直接调用sch_direct_xmit把包发给驱动。驱动侧的发送入口通常是ndo_start_xmit调用之前会做好 DMA 映射映射。如果你仔细看代码就会发现发送的时候也有一些优化比如 skb 里的destructor回调sock_wfree之类的函数用来做 socket 写缓冲区的内存回收。如果驱动发送成功并最终释放 SKB内存会通过kfree_skb返还给 slab 缓存如果发送失败SKB 要重新排队还是丢弃则由驱动和 qdisc 共同决定。这段路径里最经典的一个坑是如果你在某个 netfilter hook 里修改了 SKB但没调整好 checksum 相关字段或者没更新 skb-len发包时可能会遇到硬件突然计算错误校验抓包发现包发了但接收端一直不认然后就是各种莫名重传。这类问题排查起来非常痛苦后面我专门写一节聊。3.3 引用计数与 skb_clone共享数据独立控制协议栈里经常要做的一件事是“同一个包给多个地方处理”。典型场景一个 IP 包除了给协议栈的上层处理还要给 tcpdump 这样的抓包程序一份。如果每次抓包都把完整数据拷一份系统性能肯定崩了。内核的解决方案是skb_clone。它不是把整个数据区复制一份而是只复制struct sk_buff结构体本身包括四大指针、控制块、长度字段让新的 SKB 和老的 SKB 共享同一个数据区和skb_shared_info。那么问题来了两个 SKB 共享数据区如果一个要修改数据内容怎么办这就引入共享信息中的dataref引用计数。需要修改数据的场景必须先调用pskb_copy或skb_copy做真正的深拷贝保证改的是自己独享的数据。抓包场景则不需要修改直接 clone 后丢给 tcpdump 就行。还有另一种共享方式是skb_get就是单纯把引用计数加一。这种用于网络栈内部临时拿一下再放回去的场景。我之前有次排查内存泄漏就是有人一直调 skb_get 导致 SKB 引用计数永远不为零kfree_skb根本不会真的释放内存。后来靠skb-users和 slabtop 对比才暴露出来。4. SKB 操作 API 与内存管理细节4.1 头尾操作四件套reserve、put、push、pull这部分是每个写网络代码的人都要背下来的基本功。我把它们放在一起对比着理解就不容易混。skb_reserve(skb, len)移动 data 指针向前腾出 headroom。一般用于分配 SKB 后立刻预留协议头空间。比如驱动在alloc_skb之后调用skb_reserve(skb, NET_SKB_PAD NET_IP_ALIGN)目的就是对齐 IP 头并留够硬件的填充字节。skb_put(skb, len)把 tail 指针向后移动 len表示在数据区尾部追加了 len 字节。通常驱动从 DMA buffer 拷贝完数据后会调用它来记录数据长度。skb_push(skb, len)把 data 指针向前移动 len表示在数据区头部增加 len 字节。每一层加 Header 都要用它。skb_pull(skb, len)把 data 指针向后移动 len表示移除数据区前面 len 字节。也就是“剥头”。它们都只做指针移动copy 和清零逻辑需要自己保证。特别注意的是skb_put会导致len字段增加而skb_push调整的是线性区长度跟data_len有微妙关系所以如果 SKB 带分片操作时更要小心。我见过一个典型 bug驱动收包后忘了调用skb_put导致上层读到的len只有一点点甚至为 0包内容其实已经在 buffer 里了但没人认账。反过来如果调了两次skb_puttail会越界侵入skb_shared_info直接把尾部的 frag 数组踩烂包就变成“幽灵包”。这种内存越界类问题靠开 KASAN 编译内核最容易定位。4.2 克隆、拷贝与非线性区修改的取舍关于skb_clone和skb_copy的区别很多文章提过但我要补充一个实际选型场景。如果写的是自己处理数据包的 XDP/eBPF 程序大多数解释器会限制你不能访问分片区域因为 skb 在线性区的部分才保证连续。如果必须处理非线性区建议直接走skb_linearize把整个 SKB 变连续代价是可能多一次大内存拷贝但在性能不敏感的路径上是正确的选择。另外pskb_copy是个常被忽略的函数。它只复制线性区和struct sk_buff结构不复制frags[]引用的页。这样一来如果只是要看头部内容或者只改了头部这个方案就非常便宜。但如果改了分片里的数据就要格外小心因为那部分数据还是和原 SKB 共享的。写内核模块时我给自己定了个原则如果需要修改包的任何部分优先skb_copy如果只是读头部或做统计优先pskb_copy或直接 clone。更底层的内存分配机制是sk_buff 结构体本身从名为skbuff_head_cache的 SLAB cache 分配数据区则来自 kmalloc、分子区或者 page_frag。两者并不是一块连续内存所以skb_copy是分别复制两次。这种分离设计让“克隆”很高效但也意味着你不能简单用memcpy(skb, clone, sizeof(*skb))这种粗暴方式来复制必须通过 API 走。4.3 回收机制kfree_skb、引用计数和 skb poolSKB 的释放路径主要分两种。正常释放走kfree_skb它会先调用skb_release_head_state处理协议栈头状态比如 socket 引用、skb_release_data释放数据区处理 frags 页引用最后kfree_skbmem把 sk_buff 结构体还给 slab。异步环境下如果调用kfree_skb不合适比如在硬中断里通常会置skb-destructor延迟到软中断处理。skb-users这个字段是引用计数。注意skb_clone时新老的 SKB 都是独立的struct sk_buff它们各自的 users 各自管理数据区共享的部分由skb_shared_info里的dataref管理。只有这两者都归零了整个包才算真正释放。做高性能转发时还有一个思路叫skb pool复用。你可以自己在驱动里维护一个sk_buff的缓存队列收包时如果 pool 里有现成的 SKB 就直接复用减少反复分配释放的开销。DPDK 有内存池内核里的page_frag_cache也类似。如果你在做嵌入式网卡驱动这招对提高小包吞吐效果很直接但要注意 pool 的 free 和 alloc 要配成同一组锁不然在 SMP 环境下毛刺很明显。5. 实操中的调试技巧与性能优化5.1 怎么观察 SKB 的内容与状态先从最基础的说起ss -n -m能看 socket 内存统计netstat -s能看协议层各种丢包计数/proc/net/softnet_stat能看到 softnet 的 dropped 和 time_squeeze。如果你的目标是深入到具体一个 SKB则有几条路线用tracepoint挂到skb:kfree_skb或skb:consume_skb能看到释放位置和原因。利用perf trace或bpftrace都很容易做。用tc的bpf程序在 qdisc 入口挂一个 BPF把struct __sk_buff的关键字段len、mark、protocol打印出来。这是最实用的动态观测手段。如果在内核模块里调试可以直接dump_skb类似的函数或者用printk%px打印指针。不过%px在较新内核会打码需要 KASLR 关闭或开启kptr_restrict0才方便。另外推荐一个小工具skbedit和skbmodtc 子命令它们可以设置 mark、改变 priority、修改 MAC 头用来制造测试特异性很好的场景。比如你用skbedit set mark 10给特定流打上标记再用tc filter按 mark 做分流这在验证 TC offload 或自定义 qdisc 时很常用。还有个大招是编译带CONFIG_DEBUG_LIST、CONFIG_SKB_DEBUG部分内核分支有和 KASAN 的内核配合panic_on_warn来捕获 SKB 区域的 use-after-free。我自己的经验是如果你是在做驱动或者协议修改强烈建议本地有一台跑这种“慢内核”的测试机器宁可牺牲性能也要先把内存问题暴露出来。5.2 常见问题排查丢包、内存泄漏和数据错位我先把实战中最高频的几类问题列出来并用表格对比可能的方向。问题现象常见原因排查建议网卡 RX 报 dropped 暴涨驱动 ring buffer 满、NAPI 处理太慢看ethtool -S的rx_ring_full加大 ring或 /proc/net/softnet_stat 的 dropped 列socket 接收队列丢包应用处理慢导致队列满看ss -nmp的 rcvbuf 和 rcvq考虑调大 rmemSKB 内存泄漏skb_clone/skb_get 后没配对释放netfilter 里 ACK 路径异常用 slabtop 观察skbuff_head_cache增长bpftrace 挂 kfree_skb 看调用栈改包后校验错误修改了 payload 但没更新 checksum 相关字段检查 skb-ip_summed、CHECKSUM_PARTIAL 状态必要时关闭硬件校验和数据错位导致协议解析失败头指针操作顺序错乱headroom 不够导致越界打开 KASAN检查skb_reserve(skb, reserve)的值是否覆盖 VLAN 头等额外空间丢包率的排查一般从ethtool -S eth0开始确认硬件的 rx_dropped、rx_missed 这些计数是不是在涨。如果计数涨说明包已经到了网卡但驱动没及时取走多半是 NAPI 的 poll 权重和中断节流配置的问题。如果硬件计数基本不动但/proc/net/softnet_stat的第三列在涨说明包进入了协议栈但在 backlog 里没来得及处理。这时候常见原因是某个协议钩子太慢或者是 CPU 软中断不均衡导致单个 CPU 被打满。内存泄漏方面我分享一个印象深刻的项目经验。某个定制内核模块里只要开启 NATslab 里的 skbuff_head_cache 就会持续涨1 小时能涨出上百 MB。最后搭配 bpftrace 去挂kfree_skb和skb_clone统计出是 conntrack 模块里对 clone 出来的 SKB 没有及时释放也就是说每当一个连接有多个方向流量时引用计数就多了一。改掉这个 bug 后slab 水位立刻平稳。排查这种问题核心在于先统计分配和释放数量反推引用计数不平衡的位置。5.3 性能优化从 clone 到零拷贝的思路先厘清一点SKB 的 clone 本身不是为了性能优化而是为了功能复用。但在很多性能优化场景中减少不必要的 copy 是核心目标。sendfile、splice系统调用之所以能提高吞吐就是因为 SKB 可以直接引用用户页或页缓存的 page通过skb_fill_page_desc把数据挂进 frags而不是把数据搬进内核线性区再搬出去。这就是 Linux 零拷贝最内核级的实现路径。如果你的业务里数据包进入用户态后还需要转发出网卡比如自研的代理网关可以考虑用TPACKET_V3这种 AF_PACKET 模式利用 mmap 的 ring buffer 实现抓包零拷贝。不过它拿到的是 pcap 格式的数据还是需要解析和重组。要极致的性能现阶段主流的方案还是 DPDK 或 AF_XDP。AF_XDP 的好处是它能复用内核的 XDP 框架并在用户态直接操作 UMEM本质上就是让你自己管理页引用而内核层面的 SKB 被旁路了所以性能模型完全不同。需要提醒的是零拷贝并非在所有场景都能涨性能。如果包很小比如 64 字节小包频繁的页引用和 frag 拆分开销并不比线性拷贝小多少。如果包很大比如 1MB 的 TCP 流量零拷贝优势才明显。我自己的经验是先做 profile 再决定优化路径不要在没数据支撑的情况下盲目上 DPDK 或者 AF_XDP。从内核调度角度看如果 SKB 一直跨 CPU 传递会造成 cacheline 乒乓。通过 RPS/RFS 和irqbalance做好 CPU 亲和性通常收益很大。如果你在写驱动或做网卡多队列更要注意 skb 的分配最好与当前 CPU 绑定用napi_alloc_skb或用build_skb复用页的本地缓存别每次调用全局 kmalloc否则在大量小包场景下锁竞争会被直接拉满。6. 几个容易踩但又很少被记录的细节6.1 不要迷信 headroom 永远够用很多模块在处理 VLAN 或者隧道协议时习惯性地往 SKB 头部塞东西你可能会直接skb_push一个struct vlan_hdr大小的空间但没检查 headroom。如果 headroom 不够这种 push 会把 data 推到 head 前面直接踩到别的内存。正确做法是先检查skb_headroom不够就调用skb_cow_head或skb_realloc_headroom让内核重新分配一个有足够头空间的 SKB。6.2 小心硬件 offload 状态影响你的改包逻辑驱动和协议栈之间通过skb-ip_summed字段传递校验和状态。CHECKSUM_PARTIAL表示硬件会计算校验和但你要保证一部分字段比如 IP 头、伪头是正确填好的。如果你在 netfilter 里改了端口号却没调用inet_proto_csum_replace之类的 helper硬件会基于旧的伪头计算校验和导致 TCP 层校验失败被接收端丢包。这种问题不仔细抓包很难发现因为看起来包是正常发出的。6.3 调试时优先用 tracepoint 而不是乱加 printk在内核里加 printk 看 SKB 信息虽然直观但生产环境里意义不大。我更推荐先挂 tracepoint比如skb:consume_skb、skb:kfree_skb、net:netif_receive_skb、net:dev_queue_xmit或者用bpftrace写脚本直接打印函数参数里的struct sk_buff *并读取字段。这样不影响线上服务又能把关键路径抓出来。如果看函数调用栈更清晰可以用perf record -g -e skb:kfree_skb得到完整的内核栈然后直接定位是谁调用了释放函数、为什么释放路径反射出引用计数异常。这个方法帮我解决了好几次莫名其妙的内存泄漏问题比瞎猜快得多。6.4 SKB 与嵌入式 Linux 开发嵌入式 Linux 里做网卡驱动如果你有 DMA 操作头部的NET_SKB_PAD和NET_IP_ALIGN这两个宏一定不要忽略。NET_SKB_PAD 一般 64 字节用于容纳足够大的平台对齐和填充NET_IP_ALIGN 一般 0 或 2用来保证 IP 头四字节对齐。很多嵌入式 SoC 的 DMA 引擎要求源地址按 4 字节或 8 字节对齐如果驱动在alloc_skb后直接调用skb_reserve(skb, NET_SKB_PAD NET_IP_ALIGN)能避免不少机器依赖问题。还有一点嵌入式板卡经常有功耗限制驱动可以结合 NAPI 的budget和weight调节中断频率。但不要为了省电把 budget 设得太小否则中断风暴来了反而更费电。需要找 release、demo、测试板逐档试不能只凭感觉。7. 写在最后的实战感悟内核网络这块我前前后后摸了好几年踩过最大的坑基本都是和 SKB 生命周期相关的。曾经有个高速转发模块上线后只要吞吐一高就丢包查了很久才发现是驱动收回包后没有做skb_put导致 IP/TCP 层看到的 len 不对偶尔又因为 headroom 不足skb_push越界把相邻内存给改坏了。这类问题一旦进入数据竞争状态非常考验人后来还是靠 KASAN tracepoint 组合定位到的。所以我自己有个执念任何接触网络内核开发的人都应该把struct sk_buff的源码从头到尾读一遍再去看几个主流驱动的收发实现。不要一上来就调 XDP、调零拷贝基础不牢靠后面全都是在猜。也可以写一个小的内核模块用dev_alloc_skb自己组装一个包然后逆序执行skb_reserve、skb_put、skb_push、skb_pull把四个指针的变化印在日志里跑一遍比看十篇文章都管用。这篇文章基本把 SKB 的结构、操作、收发路径和调试方法都覆盖了。接下来的突破口建议放在 driver 层和 qdisc 层自己的代码上找一个软中断频繁的小包场景用perf top看热点落在哪再对照 SKB 的分配、克隆、释放路径去分析。你会发现真正影响性能的往往不是某个宏大的算法而是这些看起来不起眼的细节。