注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

小可尼の博客

Linux后端的技术窝窝

 
 
 

日志

 
 

skb_buff结构分析  

2013-08-28 22:08:38|  分类: linux内核开发 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
出处:http://blog.csdn.net/zhoujunyi/article/details/1920334

struct sk_buff可能是linux网络代码中最重要的数据结构,它表示接收或发送数据包的包头信息,并包含很多成员变量供网络代码中的各子系统使用。
    这个结构被网络的不同层(MAC或者其他二层链路协议,三层的IP,四层的TCP或UDP等)使用,并且其中的成员变量在结构从一层向另一层传递时改变。 L4向L3传递前会添加一个L4的头部,同样,L3向L2传递前,会添加一个L3的头部。添加头部比在不同层之间拷贝数据的效率更高。由于在缓冲区的头部 添加数据意味着要修改指向缓冲区的指针,这是个复杂的操作,所以内核提供了一个函数skb_reserve来完成这个功能。协议栈中的每一层在往下一层传 递缓冲区前,第一件事就是调用skb_reserve在缓冲区的头部给协议头预留一定的空间。
    skb_reserve同样被设备驱动使用来对齐接收到包的包头。如果缓冲区向上层协议传递,旧的协议层的头部信息就没什么用了。例如,L2的头部只有在 网络驱动处理L2的协议时有用,L3是不会关心它的信息的。但是,内核并没有把L2的头部从缓冲区中删除,而是把有效荷载的指针指向L3的头部,这样做, 可以节省CPU时间。

    有些sk_buff成员变量的作用是方便查找或者是连接数据结构本身。内核可以把sk_buff组织成一个双向链表。当然,这个链表的结构要比常见的双向 链表的结构复杂一点。就像任何一个双向链表一样,sk_buff中有两个指针next和prev,其中,next指向下一个节点,而prev指向上一个节 点。在第一个节点前面会插入另一个结构sk_buff_head,这是一个辅助节点(作为sk_buff双向链表的头),它的定义如下:
struct sk_buff_head {
    struct sk_buff -
*next;
    struct sk_buff -*prev;
    __u32           qlen;
    spinlock_t      lock;
};
    qlen代表链表元素的个数
    lock用于防止对链表的并发访问
    sk_buff和sk_buff_head的前两个元素是一样的:next和prev指针。这使得它们可以放到同一个链表中,尽管sk_buff_head要比sk_buff小得多。另外,相同的函数可以同样应用于sk_buff和sk_buff_head。



sk_buff->sk
    这是一个指向拥有这个sk_buff的sock结构的指针。这个指针在网络包由本机发出或者由本机进程接收时有效,因为插口相关的信息被L4(TCP或 UDP)或者用户空间程序使用。如果sk_buff只在转发中使用(这意味着,源地址和目的地址都不是本机地址),这个指针是NULL

sk_buff->len
   
表示当前协议数据包的长度
。它包括主缓冲区中的数据长度(data指针指向它)和分片中的数据长度。

sk_buff->data_len
    和len不同,data_len只计算分片中数据的长度

sk_buff->mac_len
    这是mac头的长度

sk_buff->users
    这是一个引用计数,用于计算有多少实体引用了这个sk_buff缓冲区。它的主要用途是防止释放sk_buff后,还有其他实体引用这个sk_buff。 因此,每个引用这个缓冲区的实体都必须在适当的时候增加或减小这个变量。这个计数器只保护sk_buff结构本身,而缓冲区的数据部分由类似的计数器 (dataref)来保护.有时可以用atomic_inc和atomic_dec函数来直接增加或减小users,但是,通常还是使用函数 skb_get和kfree_skb来操作这个变量。

sk_buff->truesize
    这是缓冲区的总长度,包括sk_buff结构和数据部分。如果申请一个len字节的缓冲区,alloc_skb函数会把它初始化成len+sizeof(sk_buff)。当skb->len变化时,这个变量也会变化。

sk_buff->head
sk_buff->data
sk_buff->tail
sk_buff->end

    它们表示缓冲区和数据部分的边界。在每一层申请缓冲区时,它会分配比协议头或协议数据大的空间。head和end指向缓冲区的头部和尾部,而data和 tail指向实际数据的头部和尾部。每一层会在head和data之间填充协议头,或者在tail和end之间添加新的协议数据。数据部分会在尾部包含一 个附加的头部。

        struct sk_buff
         |----------|
         |          |
