Linux 内核网络协议栈 ------sk_buff 结构体以及完全解释（2.6.16）

心已赠人 2022-05-26 23:49 247阅读 0赞

在2.6.24之后这个结构体有了较大的变化，此处先说一说2.6.16版本的sk\_buff，以及解释一些问题。

**一、**

先直观的看一下这个结构体~~~~~~~~~~~~~~~~~~~~~~在下面解释每个字段的意义~~~~~~~~~~~

**\[cpp\]** [view plain][] [copy][view plain]

1.  struct sk\_buff \{
2.  /\* These two members must be first. \*/
3.  struct sk\_buff \*next;
4.  struct sk\_buff \*prev;
5.  
6.  struct sock \*sk;
7.  struct skb\_timeval tstamp;
8.  struct net\_device \*dev;
9.  struct net\_device \*input\_dev;
10. 
11. union \{
12. struct tcphdr \*th;
13. struct udphdr \*uh;
14. struct icmphdr \*icmph;
15. struct igmphdr \*igmph;
16. struct iphdr \*ipiph;
17. struct ipv6hdr \*ipv6h;
18. unsigned char \*raw;
19. \} h;
20. 
21. union \{
22. struct iphdr \*iph;
23. struct ipv6hdr \*ipv6h;
24. struct arphdr \*arph;
25. unsigned char \*raw;
26. \} nh;
27. 
28. union \{
29. unsigned char \*raw;
30. \} mac;
31. 
32. struct dst\_entry \*dst;
33. struct sec\_path \*sp;
34. 
35. /\*
36.  \* This is the control buffer. It is free to use for every
37.  \* layer. Please put your private variables there. If you
38.  \* want to keep them across layers you have to do a skb\_clone()
39.  \* first. This is owned by whoever has the skb queued ATM.
40.  \*/
41. char cb\[48\];
42. 
43. unsigned int len,
44. data\_len,
45. mac\_len,
46. csum;
47. \_\_u32 priority;
48. \_\_u8 local\_df:1,
49. cloned:1,
50. ip\_summed:2,
51. nohdr:1,
52. nfctinfo:3;
53. \_\_u8 pkt\_type:3,
54. fclone:2,
55. ipvs\_property:1;
56. \_\_be16 protocol;
57. 
58. void (\*destructor)(struct sk\_buff \*skb);
59. \#ifdef CONFIG\_NETFILTER
60. \_\_u32 nfmark;
61. struct nf\_conntrack \*nfct;
62. \#if defined(CONFIG\_NF\_CONNTRACK) || defined(CONFIG\_NF\_CONNTRACK\_MODULE)
63. struct sk\_buff \*nfct\_reasm;
64. \#endif
65. \#ifdef CONFIG\_BRIDGE\_NETFILTER
66. struct nf\_bridge\_info \*nf\_bridge;
67. \#endif
68. \#endif /\* CONFIG\_NETFILTER \*/
69. \#ifdef CONFIG\_NET\_SCHED
70. \_\_u16 tc\_index; /\* traffic control index \*/
71. \#ifdef CONFIG\_NET\_CLS\_ACT
72. \_\_u16 tc\_verd; /\* traffic control verdict \*/
73. \#endif
74. \#endif
75. 
76. 
77. /\* These elements must be at the end, see alloc\_skb() for details. \*/
78. unsigned int truesize;
79. atomic\_t users;
80. unsigned char \*head,
81. \*data,
82. \*tail,
83. \*end;
84. \};

> : next和prev，这两个域是用来连接相关的skb的(例如如果有分片，将这些分片连接在一起可以)

> : sk，指向报文所属的套接字指针

> : tstamp，记录接收或者传输报文的时间戳

> : dev和input\_dev，记录接收或者发送的设备

>: union u，对于一个层次，例如tcp层，可能有很多不同的协议，他们的协议头不一样，那么这个联合体就是记录这些协议头的。

此处u就是代表传输层

> : union nh，代表网络层头

> : union mac，代表链路层头

> : dst，指向des\_entry结构，记录了到达目的地的路由信息，以及其他的一些网络特征信息。

> : sp：安全路径，用于xfrm

> : cb\[\]，保存与协议相关的控制信息，每个协议可能独立使用这些信息。

> : 重要的字段 len 和 data\_len：

