做网站排名优化有用吗,wordpress需要 伪静态,wordpress跳转到登录页面代码,网站建设 010最近学习linux内核网络协议栈#xff0c;把数据包接收流程大致理了一下#xff0c;前面也看了瀚海书香兄的总结#xff0c;感觉总结的比我精炼#xff0c;抓住了主干#xff0c;是一目了然的那种我的这篇本来是自己看得#xff0c;因此把我自己学习中一些遇到的问题写了出…最近学习linux内核网络协议栈把数据包接收流程大致理了一下前面也看了瀚海书香兄的总结感觉总结的比我精炼抓住了主干是一目了然的那种我的这篇本来是自己看得因此把我自己学习中一些遇到的问题写了出来可能其他人会觉得废话比较多呵呵另外因为我看的书Understanding Linux Network Internal只讲了ip层及以下因此L4层的流程是我自己在代码中找的不保证100%正确如果有错误还希望大虾及时指出防止误人子弟NAPI驱动流程中断发生--确定中断原因是数据接收完毕(中断原因也可能是发送完毕DMA完毕甚至是中断通道上的其他设备中断)--通过netif_rx_schedule将驱动自己的napi结构加入softnet_data的poll_list链表禁用网卡中断并发出软中断--中断返回时触发软中断net_rx_action从softnet_data的poll_list上取下刚挂入的napi结构并且调用其poll函数这个poll函数也是驱动自己提供的比如rtl8139网卡驱动中的rtl8139_poll等。--在poll函数中进行轮询直到接受完所有的数据或者预算(budget)耗尽。每接收一个报文要分配skb用eth_type_trans处理并交给netif_receive_skb。--如果数据全部接收完(预算没有用完)则重新使能中断并将napi从链表中取下。如果数据没接收完则什么也不作等待下一次poll函数被调度。非NAPI流程中断发生--确定中断发生的原因是接收完毕。分配skb读入数据用eth_type_trans处理并且将skb交给netif_rx--在netif_rx中将packet加入到softnet_data的input_pkt_queue末尾(NAPI驱动不使用这个input_pkt_queue)再通过napi_schedule将softnet_data中的backlog(这也是个napi结构)加入softnet_data的poll_list最后发出软中断--软中断net_rx_action从poll_list上取下softnet_data的backlog调用其poll函数这个poll函数是内核提供的process_backlog--函数process_backlog从softnet_data的input_pkt_queue末尾取下skb并且直接交给netif_receive_skb处理。--如果input_pkt_queue中所有skb都处理完则将backlog从队列中除去(注意input_pkt_queue中可能有多个网卡加入的报文因为它是每cpu公用的)并退出循环;如果预算用完后也跳出循环。最后返回接受到的包数总结NAPI和非NAPI的区别1.NAPI使用中断轮询的方式中断产生之后暂时关闭中断然后轮询接收完所有的数据包接着再开中断。而非NAPI采用纯粹中断的方式一个中断接收一个数据包2.NAPI都有自己的struct napi结构非NAPI没有3.NAPI有自己的poll函数而且接收数据都是在软中断调用poll函数时做的而非NAPI使用公共的process_backlog函数作为其poll函数接收数据是在硬件中断中做的4.NAPI在poll函数中接收完数据之后直接把skb发给netif_receive_skb而非NAPI在硬件中断中接收了数据通过netif_rx把skb挂到公共的input_pkt_queue上最后由软中断调用的process_backlog函数来将其发送给netif_receive_skb驱动以及软中断这块对skb仅仅做了以下简单处理1.调用skb_reserve预留出2个字节的空间这是为了让ip首部对齐因为以太网首部是14字节2.调用skb_put将tail指向数据末尾3.调用eth_type_trans进行如下处理(1)将skb-dev指向接收设备(2)将skb-mac_header指向data(此时data就是指向mac起始地址)(3)调用skb_pull(skb, ETH_HLEN)将skb-data后移14字节指向ip首部(4)通过比较目的mac地址判断包的类型并将skb-pkt_type赋值PACKET_BROADCAST或PACKET_MULTICAST或者PACKET_OTHERHOST因为PACKET_HOST为0所以是默认值(5)最后判断协议类型并返回(大部分情况下直接返回eth首部的protocol字段的值)这个返回值被存在skb-protocol字段中总结结束后skb-data指向ip首部skb-mac_header指向mac首部,skb-protocol储存L3的协议代码skb-pkt_type已被设置skb-len等于接收到的报文长度减去eth首部长度也就是整个ip报文的总长。其余字段基本上还是默认值。netif_receive_skb1.将skb-iif赋值为skb-dev-ifindex将skb-network_header和skb-transport_header都指向skb-data也就是ip首部然后skb-mac_lenskb-gt;network_header-skb-mac_header正常情况下应该等于ETH_HLEN吧2.向ptype_all中注册(通过dev_add_pack)的每一个packet_type调用一次deliver_skb,这里没有拷贝skb只是先增加了一下skb-users3.调用handle_bridge处理桥报文如果该dev不是一个桥端口则直接返回4.调用handle_macvlan处理vlan5.对于每一个在ptype_base中注册的packet_type(也是用dev_add_pack),调用deliver_skb6.如果没有任何一个注册的packet_type接受skb则直接kfree_skb并且返回NET_RX_DROP。否则返回最后一个pkt_type-func返回的值总结需要说一下dev_add_pack这个函数根据传入的packet_type的type字段决定加入哪个队列如果是ETH_P_ALL就加入ptype_all否则计算哈希值并加入ptype_base通过这个函数注册的都是L3层的协议比如ip,arp,rarp,bootp等其实还有packet协议族套接字的监听函数(除了ETH_P_ALL之外都加入ptype_base它们对应的接收函数是packet_rcv)这里对于ip来说接受函数就是ip_rcv。经过这个函数又有几个字段发生变化network_header和transport_header都指向ip首部,mac_len为mac首部长度ip_rcv:1.丢弃所有pkt_type为OTHER_HOST的包注意对于将网卡设为混杂模式的监听进程来说这个包已经在netif_receive_skb中给它们发送了一份拷贝2.检查skb是否被共享如果被共享需要用skb_clone拷贝一份因为后面要对skb的内容进行变更3.常规检测如果报文的长度小于ip首部最小长度丢弃如果ip协议字段不等于4丢弃若ip首部长度字段小于5丢弃若ip首部长度小于ip首部长度字段*4丢弃如果ip首部校验和出错丢弃如果skb-len(此时len为整个ip报文长度)小于ip首部总长字段丢弃如果ip首部总长字段小于ip首部长度字段丢弃4.注意第三步中skb-len是可以小于ip首部的总长字段的因为根据代码注释传输介质有可能在末尾添加了padding在这种情况下会调用pskb_trim_rcsum将多余的结尾部分砍掉(通过把skb-tail往前移)并且还要将检查和无效化5.此处调用NF_INET_PRE_ROUTING钩子函数总结ip_rcv主要进行的常规检查唯一对skb进行操作的就是将结尾的填充字段砍掉。ip_rcv_finish1.首先如果skb-dst为空说明还不确定这个ip报文的目的地是本机还是别的机器这时通过ip_route_input来找到rtable并且赋给skb-rtable2.如果ip首部长度字段大于5则调用ip_rcv_options处理ip选项。该函数调用ip_options_compile将选项全部处理放在skb的cb字段中作为一个structip_options(还要详细看ip_options_compile)。如果有源站路由选项则检查设备是否支持源站路由(软件支持可配置)则调用ip_options_rcv_srr(此函数也还需认真看)填写源站路由。3.添加统计信息并调用dst_inputdst_input只是调用skb-dst-input函数这个skb-dst就是前面用ip_route_input确定的而根据dst类型的不同这个input函数可能是ip_local_deliver或者ip_forward这里我们看ip_local_deliver。总结ip_rcv_finish改变了skb-dst字段(如果本来skb-dst字段已经有值则不改变)和skb-cb字段(在ip_rcv_options中将ip首部选项编译之后放入cb)。ip_options_compile可以改变报文内容比如填写路由记录选项填写时间戳选项等ip_local_deliver1.如果ip首部offset或者MF不为0则调用ip_defrag进行ip分片的重组ip_defrag只在成功完全重组了一个报文之后才会返回0其他情况都是返回非0如果返回非0就会从ip_local_deliver返回。ip_defrag也比较复杂需要细看总体来说就是将分片放在一个哈希表中开启定时器来一个分片就与前面属于同一ip报文的分片合并(两个分片是否属于同一个ip报文是通过ip的id字段源目的地址L4协议等多个参数确定的可参考ip4_frag_match)2.钩子NF_INET_LOCAL_IN并调用ip_local_deliver_finish总结从上两个函数可以看出NF_INET_PRE_ROUTING和NF_INET_LOCAL_IN之间的区别前者还没有经过路由处理即skb-dst一般还没有确定而后者是已经确定了skb-dst且dst为本地地址假如skb-dst不是本地地址则会调用ip_forward这就不会触发NF_INET_LOCAL_IN了。另外NF_INET_PRE_ROUTING尚未对ip分片进行合并处理而NF_INET_LOCAL_IN抓到的数据包是已经合并成的ip报文了ip_local_deliver_finish1.将skb-data继续移动指向传输层首部并且将skb-transport_header也指向传输层首部接下来开始处理2.首先从ip首部取得传输层协议号然后用这个协议号调用raw_local_deliver将skb传给raw_v4_hashinfo哈希表中的原始套接字协议3.再利用protocol值作为下标取得inet_protos全局数组中的注册协议(对于tcp,udp,icmp分别是tcp_protocoludp_protocolicmp_protocol)。如果找到了对应的协议处理结构就把skb交给该结构的handler函数处理(对于tcp,udp,icmp分别是tcp_v4_rcvudp_rcvicmp_rcv)。如果没找到对应的处理结构则回发一个icmp协议不可达的目的不可达报文并释放skb。总结这里又一次移动了skb-data指针将其指向传输层首部同时设置了transport_header也指向传输层首部。raw_v4_hashinfo和inet_protos都是一个256项的全局数组以协议号为下标保存了各个协议的处理结构。这两个数组就像是L4层的ptype_base根据本层的协议号来决定处理函数注意区别raw_v4_hashinfo和上面的ptype_all前者是AF_INET的SOCK_RAW套接字注册的接收结构而后者是AF_PACKET套接字注册的接收结构可见raw套接字是经过了ip层处理的而packet是在netif_receive_skb中接收的尚未经过任何处理其中一个显著区别就是raw经过了ip_defrag而packet没有对于udp来说inet_protos中的结构是全局变量udp_protocol它的handler函数是udp_rcvudp_rcv所做的就是直接调用__udp4_lib_rcv(skb, udp_hash, IPPROTO_UDP);__udp4_lib_rcv此函数中会调用__udp4_lib_lookup_skb--()__udp4_lib_lookup()来查找此udp包对应的socket主要是查找源目的地址和端口号都符合的socket。如果查找到了对应的socket则调用udp_queue_rcv_skb将skb放入udp的接收队列然后返回0如果没有查找到对应的socket要向源地址发送一个ICMP端口不可达消息udp_queue_rcv_skb它经过__udp_queue_rcv_skb(sk,skb)--__udp_queue_rcv_skb--skb_queue_tail一系列调用过程将skb加入socket的接收队列sk-sk_receive_queuek末尾。其中还要检测接收缓冲区是否已经满。接着调用sk-sk_data_ready(sk, skb_len)通知socket有数据就绪可以读了。一般情况下这个函数对应sock_def_readable这个函数的功能就是唤醒在sk-sk_sleep上睡眠的进程那么是谁在这里睡眠呢在调用recvfrom系统调用接收报文的时候会经过这样一个流程sys_socketcall--sys_recvfrom--sock_recvmsg--__sock_recvmsg--sock-ops-recvmsg这个sock-ops对应全局变量inet_dgram_ops里面的recvmsg对应sock_common_recvmsg--sock_common_recvmsg--sk-sk_prot-recvmsg这个sk-sk_prot对应全局变量udp_prot里面的recvmsg对应udp_recvmsg--udp_recvmsg--__skb_recv_datagram在__skb_recv_datagram中会首先尝试从sk-sk_receive_queue上取下数据包如果发现队列中没有数据包则开始在sk-sk_skeep上睡眠。而上面sock_def_readable唤醒的就是这里睡眠的进程。可以看到在__skb_recv_datagram中被唤醒后函数又尝试从sk-sk_receive_queue上取下数据包这时当然会成功成功之后返回到udp_recvmsg。udp_recvmsg再进行一些简单的检测之后就调用copy_to_user将数据拷贝到用户空间了(其实这里并不是简单调用copy_to_user还要处理很多情况比如用户使用的msghdr可能包含多个iovecskb可能有多个frags等等)这样一个udp数据包就从网卡到达了用户的缓冲区阅读(713) | 评论(0) | 转发(0) |