Linux网络 - 数据包在内核中接收和发送的过程（转）

本文将介绍在Linux系统中， 数据包是如何一步一步从网卡传到进程手中的 以及 数据包是如何一步一步从应用程序到网卡并最终发送出去的 。

如果英文没有问题，强烈建议阅读后面参考里的文章，里面介绍的更详细。

本文只讨论以太网的物理网卡，不涉及虚拟设备，并且以一个UDP包的接收过程作为示例.

网卡需要有驱动才能工作，驱动是加载到内核中的模块，负责衔接网卡和内核的网络模块，驱动在加载的时候将自己注册进网络模块，当相应的网卡收到数据包时，网络模块会调用相应的驱动程序处理数据。

下图展示了数据包（packet）如何进入内存，并被内核的网络模块开始处理：

软中断会触发内核网络模块中的软中断处理函数，后续流程如下

由于是UDP包，所以第一步会进入IP层，然后一级一级的函数往下调：

应用层一般有两种方式接收数据，一种是recvfrom函数阻塞在那里等着数据来，这种情况下当socket收到通知后，recvfrom就会被唤醒，然后读取接收队列的数据；另一种是通过epoll或者select监听相应的socket，当收到通知后，再调用recvfrom函数去读取接收队列的数据。两种情况都能正常的接收到相应的数据包。

了解数据包的接收流程有助于帮助我们搞清楚我们可以在哪些地方监控和修改数据包，哪些情况下数据包可能被丢弃，为我们处理网络问题提供了一些参考，同时了解netfilter中相应钩子的位置，对于了解iptables的用法有一定的帮助，同时也会帮助我们后续更好的理解Linux下的网络虚拟设备。

ndo_start_xmit会绑定到具体网卡驱动的相应函数，到这步之后，就归网卡驱动管了，不同的网卡驱动有不同的处理方式，这里不做详细介绍，其大概流程如下：

在网卡驱动发送数据包过程中，会有一些地方需要和netdevice子系统打交道，比如网卡的队列满了，需要告诉上层不要再发了，等队列有空闲的时候，再通知上层接着发数据。

流程路径：ip_rcv() -->ip_rcv_finish() -->ip_local_deliver() --> ip_local_deliver_finish()

解封侧一定是ip报文的目的端，ip_rcv_finish中查到的路由肯定是本机路由（RTCF_LOCAL），调用 ip_local_deliver 处理。

下面是贴的网上的一张图片。

ip_local_deliver_finish中 根据上次协议类型，调用对应的处理函数。inet_protos 中挂载了各类协议的 *** 作集，对于AH或者ESP来说，是xfrm4_rcv，对于ipsec nat-t情况下，是udp协议的处理函数udp_rcv，内部才是封装的ipsec报文（AH或者ESP）。

xfrm4_rcv -->xfrm4_rcv_spi -->xfrm4_rcv_encap -->xfrm_input

最终调用 xfrm_input 做收包解封装流程。

1、创建SKB的安全路径；

2、解析报文，获取daddr、spi，加上协议类型（esp、ah等），就可以查询到SA了，这些是SA的key，下面列出了一组linux ipsec的state（sa）和policy，方便一眼就能看到关键信息；

3、调用SA对应协议类型的input函数，解包，并返回更上层的协议类型，type可为esp,ah,ipcomp等。对应的处理函数esp_input、ah_input等；

4、解码完成后，再根据ipsec的模式做解封处理，常用的有隧道模式和传输模式。对应xfrm4_mode_tunnel_input 和 xfrm4_transport_inout，处理都比较简单，隧道模式去掉外层头，传输模式只是设置一些skb的数据。

5、协议类型可以多层封装，如ESP+AH，所以需要再次解析内存协议，如果还是AH、ESP、COMP，则解析新的spi，返回2，查询新的SA处理报文。

6、经过上面流程处理，漏出了用户数据报文（IP报文），根据ipsec模式：

流程路径如下图，这里以转发流程为例，本机发送的包主要流程类似。

转发流程：

ip_forward 函数中调用xfrm4_route_forward，这个函数：

1、解析用户报文，查找对应的Ipsec policy（__xfrm_policy_lookup）；

2、再根据policy的模版tmpl查找对应最优的SA（xfrm_tmpl_resolve），模版的内容以及和SA的对应关系见上面贴出的ip xfrm命令显示；

3、最后根据SA生成安全路由，挂载再skb的dst上； 一条用户流可以声明多个安全策略（policy），所以会对应多个SA，每个SA处理会生成一个安全路由项struct dst_entry结构（xfrm_resolve_and_create_bundle），这些安全路由项通过 child 指针链接为一个链表，其成员 output挂载了不同安全协议的处理函数，这样就可以对数据包进行连续的处理，比如先压缩，再ESP封装，再AH封装。

安全路由链的最后一个路由项一定是普通IP路由项，因为最终报文都得走普通路由转发出去，如果是隧道模式，在tunnel output封装完完成ip头后还会再查一次路由挂载到安全路由链的最后一个。

注： SA安全联盟是IPsec的基础，也是IPsec的本质。 SA是通信对等体间对某些要素的约定，例如使用哪种协议、协议的 *** 作模式、加密算法、特定流中保护数据的共享密钥以及SA的生存周期等。

然后，经过FORWARD点后，调用ip_forward_finish()-->dst_output，最终调用skb_dst(skb)->output(skb)，此时挂载的xfrm4_output

本机发送流程简单记录一下，和转发流程殊途同归：

查询安全路由： ip_queue_xmit -->ip_route_output_flow -->__xfrm_lookup

封装发送：ip_queue_xmit -->ip_local_out -->dst_output -->xfrm4_output

注：

1). 无论转发还是本地发送，在查询安全路由之前都会查一次普通路由，如果查不到，报文丢弃，但这条路由不一定需要指向真实的下一跳的出接口，只要能匹配到报文DIP即可，如配置一跳其它接口的defualt。

2). strongswan是一款用的比较多的ipsec开源软件，协商完成后可以看到其创建了220 table，经常有人问里面的路由有啥用、为什么有时有有时无。这里做个测试记录： 1、220中貌似只有在tunnel模式且感兴趣流是本机发起（本机配置感兴趣流IP地址）的时候才会配置感兴趣流相关的路由，路由指定了source；2、不配置也没有关系，如1）中所说，只要存在感兴趣流的路由即可，只不过ping的时候需要指定source，否者可能匹配不到感兴趣流。所以感觉220这个表一是为了保证

ipsec封装发送流程：

xfrm4_output-->xfrm4_output_finish-->xfrm_output-->xfrm_output2-->xfrm_output_resume-->xfrm_output_one

xfrm4_output 函数先过POSTROUTING点，在封装之前可以先做SNAT。后面则调用xfrm_output_resume-->xfrm_output_one 做IPSEC封装最终走普通路由走IP发送。

贴一些网上的几张数据结构图

1、安全路由

2、策略相关协议处理结构

3、状态相关协议处理结构

---