分析数据在协议栈底层的流程

分析数据在协议栈底层的流程:  

    

   当网卡收到数据后，产生硬件中断，由中断处理程序（一般为网卡驱动程序所注册）从网卡内读取数据，并封装称sk_buff{}结构，然后把这些数据传递给函数netif_rx（）进行进一步的处理。  
          函数netif_rx（）根据当前接收队列的拥挤情况，选择丢弃还是接收，如果是接收，则将接收到的sk_buff{}挂到接收队列softnet_data[CPU]->input_pkt_queue上，并调用函数__cpu_raise_softirq（）激活软中断NET_RX_SOFTIRQ，相应的处理函数是net_rx_action（）。  
          在函数net_rx_action（）中根据数据包的协议类型，调用相应的处理函数。对于IP包，处理函数是ip_rcv（）。  
          函数ip_rcv（）对IP包进行了一系列必要的检查（包括检查校验和），最终调用函数ip_rcv_finish（）对数据包进行向上传输。  
          函数ip_rcv_finish（）首先调用函数ip_route_input（）获取路由，检测该包是发给本机的还是要进行转发的，如果要进行转发，则调用调用函数ip_forward（）进行转发，否则调用函数ip_local_deliver（）进一步向上传递数据包。  
          函数ip_local_deliver（）首先进行了防火墙的过滤工作，最终调用函数ip_local_deliver_finish（）向上传递数据。  
          在函数ip_local_deliver_finish（）中，会检查是否有匹配协议（如根据IP头判断我们的数据包是TCP包，则要判断是否有接收TCP包的原始套接口。当然，如果有接收所有IP包的原始套接口存在也是可以的）的原始套接口。如果有，则调用函数raw_v4_input（）进行处理。  
          在函数raw_v4_input（）中，要进一步进行匹配，这次匹配的依据有四个，依次是：协议、源地址、目的地址和接收接口。分别对每一个匹配成功的原始套接口调用函数raw_rcv（）传递一个克隆的以sk_buff{}为结构的数据包。  
          接下来的几个函数都很简单，调用顺序依次是raw_rcv（）、raw_rcv_skb（）和sock_queue_rcv_skb（）。这几个函数基本上都是简单的依次调用关系。最后调用函数sock_queue_rcv_skb（），该函数经过skb_queue_tail（）函数将数据包sk_buff{}放入了接收队列sk->receive_queue的末尾。  
           
7．原始套接口的协议栈实现――原始套接口的绑定  
   
          这里我们简略分析，对原始套接口绑定调用的是函数sk->prot->bind，在原始套接口的创建中我们给出了套接口的sk->prot即struct   proto   结构变量raw_prot，从中可以看出和sk->prot->bind指针实质指向函数raw_bind（）。  
           
          在这个函数中首先判断套接口状态，如果是TCP_CLOSE的话，就退出。然后有对参数进行了一些常规检查。同时，如果发现要绑定的地址是广播或多播的话，也会退出。如果通过了这些检查，就进行一些赋值操作，将用户要绑定的地址赋值到sk->rcv_saddr和sk->saddr中，即：  
          sk->rcv_saddr   =   sk->saddr   =   addr->sin_addr.s_addr  
          然后会正常退出。  
          注意，这里没有对端口做任何操作，即使用户指定了要绑定的端口，内核也不予理睬。  
   
8．原始套接口的协议栈实现――原始套接口的连接  
   
          从原始套接口的创建一节中给出的struct   proto   结构可以看出，原始套接口的连接其实调用的是函数udp_connect（），好兴奋，终于见到了不那么"原始"的东西了。  
           
          在这个函数中，首先对用户的参数进行了一些检查。当然，它也检查了用户指定的网域是否是"AF_INET"，如果不是，会返回一个EAFNOSUPPORT错误。  
然后，该函数调用了函数ip_route_connect（）来获取一个到目的地址的路由，如果失败，也会返回错误。  
接下来的工作看起来就有点令人难以理解。  
它检查了套接口是否指定了源地址，如果没有指定，则将寻找到的路由的源地址赋值给这个套接口的源地址，即：  
   
              if(!sk->saddr)  
                      sk->saddr   =   rt->rt_src;                 /*   Update   source   address   */  
          if(!sk->rcv_saddr)  
                  sk->rcv_saddr   =   rt->rt_src;  
                   