len代: 表整个数据区域的长度！这里要提前解释几个定义，skb的组成是有sk\_buff控制 + 线性数据 + 非线性数据

(skb\_shared\_info) 组成！

后面会具体解释是什么意思！在sk\_buff这个里面没有实际的数据，这里仅仅是控制信息，数据是通过后面的data指针指向其他内

存块的！那个内存块中是线性数据和

非线性数据！那么len就是length(线性数据) + length(非线性数据)！！！

data\_len: 指的是length(非线性数据)！！！那么可以知道：length(线性数据) = skb->len - skb->data\_len

> : mac\_len，指的是mac头长度

> : csum，某时刻协议的校验和

> : priority，报文排队优先级，取决于ip中的tos域

> : local\_df，允许在本地分配

> : cloned，保存当前的skb\_buff是克隆的还是原始数据

> : ip\_summed，是否计算ip校验和

> : nohdr，仅仅引用数据区域

> : pkt\_type，报文类型，例如广播，多播，回环，本机，传出...

> : fclone，skb\_buff克隆状态

> : ipvs\_property，skb\_buff是否属于ipvs

> : protocal，协议信息

> : nfmark，用于钩子之间通信

> : nfct\_reasm，netfilter的跟踪连接重新组装指针

> : nf\_bridge，保存桥接信息

> : tc\_index: Traffic control index，tc\_verd: traffic control verdict

> : truesize，该缓冲区分配的所有总的内存，包括：skb\_buff + 所有数据大小

> : users，保存引用skb\_buff的数量

> : 重要数据字段：head，data，tail，end！！！

head：指向分配给的线性数据内存首地址( 建立起一个观念：并不是分配这么多内存，就都能被使用作为数据存储，可能没这么多

数据也有可能！但是也不要认为分配这么多 就足够了，也不一定(非线性数据就是例子) )

data：指向保存数据内容的首地址！我们由head可以知道，head和data不一定就是指在同一个位置！！！

tail：指向数据的结尾！

end：指向分配的内存块的结尾！ ( 由上面我们知道数据结尾 != 分配的内存块的结尾 )

下面还会具体分析！！！！！！！！！！！

**二、**

我觉得需要先了解一些对于一个数据skb到底有什么，或者说由哪些元素组成！这就需要知道所谓的 “线性数据” 和 “非线性数据”。

基本的组成如下：

> : sk\_buff ： 这是一个sk\_buff的控制结构

> : 线性数据区域

> : 非线性数据区域( 由skb\_shared\_info结构体管理 )

那么下面通过一个图来看看这个skb结构到底是怎么样的！看（图一）

![SouthEast][]

**（图一）**

借助图一，我们先来分析两个重要字段：**len和data\_len**！

之前说过len代表的是整个数据的长度，data\_len代表的是非线性数据长度。我们由图一可以看到线性数据长度为l1，再看看非线性数据，其实就是看frags\[\]和frag\_list

ok...那么我们可以知道非线性数据长度为( l2 + ... + ln ) + ( l(n+1) + ... + lm )

即：len = l1 + ( l2 + ... + ln ) + ( l(n+1) + ... + lm )

data\_len = ( l2 + ... + ln ) + ( l(n+1) + ... + lm )

ok...

现在从分配内存开始解释这个图的由来：

我们使用skb\_alloc给skb分配空间，那么刚刚分配结束返回时候，是什么样的情况呢？看下图（图二）：

![SouthEast 1][]

**（图二）**

刚刚开始初始化的时候，预分配一个一块线性数据区域，这个区域一般放入的是各个协议层次的不同的头，还有一些实际数据，下面的非线性区域是为了弥补当数据真的很多的时候，作为数据区域的扩展！关于skb\_shared\_info具体意思下面会继续说！注意在初始化的时候，head，data和tail都指向内存的开始位置，head在这个位置始终不变，它表示的是分配的内存的开始位置。end的位置也是不变的，表示的是分配的内存的结束位置。data和tail会随着数据的加入和减少变化，总之表示的是放入数据的内存区域(由图一)可知。

现在需要解释一下skb\_shared\_info这个结构体，这个结构体真的是很很有特色！主要是其中的两个字段frags和frag\_list，下面继续解释：

**\[cpp\]** [view plain][] [copy][view plain]

