sk_buff封装

2023-03-24  本文已影响0人  程序员札记

sk_buff结构体是Linux网络协议栈的核心中的核心，几乎所有的操作都是围绕sk_buff这个结构体进行的，它的重要性和BSD的mbuf类似(看过《 TCP/IP详解 卷2》的都知道)，sk_buff就是网络数据包本身以及针对它的操作元数据。
sk_buffer简称skb，sk_buffer是Linux网络模块中的核心结构体各个层用到的数据包都存在这个结构体里。 skb内部其实包含了网络协议中所有的 header。比如在设置 TCP HEADER的时候，只是把指针指向 sk_buffer的合适位置。后面再设置 IP HEADER的时候，在把指针移动一下就行，避免频繁的内存申请和拷贝，效率很高。

image.png

网络分层模型

这是一切的本质。网络被设计成分层的，所以网络的操作就可以称作一个“栈”，这就是网络协议栈的名称的由来。在具体的操作上，数据包最终形成的过程就是一层一层封装的过程，在栈上形成一段连续的数据，我们可以称作是一层一层的push操作。同样的，数据包的解封装的过程，则可以认为是一层一层的pop操作。

sk_buff的操作.

要想形成一个最终的数据包，即以太帧(不考虑其它的链路层)。要进行以下的操作：

  1. 分配一个skb结构体
  2. 分配数据包的数据区
  3. 在skb数据区定位应用层起始位置
  4. 拷贝数据到应用层(假设应用层协议没有在socket接口之上被封装)
  5. 在skb数据区定位传输层起始位置
  6. 设置传输层头部字段
  7. 在skb数据区定位IP层起始位置
  8. 设置IP层头部字段
  9. 在skb数据区定位以太层起始位置
  10. 设置以太头部字段

可以看出基本的模式，即“定位/设置”两步骤操作，有点区别的是应用层操作，这是因为应用层的操作一般都是在socket接口之上完成的。但是既然本文讲述的是skb的通用操作，就不再区分这个了。

skb的核心操作

在上面一小节，我们展示了skb的封装逻辑，但是具体到接口层面，就涉及到了skb的核心操作。

  1. 分配skb
    这个是由alloc_skb完成的，完成同一任务的接口形成一个接口族，但是alloc_skb是最基本的接口。该alloc_skb接口完成两件事，即分配skb结构体以及skb数据包缓冲区，设置初始值。size参数表示skb的数据包缓冲区的大小，这个大小包括所有层的总和。如果该函数成功返回，那么就相当于你已经有了一个大小为size的空数据包缓冲区以及操作该数据包缓冲区的skb元数据。如下图所示：


    image.png

  1. 初始定位(skb_reserve)
    skb的逐层封装的关键在于写指针的定位，即这一层从哪个位置开始写。从协议封装的压栈形象来看，这个定位应该是顺序有规律的。初始定位十分重要，后面的定位就是例行公事了。初始定位当然是定位到应用层的末端，从这里开始，逐层将协议头push到skb的数据包缓冲区。初始定位图示如下：


    image.png
  1. 拷贝应用层数据(skb_push/copy)
    当skb分配好了之后，需要将协议“栈”的位置定位在数据包的“最低处”，这是初始定位，这样才可以把每一层的数据或者协议头push到栈上，这个操作由skb_reserve来完成。应用层数据已经在socket之上封装好了，那么就把skb的数据包缓冲区写指针定位到应用数据的开始处，此时的写指针在应用层缓冲区的末尾，因此需要使用skb_push操作将写指针定位到应用层开始处，这等于说压入了应用层栈帧。
    skb_push接口是将一个协议栈帧压入协议栈的接口，它返回一个position，该position就是skb数据包的写指针，告诉调用者，这里开始按照你的封装逻辑封装数据包，写多少字节呢？由skb_push的参数n指示。应用层的压栈操作如下图所示：
image.png

