| ，否则如ip_packet_type，会在数组ptype_base[16]找到相应的位置。两者不同点是如果
是以ETH_P_ALL类型登记,那么处理函数会受到所有类型的包，否则只能处理自己登记的类
型的。
skb->protocol是在el3_rx中赋值的，其实就是以太帧头信息中提取出的上层协议名，对于我
们的例子来说，这个值是ETH_P_IP，所以在net_tx_action中，会选择IP层的接收处理函
数，而从ip_packet_type 不难看出，这个函数便是ip_recv（）。
pt_prev->func（实际指向ip_recv）前面有一个atomic_inc(&skb->users)操作（在2.2内核
中这个地方是一句skb_clone，原理类似），目的是增加这个sk_buff的引用数。网络层的接
收函数在处理完或因为某些原因要丢弃此sk_buff时（如防火墙）会调用kfree_skb，而
kfree_skb中首先会检查是否还有其他地方需要此函数，如果没有地方再用，才真正释放此内
存（__kfree_skb），否则只是计数器减一。
现在我们便来看看ip_recv（net/ipv4/ip_input.c）。这个函数的操作是非常清晰的:首先检查
这个包的合法性（版本号，长度，校验和等是否正确），如果合法则进行接下来的处理。在
2.4内核中，为了灵活处理防火墙代码，将原来的一个ip_recv分成了两部分，即将将原来的
的ip_recv的后半段独立出一个ip_rcv_finish函数。在ip_rcv_finish中，一部分是带有IP选项
（如源路由等）的IP包，例外就是通过ip_route_input查找路由，并将结果记录到skb->dst
中。此时接收到的包有两种，发往本地进程（需要传往上层协议）或转发（用作网关时），
此时需要的处理函数也不相同，如果传往本地，则调用ip_local_deliver(/net/ipv4/ip_input.c),
否则调用ip_forward(/net/ipv4/ip_forward.c).skb->dst->input这个函数指针会将数据报领上
正确的道路。
对我们的例子而言，此时应该是调用ip_local_deliver的时候了。
发来的包很有可能是碎片包，这样的话则首先应该把它们组装好再传给上层协议，这当然也
是ip_local_deliver函数所做的第一份工作，如果组装成功（返回的sk_buff不为空），则继续
处理（详细的组装算法可参见绿盟月刊13期中的《IP分片重组的分析和常见碎片攻击》）。
但此时代码又被netfilter一分为二了，象前面一样，我们直接到后半段，即
ip_local_deliver_finish(/net/ipv4/ip_input.c)中去。
传输层（如TCP,UDP，RAW）的处理被登记到了inet_protos中（通过
inet_add_protocol）。ip_local_deliver_finish会根据IP头信息中的上层协议信息（即
iph->protocol），调用相应的处理函数。为了简便，我们采用了udp,此时的ipprot->handler
实际便是udp_rcv了。
前面已经提到，在应用程序中建立的每个socket在内核中有一个struct socket/struct sock对
应。udp_rcv会通过udp_v4_lookup首先找到在内核中的sock,然后将其作参数调用
udp_queue_rcv_skb（/net/ipv4/udp.c）。马上，sock_queue_rcv_skb函数被调用，此函数
将sk_buff放入等待队列，然后通知上层数据到达：
...
kb_set_owner_r(skb, sk);
skb_queue_tail(&sk->receive_queue, skb);
if (!sk->dead)
sk->data_ready(sk,skb->len);
return 0;
...
sk->data_ready的定义在sock结构初始化的时候（sock_init_data）：
...
sk->data_ready=sock_def_readable;
...
现在我们便要从上往下看起了：
进程B要接收数据报，在程序里调用：
...
read(sockfd,buff,sizeof(buff));
...
此系统调用在内核中的函数是sys_read(fs/read_write.c)以下的处理类似write的操作，不再
详述.udp_recvmsg函数会调用skb_recv_datagram，如果数据还没有到达，且socket设为阻
塞模式时，进程会挂起（signal_pending(current)），直到data_ready通知进程资源得到满
足后继续处理（wake_up_interruptible(sk->sleep);）。
2.4 skbuff
网络代码中有大量的处理涉及对sk_buff的操作，尽管此文中尽量将其回避了，但在仔细分析
的时候则必须对此作分析，数据包在网络协议层是以sk_buff的形式传送处理的，可以说它是
网络部分最重要的数据结构。具体分析建议参看alan cox的《Network Buffers And Memory
Management》，这篇发表在1996年10月的linux journal上。
这里引用phrack 55-12期中的一幅图,尽管它只描绘了sk_buff的极小的一个侧面，但却非常
有用，尤其是当你像我一样总忘记了skb_put是向前还是向后调指针的时候：）
--- -----------------hand
^ | |
| | | ^ skb_push
| | | |
| -----------------data--- ---
| | | ^ |
true | | | v skb_pull
size | | len
| | | | ^ skb_trim
| | | v |
| -----------------tail--- ---
| | | |
| | | v skb_put
v | |
--- -----------------end
linux网络层效率：在linux的网络层代码中指针被大量应用，其目的就是避免数据拷贝这类耗
费系统资源的操作。一个数据包的数据段部分在读入或发出时只经过两次拷贝，即从网卡中
考到核心态内存，和从核心态内存考到用户态内存。前些天看到，在一些提高sniffer抓包效
率的尝试中，turbo packet(一个内核补丁)采用了核心态和
用户态共享一段内存的办法，又减少了一次数据拷贝，进一步提高了效率。
3 后记：
这次的投稿又是到了最后关头仓促写出来的，看着里面拙劣的文笔，实在觉得有点对不住观
众～～如果有时间我会把这部分好好重写的，其实这也是我一直的愿望：）
4 参考文献：
[1.] phrack 55-12期
[2.] <Linux Kernel Internals> 2nd Edition
[3.] Network Buffers And Memory Management Alan Cox
http://www2.linuxjournal.com/lj-issues/issue30/1312.html
[4.] 浙大源码分析报告《Linux网络设备分析》潘纲
[5.] Linux IP Networking--A Guide to the Implementation and Modification of theLinux
Poptocol Stack
Glenn Herrin May 31,2000 http://www.movement.uklinux.net/linux-net.pdf
版权所有，未经许可，不得转载
欢迎访问我们的站点http://www.nsfocus.com/
中联绿盟给您安全的保障
上一页 [1] [2] |
