2. 内核缓冲区机制：Socket 缓冲区与 sk_buff 结构体

聊到 Socket 缓冲区，很多人的第一反应就是那个 rmem_default 和 wmem_default 参数。但说实话，那只是冰山一角。真正决定网络性能的，是内核里那套缓冲区管理机制——尤其是 sk_buff 这个核心结构体。

我刚开始调优网络时，也以为改大缓冲区就能解决问题。结果有一次线上服务延迟飙升，查了半天才发现是缓冲区过大导致内存碎片，反而拖慢了分配速度。嗯，从那以后我就老老实实把 sk_buff 的整个生命周期摸了一遍。

2.1 为什么需要内核缓冲区？

你想想看，应用层和网卡之间，速度完全不匹配。网卡收包是微秒级的，应用处理可能要到毫秒级。没有缓冲区，包就会丢得一塌糊涂。

内核缓冲区的作用说白了就三点：

解耦：让应用层和硬件层各自忙各自的，不用互相等
平滑：应对网络流量的突发，避免瞬间丢包
重组：把乱序的、分片的包重新拼好再交给应用

核心观点：内核缓冲区不是越大越好。我见过有人把缓冲区设到 16MB，结果内存压力剧增，吞吐量反而下降。合适的才是最好的。

2.2 sk_buff 结构体——网络子系统的"万能容器"

在 Linux 内核里，每一个网络包都装在一个 sk_buff 里。你可以把它理解成一个快递箱——箱子本身有标签（元数据），里面装着货物（实际数据）。

这个结构体有多大？我印象中在 5.x 内核里，它大概占 200 多字节。别小看这 200 字节，在高并发场景下，每个包都要分配一个 sk_buff，内存开销相当可观。

// 简化后的 sk_buff 核心字段（Linux 5.10）
struct sk_buff {
    // 链表指针
    struct sk_buff      *next;
    struct sk_buff      *prev;
    
    // 所属 socket
    struct sock         *sk;
    
    // 时间戳
    __u32               tstamp;
    
    // 数据指针
    char                *head;      // 缓冲区起始
    char                *data;      // 数据起始
    char                *tail;      // 数据结束
    char                *end;       // 缓冲区结束
    
    // 长度信息
    unsigned int        len;        // 实际数据长度
    unsigned int        truesize;   // 总内存占用（含 sk_buff 本身）
    
    // 协议信息
    __be16              protocol;   // 上层协议类型
    unsigned short      mac_header; // MAC 头偏移
    unsigned short      network_header; // 网络头偏移
    unsigned short      transport_header; // 传输头偏移
    
    // 标志位
    __u32               pkt_type;   // 包类型（单播/多播/广播）
};

这里我特别想强调 truesize 这个字段。很多人在计算内存占用时只算了 len，但实际上 truesize 才是真正占用的内存。它包括了 sk_buff 结构体本身、数据区、以及可能的协议头预留空间。我曾经踩过一个坑：应用层统计内存只算了数据长度，结果实际内存占用是预期的两倍多。

2.3 缓冲区与协议栈的协作关系

数据包从网卡到应用层，要经过好几层协议栈。每一层都在操作 sk_buff 里的指针，而不是复制数据。这就是所谓的"零拷贝"思想——至少在内核内部是这样。

小技巧：你可以通过 cat /proc/net/sockstat 查看当前系统的 socket 内存使用情况。重点关注 mem 字段，它表示已分配的页面数（单位是页）。

来看一个典型的收包流程：

网卡驱动：从 Ring Buffer 拿到数据，分配 sk_buff，填充数据
链路层：设置 mac_header，校验 FCS
网络层：设置 network_header，处理 IP 头，路由查找
传输层：设置 transport_header，处理 TCP/UDP 头
Socket 层：将 sk_buff 放入接收队列，唤醒应用

每一层都只移动指针，不复制数据。这也是为什么 sk_buff 里要存那么多偏移量——它们就是各层协议的"书签"。

2.4 缓冲区大小与内存管理

每个 socket 都有两个核心队列：接收队列和发送队列。队列里的每个 sk_buff 都占用内存，内核必须控制总量，否则系统内存会被网络包吃光。

内核通过三个层级来管理：

层级	控制参数	作用范围	我常用的值
系统级	`net.core.rmem_max` `net.core.wmem_max`	所有 socket 的上限	2MB ～ 8MB
协议级	`net.ipv4.tcp_rmem` `net.ipv4.tcp_wmem`	TCP socket 的默认/最小/最大	"4096 131072 6291456"
应用级	`setsockopt(SO_RCVBUF)` `setsockopt(SO_SNDBUF)`	单个 socket	按业务需求调整

注意：应用层通过 setsockopt 设置的值会被内核翻倍。比如你设了 100KB，内核实际分配 200KB（多出来的用于 sk_buff 结构体开销）。我曾经在文档里没写清楚，结果测试团队发现实际内存和配置对不上，排查了半天。

2.5 避坑指南：我踩过的三个坑

这些年调优 socket 缓冲区，我总结了几条血泪教训：

坑一：盲目增大缓冲区。我曾经把 tcp_rmem 的最大值设到 32MB，结果高并发下内存直接爆了。后来发现，每个连接都按最大值预分配，10000 个连接就是 320GB——服务器才 128GB 内存。
坑二：忽略 truesize。应用层统计内存时只看 len，但内核实际占用是 truesize。一个 1500 字节的包，truesize 可能到 2000+ 字节。差距不小。
坑三：不区分接收和发送。接收缓冲区不足会导致丢包，发送缓冲区不足只会阻塞写入。两者的调优策略完全不同。我见过有人把发送缓冲区调得巨大，接收缓冲区却用默认值——结果收包丢得一塌糊涂。

2.6 小结

sk_buff 是 Linux 网络子系统的基石。理解它的结构、指针操作方式、以及在各协议层的流转，是调优 socket 缓冲区的前提。记住三个核心点：

缓冲区不是越大越好，要匹配业务模型
truesize 才是真实内存占用
接收和发送要分开调优

📚 课程目录

2. 内核缓冲区机制：Socket 缓冲区与 sk_buff 结构体

2.1 为什么需要内核缓冲区？

2.2 sk_buff 结构体——网络子系统的"万能容器"

2.3 缓冲区与协议栈的协作关系

2.4 缓冲区大小与内存管理

2.5 避坑指南：我踩过的三个坑

2.6 小结