Linux_TCP_IP_协议栈的关键数据结构Socket_Buffer.pdf

Linux TCP/IP 协议栈的关键数据结构 Socket Buffer sk_buff 结构可能是 linux 网络代码中最重要的数据结构，它表示接收或发送数据包 的包头信息。它在include/linux/skbuff.h中定义，并包含很多成员变量供网络代码中 的各子系统使用。 这个结构在 linux 内核的发展过程中改动过很多次，或者是增加新的选项，或者是重 新组织已存在的成员变量以使得成员变量的布局更加清晰。它的成员变量可以大致分为以下 几类：  Layout 布局  General 通用  Feature-specific 功能相关  Management functions 管理函数 这个结构被不同的网络层（MAC 或者其他二层链路协议，三层的 IP，四层的TCP 或 UDP 等）使用，并且其中的成员变量在结构从一层向另一层传递时改变。L4 向 L3 传递前 会添加一个 L4 的头部，同样，L3 向 L2 传递前，会添加一个 L3 的头部。添加头部比在不 同层之间拷贝数据的效率更高。由于在缓冲区的头部添加数据意味着要修改指向缓冲区的指 针，这是个复杂的操作，所以内核提供了一个函数 skb_reserve （在后面的章节中描述） 来完成这个功能。协议栈中的每一层在往下一层传递缓冲区前，第一件事就是调用 skb_re serve 在缓冲区的头部给协议头预留一定的空间。 skb_reserve 同样被设备驱动使用来对齐接收到包的包头。如果缓冲区向上层协议传 递，旧的协议层的头部信息就没什么用了。例如，L2 的头部只有在网络驱动处理 L2 的协 议时有用，L3 是不会关心它的信息的。但是，内核并没有把 L2 的头部从缓冲区中删除， 而是把有效荷载的指针指向 L3 的头部，这样做，可以节省 CPU 时间。 1. 网络参数和内核数据结构 就像你在浏览 TCP/IP 规范或者配置内核时所看到的一样，网络代码提供了很多有用 的功能，但是这些功能并不是必须的，比如说，防火墙，多播，还有其他一些功能。大部分 的功能都需要在内核数据结构中添加自己的成员变量。因此，sk_buff 里面包含了很多像# ifdef 这样的预编译指令。例如，在 sk_buff 结构的最后，你可以找到： struct sk_buff { ... ... ... #ifdef CONFIG_NET_SCHED _ _u32 tc_index; #ifdef CONFIG_NET_CLS_ACT _ _u32 tc_verd; _ _u32 tc_classid; #endif #endif } 它表明，tc_index 只有在编译时定义了 CONFIG_NET_SCHED 符号才有效。这个 符号可以通过选择特定的编译选项来定义（例如：Device Drivers Networking suppo rtNetworking options QoS and/or fair queueing）。这些编译选项可以由管理员通 过 make config 来选择，或者通过一些自动安装工具来选择。 前面的例子有两个嵌套的选项：CONFIG_NET_CLS_ACT （包分类器）只有在选择 支持“QoS and/or fair queueing”时才能生效。 顺便提一下，QoS 选项不能被编译成内核模块。原因就是，内核编译之后，由某个选 项所控制的数据结构是不能动态变化的。一般来说，如果某个选项会修改内核数据结构（比 如说，在 sk_buff 里面增加一个项 tc_index ），那么，包含这个选项的组件就不能被编译成内核模块。 你可能经常需要查找是哪个 make config编译选项或者变种定义了某个#ifdef标记， 以便理解内核中包含的某段代码。在 2.6 内核中，最快的，查找它们之间关联关系的方法， 就是查找分布在内核源代码树中的 kconfig 文件中是否定义了相应的符号（每个目录都有 一个这样的文件）。在 2.4 内核中，你需要查看 Documentation/Configure.help 文件。 2. Layout Fields 有些 sk_buff 成员变量的作用是方便查找或者是连接数据结构本身。内核可以把 sk_ buff 组织成一个双向链表。当然，这个链表的结