【理解 Cilium 系列文章】(二) 理解网络数据包的流转过程

Cilium 作为近两年最火的云原生网络方案，可谓是风头无两。作为第一个通过 ebpf 实现了 kube-proxy 所有功能的网络插件，它的神秘面纱究竟是怎样的呢？本系列文章将带大家一起来慢慢揭晓

作为《理解 Cilium系列文章》的第二篇，本文主要介绍 Cilium 网络相关知识点，为后续 Cilium 的深入了解做铺垫。了解 Cilium 是如何在网络流转的路径中做拦截处理的

之前的两篇文章【25 张图，一万字，拆解 Linux 网络包发送过程】和【图解Linux网络包接收过程】主要从源码层次介绍了 Linux 网络收发包的流程，感兴趣的同学可以看一下，读完上述两篇再看本篇将会更轻松 。

1. 网络分层的宏观视角

想必大家都应该准备过这样一道面试题 从输入 URL 到收到请求响应，中间发生了什么事情 。

这个问题如果往复杂了讲，恐怕讲个一天一夜也讲不完。此处咱们长话短说，简要描述下大体流程，先建立个宏观视角。

先复习下网络分层模型

如下 左图 为 OSI 的标准七层 网络模型，这套模型只是停留在概念上的，因为实现起来太复杂了。右边是业界标准的 TCP/IP 模型，Linux 系统中正是按照 TCP/IP 模型开发的网络协议栈。

接下来回到上文的问题 从输入 URL 到收到请求响应，中间发生了什么事情

此处简要描述下流程，限于篇幅不一一展开了，当然如果小伙伴对其中某些知识点感兴趣的话，可以自行搜索相关材料继续深入研究。

1. 客户端发起网络请求，用户态的应用程序（浏览器）会生成 HTTP 请求报文、并通过 DNS 协议查找到对应的远端 IP 地址。

2. 用户态的应用程序（浏览器) 会委托操作系统内核协议栈中的上半部分，也就是 TCP/UDP 协议发起连接请求。此处封装 TCP 头(或 UDP 头)

3. 然后经由协议栈下半部分的 IP 协议进行封装，然后交给下层协议。此处封装 IP 头

4. 经过 MAC 层处理，找到接收方的目标 MAC 地址。此处封装 MAC 头。

5. 最终数据包在经过网卡转化成电信号经过交换机、路由器发送到服务端，服务端经过处理拿到数据，再通过各种网络协议依次把封装的头解封装，把数据响应给客户端。

6. 客户端拿到数据进行渲染。

2. Linux 网络协议栈

上面讲述了网络分层原理以及各层的封包解包流程，下面介绍下 Linux 网络协议栈，其实 Linux 网络协议栈就类似于 TCP/IP 的四层结构：

通过上图可以看到：

• 应用程序需要通过系统调用，来跟 Socket 层进行数据交互；

• Socket 层的下面就是传输层、网络层和网络接口层；

• 最下面的一层，则是网卡驱动程序和硬件网卡设备；

3. Linux 接收网络包的流程

同样的，先来个宏观视角，然后再一一介绍，避免一开始就陷入细节无法自拔

图片取自《你不好奇 Linux 网络发包过程吗？》[1]

可以看到上图比之前介绍的网络封包解包相比，多了下面网卡相关的内容。是的，因为咱们要介绍的是 Cilium 相关的网络基础，所以需要了解 数据包是如何穿过 network datapath 的：包括从硬件到 内核，再到用户空间。图中有 Cilium logo 的地方，都是 datapath 上 Cilium 重度使用 BPF 程序的地方。

参考 【[译] 深入理解 Cilium 的 eBPF 收发包路径（datapath）（KubeCon, 2019）】[2]

下面将分层 介绍：

3.1 L1 -> L2（物理层 -> 数据链路层）

网卡收包简要流程：

1. 网卡驱动初始化。

2. 网卡获得一块物理内存，作用收发包的缓冲区（ring-buffer）。这种方式称为 DMA（直接内存访问）。

3. 驱动向内核 NAPI（New API）注册一个轮询（poll ）方法。

4. 网卡从网络中收到一个包，通过 DMA 方式将包放到 Ring Buffer，这是一个环形缓冲区。

5. 如果此时 NAPI 没有在执行，网卡就会触发一个硬件中断（HW IRQ），告诉处理器 DMA 区域中有包等待处理。

6. 收到硬中断信号后，处理器开始执行 NAPI。

7. NAPI 执行网卡注册的 poll 方法开始收包。

关于 NAPI poll 机制：