将应用层栈帧压入协议栈之后，就可以在写指针位置开始，往后连续写n字节的应用层数据了，一般而言，这些数据来自socket。

  1. 设置传输层头部
    和应用层的操作类似，这次需要把传输层栈帧压入协议栈中，如下图所示：
image.png

接下来就可以愉快地在skb_push返回的位置设置传输层头部了，UDP，TCP，就看你对传输层的理解了。设置传输层头部其实就是在skb_push返回的位置开始写数据，写入的长度由skb_push的参数指定，即n。

  1. 设置IP层头部
    和应用层以及传输层操作类似，这次需要把IP层的栈帧压入协议栈中，如下图所示：
image.png

接下来就可以愉快地在skb_push返回的位置设置IP层头部了，如何设置，就看你对IP层的理解了。由于只是演示skb如何封装，因此没有涉及IP层相当重要的IP路由过程。

  1. 设置以太帧头部
    这个就不说了，和上述的类似...如下图所示：
image.png

到此为止，我封装了一个完整的以太帧，可以直接通过dev_queue_xmit发送的那种。一路下来，你会发现，skb数据包缓冲区以“压栈(push)”的方式逐渐被填充，每一层，都是通过skb_push接口压入一个栈帧，返回写指针，然后按照该层的协议逻辑从写指针开始写入栈帧长度的数据。
在skb_push返回的那一刻，一个栈帧被压入了协议栈，然后该栈帧还仍未被写入数据，也就是说还没有完成封装过程，具体的封装过程由调用者自己实现。
skb_push导致了skb数据包缓冲区写指针位置的前推，连带的改变了好几个变量，首先数据包的长度增加了n个字节，其次缩小了headroom的空间，然后通过reset_XXX_header的调用，skb记住了某层协议头在数据包中的位置(这点特别重要！比如在TSO/UFO的情况下，网卡驱动需要协议头的位置信息，用以计算校验值，所以虽然skb不记住协议头的位置，一个数据包也能完成封装，但是对于协议栈的完整实现而言，却是不正确的做法，毕竟网卡计算校验码已经成了一种事实上的标准[即便它违背了严格的分层原则！])

  1. 在应用数据后面追加PADDING
    目前为止，从最后的图示上可以看到，在skb数据包缓冲区中，还有两块区域没有使用，一个headroom，一个是tailroom，这些是干什么用的呢？作为一个练习的例子，由于存在某种对齐原则，在封装完成后，我需要在数据包的最后追加一些填充，或者说我需要在最前面加一个前导码，或者最常见的，我要在数据包的最后加一个纠错码，此时应该怎么办呢？
    这个时候就需要headroom或者tailroom了，以在数据包最后追加数据为例，请看下图：
image.png

实际上，skb_put的操作就是，在数据包的末尾追加数据。至于说headroom如何使用，我就不多说了，其实还是skb_push，headroom有什么用呢？前导码，X over Y封装，不一而足。

实际的例子
下面我给出一个实际的例子，封装一个以太帧，然后发送出去：

    skb = alloc_skb(1500, GFP_ATOMIC);
    skb->dev = dev;
    // 例行填充skb元数据

    /* 保留skb区域 */
    skb_reserve (skb, 2 + sizeof(struct ethhdr) +
            sizeof(struct iphdr) +
            sizeof(struct udphdr) +
            sizeof(app_data));

    /* 构造数据区 */
    p = skb_push(skb, sizeof(app_data));
    memcpy(p, &app_data[0], sizeof(app_data));

    p = skb_push(skb, sizeof(struct udphdr));
    udphdr = (struct udphdr *)p;  
    // 填充udphdr字段，略
    skb_reset_transport_header(skb);

    /* 构造IP头 */
    p = skb_push(skb, sizeof(struct iphdr));
    iphdr = (struct iphdr*)p;
    // 填充iphdr字段，略
    skb_reset_network_header(skb);

    /* 构造以太头 */
    p = skb_push(skb, sizeof(struct ethhdr));
    ethhdr = (struct ethhdr*)p;
    // 填充ethhdr字段，略
    skb_reset_mac_header(skb);

    /* 发射 */
    dev_queue_xmit(skb);