1.  struct skb\_shared\_info \{
2.  atomic\_t dataref; // 对象被引用次数
3.  unsigned short nr\_frags; // 分页段数目，即frags数组元素个数
4.  unsigned short tso\_size;
5.  unsigned short tso\_segs;
6.  unsigned short ufo\_size;
7.  unsigned int ip6\_frag\_id;
8.  struct sk\_buff \*frag\_list; // 一般用于分段(还没有非常清楚的理解)
9.  skb\_frag\_t frags\[MAX\_SKB\_FRAGS\]; // 保存分页数据(skb->data\_len=所有的数组数据长度之和)
10. \};

**关于frags和frag\_list没有必然的联系！**

> : 对于frags\[\]一般用在，当数据真的很多，而且在线性数据区域装不下的时候，需要使用这个，skb\_frag\_t中是一页一页的数据，先看看结构体：

**\[cpp\]** [view plain][] [copy][view plain]

1.  struct skb\_frag\_struct \{
2.  struct page \*page; // 代表一页数据
3.  \_\_u16 page\_offset; // 代表相对开始位置的页偏移量
4.  \_\_u16 size; // page中数据长度
5.  \};

需要注意的是：只有在DMA支持物理分散页的Scatter/Gather（SG，分散/聚集）操作时候才可以使用frags\[\]来保存剩下的数据，否则，只能扩展线性数据区域进行保存！！！

这些页其实是其实就是虚拟页映射到物理页的结构，看下图(图三)：

![SouthEast 2][]

**（图三）**

> : 对于frag\_list来说，一般我们在分片的时候里面装入每个片的信息，注意，每个片最终也都是被封装成一个小的skb，这个必须

的！

注意：具体怎么分片的看上一篇博文：[数据分片][Link 1] ( 看其中的ip\_fragment函数 )

那么看一下其基本结构如图四：

![SouthEast 3][]

**（图四）**

**三、**

最重要的是需要理解对于这个skb是怎么操作的，在操作的过程中，每一块的内存分配是怎么变化的，这才更重要！

看下面的函数们：

> : alloc\_skb()函数

**\[cpp\]** [view plain][] [copy][view plain]

1.  static inline struct sk\_buff \*alloc\_skb(unsigned int size,
2.  gfp\_t priority)
3.  \{
4.  return \_\_alloc\_skb(size, priority, 0);
5.  \}

其实看\_\_alloc\_skb函数：

**\[cpp\]** [view plain][] [copy][view plain]

1.  struct sk\_buff \*\_\_alloc\_skb(unsigned int size, gfp\_t gfp\_mask,
2.  int fclone)
3.  \{
4.  kmem\_cache\_t \*cache;
5.  struct skb\_shared\_info \*shinfo;
6.  struct sk\_buff \*skb;
7.  u8 \*data;
8.  
9.  cache = fclone ? skbuff\_fclone\_cache : skbuff\_head\_cache; // 根据克隆状态来判断在哪一个缓冲区进行分配cache
10. 
11. /\* Get the HEAD \*/
12. skb = kmem\_cache\_alloc(cache, gfp\_mask & ~\_\_GFP\_DMA); // 得到skb，注意这里没有包含数据，仅仅是skb\_buff这个结构体
13. if (!skb)
14. goto out;
15. 
16. /\* Get the DATA. Size must match skb\_add\_mtu(). \*/
17. size = SKB\_DATA\_ALIGN(size); // 获得线性数据分片长度（注意对齐）
18. data = kmalloc(size + sizeof(struct skb\_shared\_info), gfp\_mask); // 注意分配的是什么，是size + skb\_shared\_info！！！！！
19. if (!data)
20. goto nodata;
21. 
22. memset(skb, 0, offsetof(struct sk\_buff, truesize)); // 初始化
23. skb->truesize = size + sizeof(struct sk\_buff); // 实际大小等于sk\_buff + size，刚刚开始还没有非线性数据
24. atomic\_set(&skb->users, 1);
25. skb->head = data; // 注意指针，这个结合上面的图一清二楚
26. skb->data = data;
27. skb->tail = data;
28. skb->end = data + size;
29. /\* make sure we initialize shinfo sequentially \*/
30. shinfo = skb\_shinfo(skb);
31. atomic\_set(&shinfo->dataref, 1);
32. shinfo->nr\_frags = 0;
33. shinfo->tso\_size = 0;
34. shinfo->tso\_segs = 0;
35. shinfo->ufo\_size = 0;
36. shinfo->ip6\_frag\_id = 0;
37. shinfo->frag\_list = NULL;
38. 
39. if (fclone) \{
40. struct sk\_buff \*child = skb + 1;
41. atomic\_t \*fclone\_ref = (atomic\_t \*) (child + 1);
42. 
43. skb->fclone = SKB\_FCLONE\_ORIG;
44. atomic\_set(fclone\_ref, 1);
45. 
46. child->fclone = SKB\_FCLONE\_UNAVAILABLE;
47. \}
48. out:
49. return skb;
50. nodata:
51. kmem\_cache\_free(cache, skb);
52. skb = NULL;
53. goto out;
54. \}