-+---->|--------|
         |          |
-
|     |        | head
         |          |
-
|     |        |
         |----------|
-| -
+->|--------|
         |   head   |--+
-| -
|        |
         |----------|     |
-
|        |
         |   data   |-----+
-|        | data
         |----------|        |        |
         |   tail   |-----+
-
|        |
         |----------|     |
-
|        |
         |   end    |--+
-| -
|        |
         |----------|
-| -
+->|--------|
                       |     |        | tail
                       |     |        |
                       +---->|--------|

void (*destructor)(struct sk_buff *skb)
    这个函数指针可以初始化成一个在缓冲区释放时完成某些动作的函数。如果缓冲区不属于一个socket,这个函数指针通常是不会被赋值的。如果缓冲区属于一 个socket,这个函数指针会被赋值为sock_rfree或sock_wfree(分别由skb_set_owner_r或 skb_set_owner_w函数初始化)。这两个sock_xxx函数用于更新socket的队列中的内存容量。


sk_buff->tstamp
    这个变量只对接收到的包有意义。它代表包接收时的时间戳,或者有时代表包准备发出时的时间戳。它在netif_rx里面由函数net_timestamp设置,而netif_rx是设备驱动收到一个包后调用的函数。

sk_buff->dev
    这个变量的类型是net_device,net_device它代表一个网络设备。dev的作用与这个包是准备发出的包还是刚接收的包有关。当收到一个包 时,设备驱动会把sk_buff的dev指针指向收到这个包的网络设备;当一个包被发送时,这个变量代表将要发送这个包的设备。在发送网络包时设置这个值 的代码要比接收网络包时设置这个值的代码复杂。有些网络功能可以把多个网 络设备组成一个虚拟的网络设备(也就是说,这些设备没有和物理设备直接关联),并由一个虚拟网络设备驱动管理。当虚拟设备被使用时,dev指针指向虚拟设 备的net_device结构。而虚拟设备驱动会在一组设备中选择一个设备并把dev指针修改为这个设备的net_device结构。因此,在某些情况 下,指向传输设备的指针会在包处理过程中被改变。

sk_buff->input_dev
    这是收到包的网络设备的指针。如果包是本地生成的,这个值为NULL。对以太网设备来说,这个值由
eth_type_trans初始化,它主要被流量控制代码使用。


sk_buff->h
sk_buff->nh
sk_buff->mac

    这些是指向TCP/IP各层协议头的指针:h指向L4(传输层),nh指向L3(网络层),mac指向L2(数据链路层)。每个指针的类型都是一个联合, 包含多个数据结构,每一个数据结构都表示内核在这一层可以解析的协议。例如,h是一个包含内核所能解析的L4协议的数据结构的联合。每一个联合都有一个 raw变量用于初始化,后续的访问都是通过协议相关的变量进行的。
    当接收一个包时,处理n层协议头的函数从其下层(n-1层)收到一个缓冲区,它的skb->data指向n层协议的头。处理n层协议的函数把本层的 指针(例如,L3对应的是skb->nh指针)初始化为skb->data,因为这个指针(data指针)的值会在处理下一层协议时改变 (skb->data将被初始化成缓冲区里的其他地址)。在处理n层协议的函数结束时,在把包传递给n+1层的处理函数前,它会把skb-> data指针指向n层协议头的末尾,这正好是n+1层协议的协议头。
    当网卡驱动程序收到一个UDP数据报后,它创建一个结构体struct sk_buff,确保sk_buff->data成员指向的空间足够存放收到的数据(对于数据报分片的情况,因为比较复杂,我们暂时忽略,我们假设 一次收到的是一个完整的UDP数据报)。把收到的数据全部拷贝到sk_buff->data指向的空间,然后,把skb->mac.raw指 向data,此时,数据报的开始位置是一个以太网头,所以skb->mac.raw指向链路层的以太网头。然后通过调用skb_pull剥掉以太网 头,所谓剥掉以太网头,只是把data加上sizeof(struct ethhdr),同时len减去这个值,这样,在逻辑上,skb已经不包含以太网头了,但通过skb->mac.raw还能找到它。这就是我们通常 所说的,IP数据报被收到后,在链路层被剥去以太网头。


