Linux内核中sk_buff结构详解

sk_buff是Linux网络中最核心的结构体，它用来管理和控制接收或发送数据包的信息。各层协议都依赖于sk_buff而存在。内核中sk_buff结构体在各层协议之间传输不是用拷贝sk_buff结构体，而是通过增加协议头和移动指针来 *** 作的。如果是从L4传输到L2，则是通过往sk_buff结构体中增加该层协议头来 *** 作；如果是从L4到L2，则是通过移动sk_buff结构体中的data指针来实现，不会删除各层协议头。这样做是为了提高CPU的工作效率。

skb_buff结构如下所示：

这里要声明两个概念的区别，后续直接用这两个概念，注意区分：

（1）线性数据：head - end。

（2）实际线性数据：data - tail，不包含线性数据中的头空间和尾空间。

skb->data_len : skb中的分片数据（非线性数据）的长度。

skb->len : skb中的数据块的总长度，数据块包括实际线性数据和非线性数据，非线性数据为data_len，所以skb->len= (data - tail) + data_len。

skb->truesize : skb的总长度，包括sk_buff结构和数据部分，skb=sk_buff控制信息 + 线性数据（包括头空间和尾空间） + skb_shared_info控制信息 + 非线性数据，所以skb->truesize = sizeof(struct sk_buff) + (head - end) + sizeof(struct skb_shared_info) + data_len。

sk_buff结构体中的都是sk_buff的控制信息，是网络数据包的一些配置，真正储存数据的是sk_buff结构体中几个指针指向的数据区中，线性数据区的大小 = (skb->end - skb->head)，对于每个数据包来说这个大小都是固定不变的，在传输过程中skb->end和skb->head所指向的地址都是不变的，这里要注意这个地址不是本机的地址，如果是本机的地址那么数据包传到其他主机上这个地址就是无效的，所以这个地址是这个skb缓冲区的相对地址。

线性数据区是用来存放各层协议头部和应用层发下来的数据。各层协议头部相关信息放在线性数据区中。实际数据指针为data和tail，data指向实际数据开始的地方，tail指向实际数据结束的地方。

用一张图来表示sk_buff和数据区的关系：

这一节介绍先行数据区在sk_buff创建过程中的变化，图中暂时省略了非线性数据区：

2.1中所讲的都是线性数据区中的相关的配置，当线性数据区不够用的时候就会启用非线性数据区作为数据区域的扩展，skb中用skb_shared_info分片结构体来配置非线性数据。

skb_shared_info结构体是和skb中的线性数据区一体的，所以在skb的各种 *** 作时都会把这两个结构看作是一个结构来 *** 作。如：

skb_shared_info结构：

非线性数据区有两种不同的构成数据的方式

（1）用数组存储的分片数据区，采用是是结构体中的frags[MAX_SKB_FRAGS]

对于frags[]一般用在当数据比较多，在线性数据区装不下的时候，skb_frag_t中是一页一页的数据，skb_frag_struct结构体如下：

下图显示了frags是怎么分配分片数据的：

（2）frag_list指针来指向的分片数据：

参考：

一个报文的产生和发送，都需要硬件和软件的完美配合。

硬件层面接收到报文之后，做一系列的初始化 *** 作，之后驱动才开始把一个封包封装为skb。

当然这是在x86架构下，如果是在cavium架构下，封包是wqe形式存在。

不管是skb还是wqe，都仅仅是一种手段，一种达到完成报文传输所采用的一种解决方案，一种方法而已。

或许处理方案的具体实现细节差别万千，但是基本的原理，都是殊途同归，万变不离其宗。

skb的产生，让Linux协议栈旅程的开启，具备了最基本的条件，接下来的协议栈之旅，才会更加精彩。

写作本文的原因是现在本机网络 IO 应用非常广。

在 php 中 一般 nginx 和 php-fpm 是通过 127.0.0.1 来进行通信的；

在微服务中，由于 side car 模式的应用，本机网络请求更是越来越多。

所以，如果能深度理解这个问题在各种网络通信应用的技术实践中将非常的有意义。

今天咱们就把 127.0.0.1 本机网络通信相关问题搞搞清楚！

为了方便讨论，我把这个问题拆分成3问：

1）127.0.0.1 本机网络 IO 需要经过网卡吗？