那么alloc之后的图就是(图五)：

![SouthEast 4][]

**（图五）**

其实和图二是一样的！我们可以看到，现在仅仅是分配了线束数据区域，但是现在还没有数据！一定要注意！所以前面三个指针指在一起！因为没有数据，那么len和data\_len的值就是0 ！

> : skb\_reserve函数

**\[cpp\]** [view plain][] [copy][view plain]

1.  static inline void skb\_reserve(struct sk\_buff \*skb, int len)
2.  \{
3.  skb->data += len;
4.  skb->tail += len;
5.  \}

代码其实很easy、就是移动两个指针而已~

这个函数很重要，是为“协议头”预留空间！而且是尽最大的空间预留，因为很多头都会有可选项，那么我们不知道可选项是多大，所以只能是按照最大的分配，那么也说明了一点，预留的空间headroom也就是不一定都能使用完的！可能还有剩余的，由上面的图也可以看出来！这也是为什么需要这么多指针的问题！那么这个函数直接导致head指针和tail、data指针分离，入下面图六所示：

![SouthEast 5][]

**（图六）**

注意headroom就是用来存储各个协议头的足够大的空间，tailroom就可以认为是存储其他线性数据的空间。( 这里不要曲解协议头不是线性数据，其实协议头也是！！！所以当增加头的时候，data指针向上移动，当增加其他数据的时候，tail指针向下移动 )。现在data和tail指向一起，那么还是说明数据没有！！！

> : skb\_put函数 ----> 用于操作线性数据区域(tailroom区域)的用户数据

**\[cpp\]** [view plain][] [copy][view plain]

1.  static inline unsigned char \*skb\_put(struct sk\_buff \*skb, unsigned int len)
2.  \{
3.  unsigned char \*tmp = skb->tail;
4.  SKB\_LINEAR\_ASSERT(skb);
5.  skb->tail += len; // 移动指针
6.  skb->len += len; // 数据空间增大len
7.  if (unlikely(skb->tail>skb->end)) // 如果tail指针超过end指针了，那么处理错误~
8.  skb\_over\_panic(skb, len, current\_text\_addr());
9.  return tmp;
10. \}

这函数其实就是从tailroom预留空间，相当于是移动tail指针，这样如果从上图（图六）开始看，也就是tail开始向下移动，和data分离了。。。一般来说，这样做都是为了用户数据再次处理，或者说为TCP/IP的负载预留空间！

看图七，当使用skb\_put时候，由图六---->图七

![SouthEast 6][]

**（图七）**  
  
我们可以看到指针的移动data还是在headroom的下面，中间的是用户数据预留的部分，由skb\_put得到，tail表示数据结尾！再看一下sk\_buff中的len，变成了数据长度ld！！

> : skb\_push函数：----------> 用于操作headroom区域的协议头

**\[cpp\]** [view plain][] [copy][view plain]

1.  static inline unsigned char \*skb\_push(struct sk\_buff \*skb, unsigned int len)
2.  \{
3.  skb->data -= len; // 向上移动指针
4.  skb->len += len; // 数据长度增加
5.  if (unlikely(skb->data<skb->head)) // data指针超过head那么就是处理错误~
6.  skb\_under\_panic(skb, len, current\_text\_addr());
7.  return skb->data;
8.  \}

和skb\_put对应，上面试操作用户数据的，这里是操作协议头的！其实就是data指针向上移动而已~注意len增大了哦~前面说了协议头也是属于数据！

如下面图所示，由图七---->图八

![SouthEast 7][]

**（图八）**

