Linux原始套接字实现分析---转
|
??? 当socket()函数的第三个参数protocol为非零的情况下，会调用dev_add_pack()将链路层套接字packet_sock的packet_type结构链到ptype_all链表或ptype_base链表中。???? void dev_add_pack(struct packet_type?*pt)?????当protocol为ETH_P_ALL时，会将套接字加入到ptype_all链表中。如图2所示，这里创建了两个链路层原始套接字。
当protocol为其它非0值时，会将套接字加入到ptype_base链表中。如图3所示，协议栈本身也需要注册packet_type结构，图中浅色的两个packet_type结构分别是IP协议和ARP协议注册的，其处理函数分别为ip_rcv()和arp_rcv()。图中另外3个深色的packet_type结构则是链路层原始套接字注册的，分别用于接收类型为ETH_P_IP、ETH_P_ARP和0x0810类型的报文。
2.2.2??报文接收 网卡驱动程序接收到报文后，在软中断上下文由netif_receive_skb()处理。首先会逐个遍历ptype_all链表中的packet_type结构，若满足条件“(!ptype->dev || ptype->dev == skb->dev)”，即套接字未绑定或者套接字绑定网口与skb所在网口匹配，就增加报文引用计数并交给packet_rcv()函数处理（若使用PACKET_MMAP收包方式则由tpacket_rcv()函数处理）。 网卡驱动->netif_receive_skb()->deliver_skb()->packet_rcv()/tpacket_rcv() ??? 以非PACKET_MMAP收包方式为例进行说明，packet_rcv()函数中比较重要的代码片段如下。当报文skb到达packet_rcv()函数时，其skb->data所指的数据是不包含MAC首部的，所以对于type为非SOCK_DGRAM（即SOCK_RAW）类型，需要将skb->data指针前移，以便数据部分可以包含MAC首部。最后将skb放到套接字的接收队列sk->sk_receive_queue中，并唤醒用户态进程来读取套接字中的数据。 ……?PACKET_MMAP收包方式的实现有所不同，tpacket_rcv()函数将skb->data拷贝到与用户态mmap映射的共享内存中，最后唤醒用户态进程来读取数据。由于报文的内容已存放在内核空间和用户空间共享的缓冲区中，用户态可以直接读取以减少数据的拷贝，所以这种方式效率比较高。 ??? 上面介绍了报文接收在软中断的处理流程。下面以非PACKET_MMAP收包方式为例，介绍用户态读取报文数据的流程。用户态recvmsg()最终调用skb_recv_datagram()，如果套接字接收队列sk->sk_receive_queue中有报文就取skb并返回。否则调用wait_for_packet()等待，直到内核软中断收到报文并唤醒用户态进程。 sys_recvmsg()->sock_recvmsg()->…->packet_recvmsg()->skb_recv_datagram() 2.2.3??报文发送 用户态调用sendto()或sendmsg()，由套接字层最终会调用到packet_sendmsg()。 sys_sendto()->sock_sendmsg()->__sock_sendmsg()->packet_sendmsg()->dev_queue_xmit() ??? 该函数比较重要的函数片段如下。首先进行参数检查及skb分配，再调用驱动程序的hard_header函数（对于以太网驱动是eth_header()函数）来构造报文的MAC头部，此时的skb->data是指向MAC首部的，且skb->len为MAC首部长度（即14）。对于创建时指定type为SOCK_RAW类型套接字，由于在发送时需要自行构造MAC头部，所以将skb->tail指针恢复到MAC首部开始的位置，并将skb->len设置为0（即不使用内核构造的MAC首部）。接着再调用memcpy_fromiovec()从skb->tail的位置开始拷贝报文数据，最终调用网卡驱动的发送函数将报文发送出去。 注：如果创建套接字时指定type为SOCK_DGRAM，则使用内核构造的MAC首部，用户态发送的数据中不含MAC头部数据。 <table style="width: 100%;" cellspacing="0" cellpadding="0"> |