sk_buff->dst
    这个变量在路由子系统中使用

sk_buff->sp
    这个变量被IPSec协议用于跟踪传输的信息

sk_buff->cb[48]
    这是一个“control buffer”,或者说是一个私有信息的存储空间,由每一层自己维护并使用。它在分配sk_buff结构时分配(它目前的大小是48字节,已经足够为每一 层存储必要的私有信息了)。在每一层中,访问这个变量的代码通常用宏实现以增强代码的可读性。例如,TCP用这个变量存储tcp_skb_cb结构。
    下面这个宏被TCP代码用来访问cb变量。在这个宏里面,有一个简单的类型转换:
    #define TCP_SKB_CB(__skb)     ((struct tcp_skb_cb *)&((__skb)->cb[0]))

    下面的例子是TCP子系统在收到一个分段时填充相关数据结构的代码:
int tcp_v4_rcv(struct sk_buff *skb)
{
    ...
    th = skb->h.th;
    TCP_SKB_CB(skb)->seq = ntohl(th->seq);
    TCP_SKB_CB(skb)->end_seq = (TCP_SKB_CB(skb)->seq + th->syn + th->fin +
                 skb->len - th->doff * 4);
    TCP_SKB_CB(skb)->ack_seq = ntohl(th->ack_seq);
    TCP_SKB_CB(skb)->when = 0;
    TCP_SKB_CB(skb)->flags = skb->nh.iph->tos;
    TCP_SKB_CB(skb)->sacked = 0;
    ...
}
    如果想要了解cb中的参数是如何被取出的,可以查看net/ipv4/tcp_output.c中的tcp_transmit_skb函数。这个函数被TCP用于向IP层发送一个分段。

sk_buff->csum
sk_buff->ip_summed

    表示校验和以及相关状态标记

sk_buff->cloned
    一个布尔标记,当被设置时,表示这个结构是另一个sk_buff的克隆

sk_buff->pkt_type
    这个变量表示帧的类型,分类是由L2的目的地址来决定的。这个值在网卡驱动程序中由函数eth_type_trans通过判断目的以太网地址来确定。如果 目的地址是FF:FF:FF:FF:FF:FF,则为广播地址,pkt_type = PACKET_BROADCAST;如果最高位为1,则为组播地址,pkt_type = PACKET_MULTICAST;如果目的mac地址跟本机mac地址不相等,则不是发给本机的数据报,pkt_type = PACKET_OTHERHOST;否则就是缺省值PACKET_HOST。
/* Packet types */
#define PACKET_HOST         0       /* To us        */
#define PACKET_BROADCAST    1       /* To all       */
#define PACKET_MULTICAST    2       /* To group     */
#define PACKET_OTHERHOST    3       /* To someone else      */
#define PACKET_OUTGOING     4       /* Outgoing of any type */


sk_buff->priority
    这个变量描述发送或转发包的QoS类别。如果包是本地生成的,socket层会设置priority变量。如果包是将要被转发的, rt_tos2priority函数会根据ip头中的Tos域来计算赋给这个变量的值。这个变量的值与DSCP(DiffServ CodePoint)没有任何关系。

sk_buff->protocol
    这个变量是高层协议从二层设备的角度所看到的协议。典型的协议包括IP,IPV6和ARP。完整的列表在 include/linux/if_ether.h中。由于每个协议都有自己的协议处理函数来处理接收到的包,因此,这个域被设备驱动用于通知上层调用哪 个协议处理函数。每个网络驱动都调用netif_rx来通知上层网络协议的协议处理函数,因此protocol变量必须在这些协议处理函数调用之前初始 化。



----------------------------------------
    linux内核是模块化的,你可以选择包含或者删除某些功能。因此,sk_buff结构里面的一些成员变量只有在内核选择支持某些功能时才有效,比如防火墙(netfilter)或者qos:
__u32             nfctinfo
...
#ifdef CONFIG_NETFILTER
    struct nf_conntrack     *nfct;
#if defined(CONFIG_NF_CONNTRACK) || defined(CONFIG_NF_CONNTRACK_MODULE)
    struct sk_buff     *nfct_reasm;
