拆解Linux网络包收发全流程:eBPF和Cilium究竟在哪里“插了一脚”?

前言

当你在浏览器里打开一个网页，或者在服务器上调用send()发送数据，Linux内核究竟在背后默默做了哪些工作？

更关键的是，eBPF这项被誉为“内核革命”的技术，到底是在哪个环节介入的？而基于eBPF的明星项目Cilium，又是如何系统化地利用这些钩子点，重新定义了云原生网络？

今天这篇文章，我们就顺着数据包的流动路径，把收包、发包、eBPF介入、Cilium落地这几个问题一次性讲透。

一、收包流程：从网卡到应用程序

我们先从数据包接收的过程开始。当网卡从物理线路上收到一个网络包，它需要经过一系列步骤才能最终到达应用程序手中。

第一步：硬件接收与DMA

网卡（NIC）接收到传送的帧后，根据驱动程序配置，会通过DMA（直接内存访问） 技术将数据包拷贝到预先分配好的内存区域——也就是Ring Buffer（环形缓冲区） 中。这一步不需要CPU参与，大大提高了效率。

第二步：硬中断通知CPU

数据写入Ring Buffer后，网卡会触发一个硬中断（Hard IRQ） ，通知CPU“有新包来了”。硬中断的处理非常“快”：它只做最精简的工作，比如记录“有包待处理”，然后立刻结束，避免长时间占用CPU。

第三步：软中断与NAPI轮询

硬中断结束后，会触发软中断（Soft IRQ） ——具体来说是NET_RX_SOFTIRQ，由内核线程ksoftirqd负责处理。这才是接收流程的核心环节。

现代Linux内核使用NAPI（New API） 机制来处理收包：它采用“中断 + 轮询”的方式，一次中断后持续轮询处理完所有待处理的包，从而大大减少中断数量，提升效率。

在软中断处理函数net_rx_action中，内核会遍历poll_list，调用网卡驱动注册的poll函数（如ixgb_clean），从Ring Buffer中取出数据包。

第四步：sk_buff与进入协议栈

驱动从Ring Buffer中取出数据后，会将其封装成内核网络包的标准数据结构——sk_buff（套接字缓冲区） 。随后调用netif_receive_skb，数据包正式进入内核网络协议栈。

接下来的调用链是：netif_receive_skb → netif_receive_skb_internal → __netif_receive_skb → __netif_receive_skb_core。

在__netif_receive_skb_core中，内核会处理二层（链路层）的逻辑（如VLAN处理），然后根据协议类型将包交给三层（网络层）处理。随后依次经过IP层、传输层（TCP/UDP），最终数据被放入对应socket的接收队列，等待应用程序通过recvfrom或read等系统调用读取。

二、发送流程：从应用程序到网卡

发送流程基本上是接收的逆过程，但同样值得仔细拆解。

第一步：系统调用与sk_buff封装

当应用程序调用send()或write()时，会触发系统调用，从用户态切换到内核态。Socket层将应用数据封装成sk_buff——内核中承载网络包的“快递箱”。

第二步：逐层添加协议头

接下来，sk_buff依次经过各层协议栈：

• 传输层（TCP/UDP）：添加TCP或UDP头部（端口、序号等）

• 网络层（IP）：添加IP头部（源IP、目的IP），并进行路由决策

• 链路层（以太网）：添加以太网头部（源MAC、目的MAC），通过ARP查询下一跳MAC地址

Linux网络栈高效的关键之一，是整个过程只移动指针、不拷贝数据，利用sk_buff中预留的头部空间来完成各层封装。

第三步：入队与网卡发送

经过协议栈处理后，sk_buff被放入网卡的发送Ring Buffer（传输队列） 中。随后网卡驱动将sk_buff中的二进制数据转换为电信号/光信号，通过网卡硬件发送到物理网络中。

第四步：发送完成中断