我们可以知道，data向上移动了，同时注意len变成ld+lp了，其中lp是这个增加的协议头的长度！

> : skb\_pull函数：-----------> 其实这个函数才是与skb\_push函数对应的函数！因为这是去头函数，而skb\_push是增头函数！所以这个函数一般用在解包的时候！

**\[cpp\]** [view plain][] [copy][view plain]

1.  static inline unsigned char \*skb\_pull(struct sk\_buff \*skb, unsigned int len)
2.  \{
3.  return unlikely(len > skb->len) ? NULL : \_\_skb\_pull(skb, len);
4.  \}
5.  
6.  
7.  static inline unsigned char \*\_\_pskb\_pull(struct sk\_buff \*skb, unsigned int len)
8.  \{
9.  if (len > skb\_headlen(skb) &&
10. !\_\_pskb\_pull\_tail(skb, len-skb\_headlen(skb)))
11. return NULL;
12. skb->len -= len; // 长度减小
13. return skb->data += len; // 移动指针
14. \}

其实就是data指针向下移动，当前一个协议头被去掉，headroom剩余的空间增大了！看下图：

由图八---->图九：

![SouthEast 8][]

**（图九）**

虚线是data之前的指针位置，现在移动到下面实线！！需注意：len的长度减小，减小的大小是剥去的头的大小！！

**四、**

最后我们从两条线整体分析一下：

1：从应用层用户数据开始，直到物理层发送出去

> 初始化的什么就不多说了，和前面的差不多，现在也加入用户数据已经在了，如图七所示一样！那么到了TCP层，需要增加

TCP层的头：

如图10所示：

![SouthEast 9][]

**（图10）**

需要注意的是这里是传输层，那么传输层的结构u中的th代表的是tcp的头，那么tcp指向tcp头OK！同时注意 len长度+=l1 哦~~~

> 再看到了IP层：如图11

![SouthEast 10][]

**（图11）**

至于需要解释什么就没什么了，都是一样的~

> 到链路层了：如图12

![SouthEast 11][]

**（图12）**

OK！

2：第二个过程其实是第一个逆过程，都差不多，所以不多说了~

**五、**

最后看一下操作skb的两个函数pskb\_copy和skb\_copy

前者仅仅是将sk\_buff的结构体和线性数据copy过来，对于非线性数据，是引用原始的skb的数据的！而后者是不仅将sk\_buff和线性数据拷贝，同时将非线性数据也copy了一份，看下面就明白了！这就在效率上就差了很多！所以如果不想修改数据，那么还是使用pskb\_copy更好！

对于pskb\_copy：

![SouthEast 12][]

对于skb\_copy：

![SouthEast 13][]

OK 我觉得差不多了~~~~~结束~~~~~~~~~~~~~

[view plain]: https://blog.csdn.net/shanshanpt/article/details/21024465#
[SouthEast]: /images/20220527/dd96236c9ccc41b99f474cfbf806e193.png
[SouthEast 1]: /images/20220527/d47bff3b7ed645cb8ee347ea694e3c41.png
[SouthEast 2]: /images/20220527/8f2d166852f64095810c33d3767d2bd9.png
[Link 1]: http://blog.csdn.net/shanshanpt/article/details/20699543
[SouthEast 3]: /images/20220527/2402a05d043d4004b1b92e9177d696c2.png
[SouthEast 4]: /images/20220527/f51f8d8aee6c4af186de5457e1d61389.png
[SouthEast 5]: /images/20220527/313949dc04314e6abb1548400ee6dfa8.png
[SouthEast 6]: /images/20220527/de153520719f4fbfb9aacd4ea01b4e41.png
[SouthEast 7]: /images/20220527/40d9ef6ed0b64bd7a3c376785f0bd574.png
[SouthEast 8]: /images/20220527/4c1f8de294d1469b89c00bf3fe522fd1.png
[SouthEast 9]: /images/20220527/9709236f65414fe1a4e3d8cfec48e352.png
[SouthEast 10]: /images/20220527/00f72115bef94498b601463453cb5872.png
[SouthEast 11]: /images/20220527/07d8d5f3717641e6823e2f61671b9e94.png
[SouthEast 12]: /images/20220527/c0395d33ad864e2790816145028c0448.png
[SouthEast 13]: /images/20220527/93bf6ba1ac7a40c39a675fab0cfd7f91.png