#endif
#ifdef CONFIG_BRIDGE_NETFILTER
    struct nf_bridge_info   *nf_bridge;
#endif
    __u32         nfmark;
#endif /* CONFIG_NETFILTER */

    这些变量被netfilter使用(防火墙代码),内核编译选项是“Device Drivers->Networking support-> Networking options-> Network packet filtering”和两个子选项“Network packet filtering debugging”和“Bridged IP/ARP packets filtering”


#ifdef CONFIG_NET_SCHED
    __u16          tc_index;
#ifdef CONFIG_NET_CLS_ACT
    __u16          tc_verd;
#endif
#endif
    这两个变量被流量控制代码使用。tc_index只有在编译时定义了CONFIG_NET_SCHED符号才有效;tc_verd只有在编译时定义了CONFIG_NET_CLS_ACT符号才有效。这两个符号可以通过选择特定的编译选项来定义:
Networking --->
    Networking options --->
        QoS and/or fair queueing --->
       [*] QoS and/or fair queueing
       [*]   Actions
   
    QoS选项不能被编译成内核模块。原因就是,内核编译之后,由某个选项所控制的数据结构是不能动态变化的。一般来说,如果某个选项会修改内核数据结构(比如说,在sk_buff里面增加一个项tc_index),那么,包含这个选项的组件就不能被编译成内核模块。
    你可能经常需要查找是哪个make menuconfig编译选项或者变种定义了某个#ifdef标记,以便理解内核中包含的某段代码。在2.6内核中,最快的,查找它们之间关联关系的方 法,就是查找分布在内核源代码树中的kconfig文件中是否定义了相应的符号(每个目录都有一个这样的文件)。在2.4内核中,你需要查看 Documentation/Configure.help文件。
    Quality of Service(QoS)服务质量
struct sk_buff {
    struct sk_buff    * next;                
         struct sk_buff    * prev;            
    struct sk_buff_head * list;        
    struct sock    *sk;            
    struct timeval    stamp;            
    struct net_device    *dev;        
    struct net_device    *real_dev;    

    union
    {
        struct tcphdr    *th;
        struct udphdr    *uh;
        struct icmphdr    *icmph;
        struct igmphdr    *igmph;
        struct iphdr    *ipiph;
        struct spxhdr    *spxh;
        unsigned char    *raw;
    } h;

    
    union
    {
        struct iphdr    *iph;
        struct ipv6hdr    *ipv6h;
        struct arphdr    *arph;
        struct ipxhdr    *ipxh;
        unsigned char    *raw;
    } nh;
union
    {    
          struct ethhdr    *ethernet;
          unsigned char     *raw;
    } mac;

    struct  dst_entry *dst;

     
    char        cb[48];     

    unsigned int     len;        

    unsigned int     data_len;
    unsigned int    csum;                
         unsigned char     __unused,            
        
            cloned,                       pkt_type,        
              ip_summed;            __u32        priority;            atomic_t    users;            
    unsigned short    protocol;        

    unsigned short    security;        
    unsigned int    truesize;                            

    unsigned char    *head;                            
    unsigned char    *data;                            
    unsigned char    *tail;            
    unsigned char     *end;            
    void         (*destructor)(struct sk_buff *);    
#ifdef CONFIG_NETFILTER
    
        unsigned long    nfmark;
    
    __u32        nfcache;
    
    struct nf_ct_info *nfct;
#ifdef CONFIG_NETFILTER_DEBUG
        unsigned int nf_debug;
#endif
#endif

#if defined(CONFIG_HIPPI)
    union{
        __u32    ifield;
    } private;
#endif

#ifdef CONFIG_NET_SCHED
       __u32           tc_index;               
#endif
};
 

该结构维护一个收到的或者要发送的网络包。但其本身并不包含存放网络包的数据的存储区。存储区是另外单独分配的内存空间,但该结构说明了如何访问存储区空间,如何维护多个存储区空间以及存储网络包解析的成果。

所有的sk_buff是通过一个双向链表进行维护的。需要说明的是该双向链表中的一个元素是struct sk_buff_head类型。它相当于该双向链表的表头,其中有锁,链表元素个数等维护链表的相关信息。链表中其它的元素都是sk_buff类型。