数据发送完毕后，网卡会触发一个硬中断通知CPU。有趣的是，发送完成触发的软中断是NET_RX_SOFTIRQ，而不是NET_TX_SOFTIRQ ——这就是为什么你在/proc/softirqs中看到NET_RX远大于NET_TX的原因。

三、eBPF在哪个阶段介入？六大钩子点全拆解

理解了完整的收发包流程，eBPF的介入位置就一目了然了。eBPF程序是事件驱动的，当内核执行到特定的钩子点（hook） 时，挂载在该点的eBPF程序就会被触发执行。

在网络数据包处理中，eBPF主要可以在以下几个阶段介入：

钩子点一：XDP——最早、最快的介入点

XDP是eBPF在网络处理中位置最靠前的钩子点，它位于网卡驱动层面，甚至在sk_buff结构分配之前。

具体来说，XDP程序在网卡驱动的软中断处理过程中被调用，此时数据包还躺在DMA缓冲区中，尚未被封装成sk_buff。XDP程序可以执行以下操作：

• XDP_DROP：直接丢弃数据包（对DDoS防御非常有效）

• XDP_PASS：放行，让数据包进入后续协议栈

• XDP_TX：从同一网卡原路转发回去

• XDP_REDIRECT：重定向到其他网卡、CPU或用户态

由于介入极早，XDP的性能非常惊人，可以达到24Mpps/core的包处理能力。

钩子点二：TC（Traffic Control）——流量控制与排队

TC是另一个重要的eBPF挂载点，它在内核协议栈的流量控制子系统中工作。

与XDP不同，TC程序运行在协议栈通用层，不需要网卡驱动做任何改动。TC程序可以挂载在ingress（入站） 和egress（出站） 两个方向，并且可以访问完整的sk_buff结构，读取其中的协议、napi_id等元数据。

TC适用于需要更复杂策略的场景，比如流量采样、带宽限制、隧道封装等。

钩子点三：协议栈内部的跟踪点与kprobe

除了XDP和TC这两个专用的网络钩子，eBPF还可以通过tracepoint和kprobe挂载到内核网络协议栈的任意函数入口或出口。

这意味着你可以在收发包路径的几乎任何一个环节插入eBPF程序——比如在IP层接收函数ip_rcv、TCP层处理函数等位置进行观测或干预。

钩子点四：Socket层与套接字

eBPF还可以挂载到socket层面，比如通过BPF_PROG_TYPE_SK_LOOKUP等在套接字查找、分发等环节介入。使用sockmap和sk_redirect，甚至可以做到真正不走协议栈的数据包转发。

四、Cilium：eBPF网络能力的集大成者

聊完了eBPF的各个钩子点，就不得不提Cilium这个项目。Cilium是一个基于eBPF构建的云原生网络、安全和可观测性开源项目。如果说eBPF是一把手术刀，Cilium就是用这把手术刀做出来的完整手术方案。

Cilium如何利用这些eBPF钩子？

Cilium在Linux内核的网络栈中支持挂载多个BPF钩子，通过组合使用这些钩子来创建高级别的网络结构。具体来说：

在XDP层：Cilium利用XDP实现高性能的负载均衡和包过滤。在NodePort场景下，Cilium的eBPF XDP加速可以将转发规则offload到物理网卡上运行，在10Mpps的请求压力下实现100%的吞吐量，而传统的kube-proxy（iptables模式）只能处理约2.3Mpps。在延迟方面，Cilium利用XDP实现容器网络的直接转发，将延迟从传统方案的100微秒量级降至30微秒以下。

在TC层：Cilium在TC ingress和egress钩子上挂载BPF程序，实现更复杂的流量控制和安全策略。虽然TC模式的性能略逊于XDP（约3.5Mpps），但它对硬件没有要求，能运行在裸金属和虚拟机等任意机器上，适用场景更广。

