2、Linux网络协议栈：Socket缓冲区、sk_buff结构体、网络设备层接口

说实话，很多搞Linux网络编程的朋友，写应用层代码溜得很，但一问到内核里数据怎么流转，就卡壳了。我个人觉得，要真正理解Linux网络模型，必须把协议栈的这几个核心组件啃透：Socket缓冲区、sk_buff结构体，还有网络设备层接口。它们就像网络数据的"高速公路"、"集装箱"和"收费站"。

今天我们就来拆开看看，数据包在内核里到底经历了什么。

2.1 Socket缓冲区：用户态与内核态的"中转站"

你想想看，应用程序调用 send() 或 recv() 时，数据并不是直接扔给网卡的。中间隔着一道墙——用户态和内核态。Socket缓冲区就是墙上的那个窗口。

每个Socket创建时，内核都会给它分配两个缓冲区：

发送缓冲区（write buffer）：应用程序要发出去的数据，先拷贝到这里。
接收缓冲区（read buffer）：从网络来的数据，内核先放到这里，等应用程序来取。

我在项目中遇到过一个问题：一个高并发的Web服务器，偶尔会出现客户端请求超时。查了半天，发现是Socket的接收缓冲区太小，内核频繁丢包。后来调大了 tcp_rmem 参数，问题就解决了。嗯，这里要注意，缓冲区大小不是越大越好，太大反而会浪费内存，增加延迟。

核心要点：Socket缓冲区是用户态和内核态数据交换的桥梁。它的大小直接影响网络吞吐量和延迟。

2.2 sk_buff结构体：网络数据的"瑞士军刀"

如果说Socket缓冲区是仓库，那 sk_buff 就是仓库里的标准集装箱。它是Linux网络协议栈中最核心的数据结构，没有之一。

一个数据包从网卡驱动到应用层，或者反过来，全程都待在这个结构体里。它长什么样？我贴一段简化后的定义：

struct sk_buff {
    /* 链表管理 */
    struct sk_buff      *next;
    struct sk_buff      *prev;
    struct sk_buff_head *list;

    /* 网络层信息 */
    struct sock         *sk;          /* 归属的Socket */
    struct net_device   *dev;         /* 网络设备 */

    /* 数据指针 */
    unsigned char       *head;        /* 数据区起始 */
    unsigned char       *data;        /* 当前协议数据起始 */
    unsigned char       *tail;        /* 当前协议数据结束 */
    unsigned char       *end;         /* 数据区结束 */

    /* 长度信息 */
    unsigned int        len;          /* 实际数据长度 */
    unsigned int        truesize;     /* 总分配大小 */

    /* 协议标识 */
    __be16              protocol;     /* 上层协议类型 */
    ...
};

你看，它用四个指针（head、data、tail、end）来管理数据区。为什么这么设计？说白了，是为了让各协议层能方便地添加或剥离头部。比如TCP层要加TCP头，IP层要加IP头，以太网层要加MAC头。通过移动 data 指针，就能做到零拷贝。

我记得刚接触内核网络代码时，看到 skb_push()、skb_put()、skb_pull()、skb_reserve() 这几个函数，完全搞不清谁是谁。后来画了个图才明白：

避坑指南：我曾经在写内核模块时，直接修改了 skb->data 指针，结果导致内核崩溃。记住，永远不要直接操作指针，要用 skb_push、skb_pull 这些封装好的函数。它们会帮你维护 len 等字段的一致性。

2.3 网络设备层接口：数据进出的"大门"

数据在协议栈里处理完了，最终要交给网卡发出去。或者网卡收到数据，要交给协议栈处理。这个交接点，就是网络设备层接口。

每个网络设备（物理网卡、虚拟网卡、网桥等）在内核里都对应一个 net_device 结构体。它包含了设备的所有信息：名字、MAC地址、MTU、操作函数集等。

关键的操作函数集定义如下：

struct net_device_ops {
    int (*ndo_open)(struct net_device *dev);        /* 启动设备 */
    int (*ndo_stop)(struct net_device *dev);        /* 停止设备 */
    netdev_tx_t (*ndo_start_xmit)(struct sk_buff *skb, struct net_device *dev); /* 发送数据 */
    int (*ndo_do_ioctl)(struct net_device *dev, struct ifreq *ifr, int cmd);    /* 控制命令 */
    ...
};

数据发送的流程大致是这样的：

应用层调用 send()，数据进入Socket缓冲区。
TCP/UDP层处理，添加传输层头，生成 sk_buff。
IP层处理，添加IP头，查找路由。
邻居子系统（ARP）解析MAC地址。
调用 dev_queue_xmit()，将 sk_buff 放入设备的发送队列。
网卡驱动通过 ndo_start_xmit 从队列取出 sk_buff，真正发送出去。

接收流程反过来：

网卡收到数据，通过DMA写入内存。
网卡触发中断，驱动在中断处理函数中调用 netif_rx() 或 napi_schedule()。
数据进入软中断（NET_RX_SOFTIRQ），协议栈逐层处理。
最终数据放入Socket接收缓冲区，唤醒等待的应用程序。

注意：在发送路径上，ndo_start_xmit 返回 NETDEV_TX_OK 表示发送成功，返回 NETDEV_TX_BUSY 表示设备忙，需要重试。如果驱动实现不当，返回 BUSY 会导致协议栈反复重试，消耗大量CPU。我曾经调试过一个性能问题，就是驱动在流量高峰时频繁返回 BUSY，导致CPU软中断占用飙到90%。

2.4 三者如何协同工作？

我们用一个完整的发送流程，把这三个组件串起来：

步骤	组件	操作
1	Socket缓冲区	应用程序调用 `send()`，数据从用户态拷贝到内核态Socket发送缓冲区
2	sk_buff	TCP层从Socket缓冲区取出数据，创建 `sk_buff`，通过 `skb_reserve` 预留头部空间
3	sk_buff	TCP层调用 `skb_push` 添加TCP头，IP层调用 `skb_push` 添加IP头
4	网络设备层	IP层通过路由找到出口设备，调用 `dev_queue_xmit()` 将 `sk_buff` 送入设备发送队列
5	网络设备层	网卡驱动调用 `ndo_start_xmit`，从队列取出 `sk_buff`，通过DMA发送
6	sk_buff	发送完成后，驱动释放 `sk_buff`，或者将其回收复用

你看，整个流程环环相扣。Socket缓冲区是数据的源头和归宿，sk_buff是数据在内核中的载体，网络设备层是数据进出内核的关口。理解了这个链条，你再看任何网络问题，都能快速定位到是哪个环节出了岔子。

总结一下：

Socket缓冲区：用户态和内核态的数据中转站，大小可调，影响性能。
sk_buff：网络数据的标准容器，通过指针操作实现零拷贝协议头处理。
网络设备层接口：数据进出内核的网关，通过 net_device_ops 函数集与驱动交互。

嗯，这一节的内容就到这里。记住，纸上得来终觉浅，建议你找个空闲时间，用 perf 或者 bpftrace 实际跟踪一下数据包的流向，感受会更深刻。

📚 课程目录

2、Linux网络协议栈：Socket缓冲区、sk_buff结构体、网络设备层接口

2.1 Socket缓冲区：用户态与内核态的"中转站"

2.2 sk_buff结构体：网络数据的"瑞士军刀"

2.3 网络设备层接口：数据进出的"大门"

2.4 三者如何协同工作？