其中sk代表我们套接口的sock{}结构，rt代表我们找到的路由，是一个struct   rtable{}结构。  
          最后，就是将目的地址和目的端口赋值到我们的套接口的指定字段中，同时更新套接口状态，即：  
           
                  sk->daddr   =   rt->rt_dst;  
                  sk->dport   =   usin->sin_port;  
                  sk->state   =   TCP_ESTABLISHED;          
   
9．原始套接口的协议栈实现――原始套接口的关闭  
   
          根据上面的经验，原始套接口的关闭应该调用函数raw_close（），这个函数只是简单的调用了函数ip_ra_control（），在函数ip_ra_control（）中，将该套接口从链表ip_ra_chain中删除，然后释放到该套接口占用的所有空间。 

10．原始套接口的应用  
   
          根据前面的分析，针对原始套接口的应用，我们可以得出以下结论。  
   
10.1   绑定的问题  
   
可以对原始套接口调用bind函数，但并不常用。该函数仅用来设置本地地址。对于一个原始套接口而言，端口号是没有意义的。当进行输出的时候，bind设置在原始套接口上所发送的数据报中将要用到的源IP地址（仅当IP_HDRINCL套接口选项未设置时）；若不调用bind，则由内核将源IP地址设成外出接口的主IP地址。  
   
10.2   连接的问题  
   
在原始套接口上可调用connect函数，但也不常用。connect函数仅设置目的地址。再重申一遍：端口号对原始套接口而言没有意义。对于输出而言，调用connect之后，由于目的地址已经指定，我们可以调用write或send，而不是sendto了。  
   
10.3   输出的问题  
   
1）普通输出通常通过sendto或sendmsg并指定目的IP地址来完成，如果套接口已经连接，也可以调用write、writev或send。  
2）如果IP_HDRINCL选项未设置，则内核写的数据起始地址是IP头部之后的第一个字节。因为这种情况下，内核将构造IP头部，并将它安在来自进程数据之前。内核将IPv4头部的协议字段设置成用户在调用socket函数时所给的第三个参数。  
3）如果IP_HDRINCL选项已设置，则内核写的数据其实地址是IP头部的第一个字节。用户所提供的数据必须包括IP头部。此时进程构造除了以下两项以外的整个IP头部：  
(1)IPv4标示字段可以设为0，要求内核设置该值。而且仅当该字段为0时，内核才为其设置。          
(2)IPv4头部校验和由内核来计算和存储。  
4）如果创建原始套接口时指定了协议类型，即第三个参数protocol，那也并不是说只能发该类型的数据包。如，即使将protocol指定为IPPROTO_TCP，也可以发送用户自己组装的UDP报文，不过此时如果IP_HDRINCL选项未设置，那么内核将会在IP头的协议字段指明后面的报文为TCP报文（不过此时却为UDP报文）。等数据包发送到对方TCP层，一般说来会因为找不到合适的TCP套接口接收该数据包而被丢弃。不过该包可以在目标主机的原始套接口上接收到。  
5）正如前面所述，任何时候，IP头的校验和都是由内核来设置的。  
6）内核任何时候那会都不会对IP包以后的字段进行校验和验证。如，即使我们指定第三个参数protocol为IPPROTO_TCP，在数据发送时内核也不会对进行TCP校验和计算和验证。  
7）如果IP_HDRINCL选项已设置，按照常规，我们应该组建自己的IP头，但是即使我们没有组建IP头，用sendto或sendmsg并指定目的IP地址来发送数据是照样可以完成的。但是这样的数据包在目标机上用原始套接口是接收不到的，因为在ip_rcv（）中要对IP头进行验证，并且要分析校验和，所以该包会被丢弃，不过在链路层应该能够接收到该数据包。  
8）如果设置了IP_HDRINCL选项，并且数据包超长，那么数据会被丢弃，并会返回出错码EMSGSIZE。如果未设置IP_HDRINCL选项，并且数据包超长，那么数据包会被分片。  
   
10.4输入的问题  
   