2）和外网网络通信相比，在内核收发流程上有啥差别？

3）使用 127.0.0.1 能比 192.168.x.x 更快吗？

在上面这幅图中，我们看到用户数据被拷贝到内核态，然后经过协议栈处理后进入到了 RingBuffer 中。随后网卡驱动真正将数据发送了出去。当发送完成的时候，是通过硬中断来通知 CPU，然后清理 RingBuffer。

当数据包到达另外一台机器的时候，Linux 数据包的接收过程开始了。

当网卡收到数据以后，CPU发起一个中断，以通知 CPU 有数据到达。

当CPU收到中断请求后，会去调用网络驱动注册的中断处理函数，触发软中断。

ksoftirqd 检测到有软中断请求到达，开始轮询收包，收到后交由各级协议栈处理。

当协议栈处理完并把数据放到接收队列的之后，唤醒用户进程（假设是阻塞方式）。

关于跨机网络通信的理解，可以通俗地用下面这张图来总结一下：

前面，我们看到了跨机时整个网络数据的发送过程 。

在本机网络 IO 的过程中，流程会有一些差别。

为了突出重点，本节将不再介绍整体流程，而是只介绍和跨机逻辑不同的地方。

有差异的地方总共有两个，分别是路由和驱动程序。

对于本机网络 IO 来说，特殊之处在于在 local 路由表中就能找到路由项，对应的设备都将使用 loopback 网卡，也就是我们常见的 lO。

从上述结果可以看出，对于目的是 127.0.0.1 的路由在 local 路由表中就能够找到了。

对于是本机的网络请求，设备将全部都使用 lo 虚拟网卡，接下来的网络层仍然和跨机网络 IO 一样。

本机网络 IO 需要进行 IP 分片吗？

因为和正常的网络层处理过程一样，如果 skb 大于 MTU 的话，仍然会进行分片。

只不过 lo 的 MTU 比 Ethernet 要大很多。

通过 ifconfig 命令就可以查到，普通网卡一般为 1500，而 lO 虚拟接口能有 65535。

为什么我把“驱动”加个引号呢，因为 loopback 是一个纯软件性质的虚拟接口，并没有真正意义上的驱动。

在邻居子系统函数中经过处理，进入到网络设备子系统，只有触发完软中断，发送过程就算是完成了。

在跨机的网络包的接收过程中，需要经过硬中断，然后才能触发软中断。

而在本机的网络 IO 过程中，由于并不真的过网卡，所以网卡实际传输，硬中断就都省去了。直接从软中断开始，送进协议栈。

网络再往后依次是传输层，最后唤醒用户进程，这里就不多展开了。

我们来总结一下本机网络通信的内核执行流程：

回想下跨机网络 IO 的流程：

通过本文的叙述，我们确定地得出结论，不需要经过网卡。即使了把网卡拔了本机网络是否还可以正常使用的。

总的来说，本机网络 IO 和跨机 IO 比较起来，确实是节约了一些开销。发送数据不需要进 RingBuffer 的驱动队列，直接把 skb 传给接收协议栈（经过软中断）。

但是在内核其它组件上可是一点都没少：系统调用、协议栈（传输层、网络层等）、网络设备子系统、邻居子系统整个走了一个遍。连“驱动”程序都走了（虽然对于回环设备来说只是一个纯软件的虚拟出来的东东）。所以即使是本机网络 IO，也别误以为没啥开销。

先说结论：我认为这两种使用方法在性能上没有啥差别。

我觉得有相当大一部分人都会认为访问本机server 的话，用 127.0.0.1 更快。原因是直觉上认为访问 IP 就会经过网卡。

其实内核知道本机上所有的 IP，只要发现目的地址是本机 IP 就可以全走 loopback 回环设备了。

本机其它 IP 和 127.0.0.1 一样，也是不用过物理网卡的，所以访问它们性能开销基本一样！

How SKBs work - Linux kernel

http://vger.kernel.org/~davem/skb.html

一篇解读Linux网络协议栈

https://zhuanlan.zhihu.com/p/475319464

你真的了解127.0.0.1和0.0.0.0的区别？

http://www.52im.net/thread-2928-1-1.html

深入 *** 作系统，彻底搞懂127.0.0.1本机网络通信

http://www.52im.net/thread-3590-1-1.html

---