解封装的过程和封装的过程相反，解封装的过程是协议栈栈帧逐层pop的过程，但是Linux协议栈并没有用栈的术语来定义接口名字，而是使用了push的反义词，即pull来定义的，skb_pull就是核心接口，和skb_push严格相对。我就不再一一画图了。

按照接口编码而不是按照实现编码

这好像是Effective C++里面的一条，同样也适合于skb的操作场景。典型的就是“如何让skb记住IP层协议头，传输层协议头，mac头的位置”，接口是：

skb_reset_mac_header
skb_reset_network_header
skb_reset_transport_header
调用时机为skb_push返回的当时。曾几何时，我按照下面的方式设置了协议头的位置：
    /* 构造IP头 */
    p = skb_push(skb, sizeof(struct iphdr));
    iphdr = (struct iphdr*)p;
    // 填充iphdr字段，略
    //skb_reset_network_header(skb);
    skb->network_header = p;

有错吗？咋一看是没错的，但是却报错了：
protocol 0008 is buggy, dev eth2
这是怎么回事？原因就在于skb纪录的协议头位置是错误的！难道以上的设置skb的network_header字段的方式有何不妥吗？当然不妥！这就是没有按照接口编码的恶果。
原因在于，系统设置skb的network_header字段的方式有两种，通过一个宏来识别：NET_SKBUFF_DATA_USES_OFFSET。也就是说，可以通过相对于skb的head指针的偏移来定位协议头的位置，也可以通过绝对地址来定位，具体使用哪一种取决于系统有没有定义NET_SKBUFF_DATA_USES_OFFSET宏，以上的skb->network_header = p明显是通过绝对地址来定位的，一旦系统定义了NET_SKBUFF_DATA_USES_OFFSET宏，肯定就不对了。既然宏定义在编译期确定，那么通过定义接口就可以在编译期唯一确定一种实现，程序员不必在乎是否定义了NET_SKBUFF_DATA_USES_OFFSET宏，这就是通过接口编程的益处。如果基于skb的实现来编程，你不得不针对所有的情况编写好几套实现，而以上错误的实现只是其中一种，而且还用错了场景！这是多么痛的领悟！
NET_SKBUFF_DATA_USES_OFFSET宏是一个细节问题，如果使用接口编程便不必关注这个细节，否则你就必须搞清楚系统为何这么设计，即便这并不是你所关注的！为何呢？
由于指针的长度大小在32位系统和64位系统中是不一样的，所以按理说skb中的指针型的元数据大小也会不同，且64位系统的将会是32位系统的两倍，为了平滑掉这个差别，使元数据大小一致，就必须让64位系统的对应指针类型变为4个字节，而这是不可能的。因此在64位系统中，使用偏移来定位元数据，而偏移的类型为固定不变的unsigned int，即4个字节。为了支持上述说法，skb中加入了一个新的层次，即定义了一种新的数据类型sk_buff_data_t，该类型在编译期确定：

#if BITS_PER_LONG > 32
#define NET_SKBUFF_DATA_USES_OFFSET 1
#endif

#ifdef NET_SKBUFF_DATA_USES_OFFSET
typedef unsigned int sk_buff_data_t;
#else
typedef unsigned char *sk_buff_data_t;
#endif
节约空间之外，对于和大小相关的操作，接口实现也更加统一。这就是细节，而这些细节并不是玩网络协议栈的人所要关注的，不是吗？这完全是系统实现的层面，和业务逻辑是无关的

内核发送网络包流程

RingBuffer结构详解

关于RingBuffer网上有很多说法，有的人说RingBuffer是系统启动时就预先申请好的一个环形数组，有的人说RingBuffer是在接收或发送数据时才动态申请的一个环形数组，那么到底RingBuffer的结构是怎么样的呢？由下图可以看到

