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、状态相关协议处理结构

一个报文的产生和发送，都需要硬件和软件的完美配合。

硬件层面接收到报文之后，做一系列的初始化 *** 作，之后驱动才开始把一个封包封装为skb。

当然这是在x86架构下，如果是在cavium架构下，封包是wqe形式存在。

不管是skb还是wqe，都仅仅是一种手段，一种达到完成报文传输所采用的一种解决方案，一种方法而已。

或许处理方案的具体实现细节差别万千，但是基本的原理，都是殊途同归，万变不离其宗。

skb的产生，让Linux协议栈旅程的开启，具备了最基本的条件，接下来的协议栈之旅，才会更加精彩。

写作本文的原因是现在本机网络 IO 应用非常广。

在 php 中 一般 nginx 和 php-fpm 是通过 127.0.0.1 来进行通信的；

在微服务中，由于 side car 模式的应用，本机网络请求更是越来越多。

所以，如果能深度理解这个问题在各种网络通信应用的技术实践中将非常的有意义。

今天咱们就把 127.0.0.1 本机网络通信相关问题搞搞清楚！

为了方便讨论，我把这个问题拆分成3问：

1）127.0.0.1 本机网络 IO 需要经过网卡吗？

2）和外网网络通信相比，在内核收发流程上有啥差别？

3）使用 127.0.0.1 能比 192.168.x.x 更快吗？

在上面这幅图中，我们看到用户数据被拷贝到内核态，然后经过协议栈处理后进入到了 RingBuffer 中。随后网卡驱动真正将数据发送了出去。当发送完成的时候，是通过硬中断来通知 CPU，然后清理 RingBuffer。

当数据包到达另外一台机器的时候，Linux 数据包的接收过程开始了。

当网卡收到数据以后，CPU发起一个中断，以通知 CPU 有数据到达。

当CPU收到中断请求后，会去调用网络驱动注册的中断处理函数，触发软中断。

ksoftirqd 检测到有软中断请求到达，开始轮询收包，收到后交由各级协议栈处理。

当协议栈处理完并把数据放到接收队列的之后，唤醒用户进程（假设是阻塞方式）。

关于跨机网络通信的理解，可以通俗地用下面这张图来总结一下：

前面，我们看到了跨机时整个网络数据的发送过程 。

在本机网络 IO 的过程中，流程会有一些差别。

为了突出重点，本节将不再介绍整体流程，而是只介绍和跨机逻辑不同的地方。

有差异的地方总共有两个，分别是路由和驱动程序。

对于本机网络 IO 来说，特殊之处在于在 local 路由表中就能找到路由项，对应的设备都将使用 loopback 网卡，也就是我们常见的 lO。

从上述结果可以看出，对于目的是 127.0.0.1 的路由在 local 路由表中就能够找到了。

对于是本机的网络请求，设备将全部都使用 lo 虚拟网卡，接下来的网络层仍然和跨机网络 IO 一样。

本机网络 IO 需要进行 IP 分片吗？

因为和正常的网络层处理过程一样，如果 skb 大于 MTU 的话，仍然会进行分片。

只不过 lo 的 MTU 比 Ethernet 要大很多。

通过 ifconfig 命令就可以查到，普通网卡一般为 1500，而 lO 虚拟接口能有 65535。

为什么我把“驱动”加个引号呢，因为 loopback 是一个纯软件性质的虚拟接口，并没有真正意义上的驱动。

在邻居子系统函数中经过处理，进入到网络设备子系统，只有触发完软中断，发送过程就算是完成了。

在跨机的网络包的接收过程中，需要经过硬中断，然后才能触发软中断。

而在本机的网络 IO 过程中，由于并不真的过网卡，所以网卡实际传输，硬中断就都省去了。直接从软中断开始，送进协议栈。

网络再往后依次是传输层，最后唤醒用户进程，这里就不多展开了。

我们来总结一下本机网络通信的内核执行流程：

回想下跨机网络 IO 的流程：

通过本文的叙述，我们确定地得出结论，不需要经过网卡。即使了把网卡拔了本机网络是否还可以正常使用的。

总的来说，本机网络 IO 和跨机 IO 比较起来，确实是节约了一些开销。发送数据不需要进 RingBuffer 的驱动队列，直接把 skb 传给接收协议栈（经过软中断）。

但是在内核其它组件上可是一点都没少：系统调用、协议栈（传输层、网络层等）、网络设备子系统、邻居子系统整个走了一个遍。连“驱动”程序都走了（虽然对于回环设备来说只是一个纯软件的虚拟出来的东东）。所以即使是本机网络 IO，也别误以为没啥开销。

先说结论：我认为这两种使用方法在性能上没有啥差别。

我觉得有相当大一部分人都会认为访问本机server 的话，用 127.0.0.1 更快。原因是直觉上认为访问 IP 就会经过网卡。

其实内核知道本机上所有的 IP，只要发现目的地址是本机 IP 就可以全走 loopback 回环设备了。

本机其它 IP 和 127.0.0.1 一样，也是不用过物理网卡的，所以访问它们性能开销基本一样！

How SKBs work - Linux kernel

http://vger.kernel.org/~davem/skb.html

一篇解读Linux网络协议栈

https://zhuanlan.zhihu.com/p/475319464

你真的了解127.0.0.1和0.0.0.0的区别？

http://www.52im.net/thread-2928-1-1.html

深入 *** 作系统，彻底搞懂127.0.0.1本机网络通信

http://www.52im.net/thread-3590-1-1.html

---