在Socket层：Cilium利用eBPF的socket层重定向能力，实现了同节点Pod通信的极致加速。当源端和目标端在同一个节点时，Cilium可以在socket层将流量直接重定向到目标端socket，绕过整个TCP/IP协议栈。具体来说，Cilium通过bpf_redirect_peer这个helper函数，直接将数据包重定向到目标Pod内部，无需经过veth-pair网卡和iptables处理。这种纯路由的通信模式，极大地降低了通信的延迟和开销。

Cilium的四大典型应用场景

场景一：替代kube-proxy

传统Kubernetes集群中，kube-proxy通过iptables或IPVS规则实现Service的负载均衡。当规则数量增大时，iptables的线性规则扫描会成为性能瓶颈。

Cilium用eBPF完全替代了kube-proxy。它将Service的转发规则存储在BPF Maps中，通过per-CPU哈希表进行查找，哈希查找的平均复杂度是O(1) 。Cilium可以运行在kube-proxy replacement模式下，完全由eBPF编程Service数据路径，彻底绕过iptables。

场景二：身份感知的网络策略

传统的网络策略基于IP地址和CIDR段进行过滤，在动态的容器环境中维护成本极高。Cilium引入了一套基于身份（Identity）的网络策略模型。

Cilium Agent负责监听Kubernetes资源并维护BPF Maps。每个Pod会被分配一个唯一的Security Identity，eBPF程序在内核中直接根据这个Identity进行决策，无需经过用户态的代理或iptables链。

场景三：深度网络可观测性（Hubble）

Cilium的Hubble组件利用eBPF在内核中收集网络流量信息。它可以实现0侵入采集L3-L7流量，实时生成服务拓扑和网络指标，100%覆盖K8s集群内东西向流量，而单节点CPU开销低于2% 。

Hubble通过eBPF程序直接在内核中收集数据，避免了昂贵的用户态/内核态上下文切换，让网络可观测性从“出了故障再排查”变成了“实时可视化监控”。

场景四：内核级Service Mesh

传统Service Mesh依赖Sidecar代理（如Envoy），每个Pod都需要伴随一个代理容器，带来了额外的资源消耗和延迟。

Cilium利用eBPF在L3/L4层直接在内核中处理服务网格的核心功能（服务发现、负载均衡等）。eBPF允许在socket层和网络接口层同时拦截数据包，极大地缩短了每个数据包的路径。对于L7层的复杂策略，Cilium通过节点本地的Envoy实例来补充，实现了性能与功能完整性的结合。

五、流程总结

为了帮助你更直观地理解，我把整个流程、eBPF的介入点以及Cilium的落地点整理如下：

收包路径：网卡硬件 → DMA → Ring Buffer → 硬中断 → 软中断(NAPI) → [XDP/Cilium XDP LB] → sk_buff分配 → 链路层 → [TC ingress/Cilium策略] → IP层 → [tracepoint/kprobe/Hubble观测] → TCP/UDP → [socket层/Cilium同节点加速] → socket接收队列 → 用户态

发包路径：用户态 → 系统调用 → socket → [socket层eBPF/Cilium重定向] → TCP/UDP → IP层 → [tracepoint/kprobe/Hubble观测] → 链路层 → [TC egress/Cilium策略] → Ring Buffer → 网卡驱动 → 硬中断(发送完成)

结语

Linux网络收发包是一个精密而高效的流水线作业，从网卡硬件到应用层，每个环节都有其设计巧思。而eBPF的出现，让我们能够在几乎每一个环节“插一脚”——或在最早期（XDP）做高性能过滤，或在协议栈内部（TC/tracepoint）做精细化观测与控制。

Cilium则将eBPF的这些能力系统地组织起来，形成了一个完整的云原生网络解决方案——从负载均衡到安全策略，从网络可观测性到Service Mesh，Cilium用eBPF重新定义了Kubernetes网络的边界。

理解这些流程、钩子点以及Cilium的落地方式，是进行网络性能优化、问题排查和云原生基础设施开发的坚实基础。希望这篇文章能帮你建立起清晰的认知框架。

下一篇聊聊cilium工作原理，欢迎转发评论！！！