链表结构图如下:

而对于每个sk_buff而言,如前所述,其本身并不维护网络包的存储区。该结构跟存储区的关系如下图所示:

图的左边表示sk_buff结构,右侧表示网络包的存储区。可以看到,sk_buff中有四个指针指向存储区。其中head一定指向存储区的开头,end一定指向存储区的结尾。data指向实际内容的开头,tail指向实际内容的结尾。这样做有两个原因,一是在分配空间的时候我们尚不知道具体需要多大的空间,只能按照最大可能空间来分配;二是为了满足字节对齐的需要。

图中Data部分的内容包括网络包的所有内容。对于输入包而言,其就是从当前层向上的所有层的头和最后的负载,每解析掉一层的头,该协议的协议头对应的数据就不再继续处理,所以data指针在每层会逐渐增大。对于输出包而言,其每向下传输一层,都会添加一层的头,所以sk_buffdata指针也会不断减小。

对于输入包而言,存储区的内容是不变的。但我们在分析包时,在每层都会剥除该层的头。为了保留我们的剥除结果,结构中会有三个指针分别指向以太,网络和传输三层的协议头。这三个指针依次分别是union {…} macunion {…} nhunion{…} h。三个成员都是联合,其中的内容是该层可能的协议类型的指针。

还有一组成员表示存储区中数据的长度。len表示存储区的数据长度和分片长度之和。data_len表示分片长度。mac_len表示mac头的长度。truesize表示存储区总长度(即end-head)和sk_buff本身长度之和。

下面的内容是关于如何维护存储区。

alloc_skbdev_alloc_skb用来分配sk_buff和存储区,kfree_skbdev_kfree_skb则释放sk_buff和其对应的存储区。刚初始化完的存储区,headdatatail都指向存储区的开头,end指向结尾。下面这些函数是修改datatail指针的指向。

skb_reserve是在存储区的开头保留一段空间。其有两个作用,对于接收到的报文而言,可以保持字节对齐;对于发送的报文而言,可以保留空间用于存放各层的协议头。毕竟我们在高层协议就会分配该存储区,所以需要预留下层的协议头的空间。该函数的作用会导致datatail两个指针都下移,在head和它们之间留出空间。

skb_put则是将tail下移,即增加了真正空间的长度。

skb_push是将data上移,也增加了真正空间的长度。

skb_pulldata下移,减少了真正空间的长度。

下面是sk_buff的其它成员:

struct sock *sk:表示该网络包所属的socket。对于该主机发送的和接收的网络包,自然对应着一个socket套接字。对于转发的网络包,则该成员为NULL

atomic_t users:表示该sk_buff结构实例被引用的计数。这个是结构本身的引用计数,而不是其对应的存储区的引用计数。

void (*destructor)():析构函数。

struct timeval stamp:对于接受包,表示该包接收到的时间。

struct net_device *dev:接收或者发送包的网卡接口。

struct net_device *input_dev:接收到包的网卡接口。

struct net_device *real_dev:在某些机器中,多个物理网卡接口可以被看作一个虚拟设备。这中情况下real_dev表示物理结构。

char cb[40]:一个用于对该网络包进行处理的通用缓冲区。可以存放一些在不同层之间传输的数据。

unsigned int csumipsum:校验和。

unsigned char cloned

unsigned char pkt_type:包类型,可以是单发给该主机的包,广播包,多播包,转发包等。

unsigned short protocol:表示以太层的上层协议,可以是IPIPv6ARP

下面是关于skb_shared_info结构的。当我们使用alloc_skb分配空间时,会在存储区的后面紧接着一个该结构的实例。如下图所示:

其中存储了关于网络块的附加信息。不知为何不也放在sk_buff中。其中维护了存储块的引用计数,IP分片数据的信息。

对于sk_buff和存储块,有时是需要拷贝的。分为三种情况,一是只拷贝sk_buff,存储块复用,此时使用skb_clone函数;二是拷贝sk_buff和存储块的主体,但存储块后的skb_shared_infofrags数组指向的分片数据不拷贝,这使用pskb_copy函数;三是上述的全都拷贝,使用skb_copy函数。在不同情况下不同使用。

  评论这张
 
阅读(930)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018