1）原始套接口可以接收到任何TCP或UDP报文。  
2）要想接收到原始套接口，首先要接收的数据包必须有一个完整的、正确的IP头，否则不能通过ip_rcv（）中的包头检查和检验和验证。  
3）在原始套接口接收的数据包过程中，内核会对接收的IP包进行校验和验证，但不会对IP包以后的任何字段进行检测和验证。如，我们创建原始套接口时，所指定的protocol参数为IPPROTO_TCP，内核也不会进行TCP校验和验证，而是直接把IP头中协议字段为TCP的所有数据包都复制一份，提交给该原始套接口。  
4）用原始套接口接收到的TCP包都是进行了IP重组以后，TCP排序以前的报文。  
5）如果在创建原始套接口时，所指定的protocol参数不为零，（socket的第三个参数），则接收到的数据报的协议字段应该与之匹配。否则该数据报不传递给该套接口。  
6）如果此原始套接口上绑定了一个本地IP地址，那么接收到的数据报的目的IP地址应该与该绑定的IP地址相匹配，否则该数据包将不传递到该套接口。  
7）如果此原始套接口通过connect指定了一个对方IP地址，那么接收到的数据包的源IP地址应与该以连接地址相匹配，否则该数据包不传递给该套接口。  
8）如果一个原始套接口以protocol参数为0的方式创建，并且未调用connect或bind，那么对于内核传递给原始套接口的每一个原始数据报，该套接口都会收到一份拷贝。  
9）原始套接口接收不到任何的ARP或RARP协议类型的套接口，因为net_rx_action()  
会把ARP或RARP协议类型的数据包传递给ARP的接收函数类处理，不会传递给IP层的接收函数ip_rcv（）。  
10）原始套接口并不是可以接收到任何的ICMP类型的数据包，因为有些ICMP类型的数据包在传递给原始套接口之前已经被系统所响应，并不再向上层传递。  
11）如果对方的数据包分片了，由于原始套接口的接收是在IP上层，所以会接收到重组以后的原始IP包。  
   
   
附录：  
协议类型（在netinet/in.h中定义）：  
   
   
          IPPROTO_IP   =   0,                                     /*   Dummy   protocol   for   TCP.     */  
          IPPROTO_HOPOPTS   =   0,                       /*   IPv6   Hop-by-Hop   options.     */  
          IPPROTO_ICMP   =   1,                                     /*   Internet   Control   Message   Protocol.     */  
          IPPROTO_IGMP   =   2,                                   /*   Internet   Group   Management   Protocol.   */  
          IPPROTO_IPIP   =   4,                                     /*   IPIP   tunnels   (older   KA9Q   tunnels   use   94).     */  
          IPPROTO_TCP   =   6,                                       /*   Transmission   Control   Protocol.     */  
          IPPROTO_EGP   =   8,                                       /*   Exterior   Gateway   Protocol.     */  
          IPPROTO_PUP   =   12,                                     /*   PUP   protocol.     */  
          IPPROTO_UDP   =   17,                                     /*   User   Datagram   Protocol.     */  
          IPPROTO_IDP   =   22,                                     /*   XNS   IDP   protocol.     */  
          IPPROTO_TP   =   29,                                       /*   SO   Transport   Protocol   Class   4.     */  
          IPPROTO_IPV6   =   41,                                   /*   IPv6   header.     */  
          IPPROTO_ROUTING   =   43,                           /*   IPv6   routing   header.     */  
          IPPROTO_FRAGMENT   =   44,                   /*   IPv6   fragmentation   header.     */  
          IPPROTO_RSVP   =   46,                                 /*   Reservation   Protocol.     */  
          IPPROTO_GRE   =   47,                                     /*   General   Routing   Encapsulation.     */  
          IPPROTO_ESP   =   50,                                     /*   encapsulating   security   payload.     */  
          IPPROTO_AH   =   51,                                       /*   authentication   header.     */  
          IPPROTO_ICMPV6   =   58,                               /*   ICMPv6.     */  
          IPPROTO_NONE   =   59,                           /*   IPv6   no   next   header.     */  
          IPPROTO_DSTOPTS   =   60,                     /*   IPv6   destination   options.     */  
          IPPROTO_MTP   =   92,                                     /*   Multicast   Transport   Protocol.     */  
          IPPROTO_ENCAP   =   98,                         /*   Encapsulation   Header.     */  
          IPPROTO_PIM   =   103,                                   /*   Protocol   Independent   Multicast.     */  
          IPPROTO_COMP   =   108,                         /*   Compression   Header   Protocol.     */  
          IPPROTO_RAW   =   255,                           /*   Raw   IP   packets.     */