传统的数据发送与接收内存拷贝

  1. 首先由DMA先将要发送的数据从磁盘拷贝到操作系统的page cache中
  2. 然后由CPU将page cache中的数据拷贝到用户内存中
  3. 然后再由CPU将数据从用户内存中拷贝到socket缓冲区
  4. 然后再从socket发送缓冲区中拷贝出数据，然后申请一个skb，将数据挂在这个skb上
    A. skb的全称叫做sk_buff，sk_buff缓冲区，是一个维护网络帧结构的双向链表，链表中的每一个元素都是一个网络帧。虽然 TCP/IP 协议栈分了好几层，但上下不同层之间的传递，实际上只需要操作这个数据结构中的指针，而无需进行数据复制。
    B. 这里是经过协议栈时做的操作，skb构建完成后就会将这个skb传递给传输层，网络层，直到最后的网卡队列的RingBuffer里都是在对这个skb进行操作
  5. 最后由DMA将数据（skb）从RingBuffer中取出送到网卡进行发送
    可以看到这里第2步和第3步的拷贝明显有点多余了，能不能省掉呢？能，sendfile就是这么干的。
image.png

sendfile内存拷贝

  1. 首先由DMA先将要发送的数据从磁盘拷贝到操作系统的page cache中
  2. 然后由CPU将page cache中的数据直接拷贝到socket发送缓冲区（这里数据不会到达用户内存了）
  3. 然后再从socket发送缓冲区中拷贝出数据，然后申请一个skb，将数据挂在这个skb上
    这里是经过协议栈时做的操作，skb构建完成后就会将这个skb传递给传输层，网络层，直到最后的网卡队列的RingBuffer里都是在对这个skb进行操作
  4. 最后由DMA将数据（skb）从RingBuffer中取出送到网卡进行发送
image.png

内核发送网络包简单流程

先上一个发送网络包的简单流程，以便于理解内核发送网络包的整体脉络！！！

  1. 内核发送数据流程详解
    以一个极简的伪代码表示我们在日常开发中如何发送数据包的，以便于理解内核发送数据包的整个流程
int main(){
  // 创建一个socket对象，返回内核中socket的文件描述符（也就是内核socket对象的句柄）
    fd = socket(fd,...);
    // 该socket绑定IP和端口
  bing(fd,....);
  // socket监听端口
  listen(fd,....);
  
  // 等待客户端连接,用户连接后会在内核中创建代表该客户端的socket对象并且返回该socket的文件描述符cfd
  cfd = accept(fd,...);
  
  // 客户端连接后，处理用户请求
  dosomething();
  
  // 向客户端发送数据, cfd表示该客户端的socket对象的文件描述符，buf表示要发送的数据
  // 【内核发送数据包流程就体现在这里】
  send(cfd, buf, sizeof(buf), 0);
}

如果是用Java里的NIO来编写的话，大致代码流程如下：

public static void main() throws Exception {
        // 创建服务端的socketchannel
        ServerSocketChannel ssc = ServerSocketChannel.open();
        // 设置这个ServerSocketChannel为阻塞(当有客户端连接请求并且和客户端建立连接成功后，下面的accept才继续向下执行)
        ssc.configureBlocking(true);

        // 阻塞接收客户端连接，客户端连接成功后会返回sc
        SocketChannel sc = ssc.accept();
        // 设置该客户端为阻塞的，方便演示
        sc.configureBlocking(true);

        // 申请一个byteBuffer
        ByteBuffer buffer = ByteBuffer.allocate(16);
        // 填充要发送的数据到byteBuffer中
        buffer.put("hello world.".getBytes());
        // 向该客户端发送数据，此时的发送过程就由内核来处理了
        int write = sc.write(buffer);
    }
image.png

性能开销分析

所以，在网络数据发送流程中，一共发送了【一次上下文太态的切换】，两次数据拷贝（一次用户空间到内核空间，一次内核空间到内核空间的拷贝），如果skb大于MTU的话还有数据切分开销，两次硬中断和两次软中断开销

三、跨机网络通信总流程

image.png
上一篇下一篇

猜你喜欢

热点阅读