AI辅助写作·已校阅

运维 / 内核调优 / 排障工程师必读 · 阅读约 9 分钟

把 Linux 网络栈想象成一座繁忙的港口：包是集装箱，CPU 是码头工人，网卡是起重机。那些三字母缩写，就是港口里的自动化设备——有的负责分包，有的负责合包，有的调度 CPU，有的减少中断。把它们搞清楚，80% 的网络性能问题就有了定位方向。

一、数据包分段与聚合

这组机制决定大包如何拆、小包如何合，对吞吐量影响最直接。

发送路径：

Application → TCP Stack → GSO（有 TSO 则直接卸载给网卡，否则软件分段）→ NIC

接收路径（GRO / LRO 择一）：

NIC → GRO（软件合并，现代推荐）→ TCP/IP Stack → ApplicationNIC → LRO（硬件合并，旧方案）→ TCP/IP Stack → Application

⚠️ 注意：GRO 与 LRO 是替代关系，不是串行关系。 现代 Linux 驱动开启 GRO 后通常会自动禁用 LRO，因为 GRO 更灵活（支持转发场景，LRO 不支持）。不要同时依赖两者。

⚠️ GRO 与 tcpdump 的坑： GRO 开启时，tcpdump 抓到的可能是 64KB 超大 TCP 包。原因是 GRO 在包到达抓包点之前就已完成合并。临时关闭方法：ethtool -K eth0 gro off，抓完再开回来。

⚠️ TSO 依赖 SG： TSO 正常工作的前提是网卡支持 Scatter-Gather I/O。若 SG 未启用，内核需先将分散内存复制为连续 buffer 才能执行 TSO，反而增加开销。排查 TSO 异常时先验证：ethtool -k eth0 | grep scatter-gather。

二、CPU 多核扩展与负载均衡

多核服务器必备，直接决定 PPS 上限和单核瓶颈。

RSS 工作原理：

NIC 收到入包 → 按（源IP、目标IP、源端口、目标端口）计算哈希→ 分发到不同 RX 队列 → 各队列由独立 CPU 处理

🚧 常见现象：单核 CPU 100%，其余核空闲。 原因几乎都是 RSS 未启用或队列数为 1。检查命令：ethtool -l eth0，预期 Combined 值大于 1。

三、校验与分片 Offload

减少 CPU 冗余计算，属于基础优化项。

⚠️ 注意：以下缩写（CSO / RXC / TXC / LSO）并非 Linux 内核或 ethtool 的官方术语，仅用于本文的概念归类。实际 ethtool -k eth0 的输出字段名为 rx-checksumming、tx-checksumming 等，请以工具输出为准。

查看网卡当前所有 offload 开关：ethtool -k eth0

四、中断与轮询机制

影响高 PPS 场景下 CPU 利用率的核心机制。

传统模式： 每个包 → 一次硬件中断 → CPU 处理。10M PPS 意味着每秒 1000 万次中断，CPU 直接被淹没。

NAPI 模式：

第一个包触发中断 → 关闭中断，进入轮询 → 批量 poll RX ring → 队列空后重开中断，中断次数大幅下降，CPU 效率显著提升。

五、队列与流控机制

Linux 网络栈的流量调度层。

常用 qdisc：默认 pfifo_fast；延迟敏感场景推荐 fq_codel；高吞吐公平调度推荐 fq。

查看当前 qdisc：tc qdisc show dev eth0

六、现代高速网络数据路径

DDoS 防护 / 云厂商负载均衡 / eBPF 观测的核心技术。

⚠️ BPF 与 eBPF： 内核 3.18+ 后，BPF 全面扩展为 eBPF（extended BPF），具备更强的安全模型和更丰富的 hook 点。本文中 BPF 均指 eBPF，两个词在现代语境下通常可互换。

XDP 处理路径：

NIC 驱动收包 → XDP Hook（可 DROP / PASS / REDIRECT / TX）→ 内核网络栈 → Socket → 应用

XDP 在单核上可达 10M+ PPS，而普通内核协议栈通常 1～3M PPS。Cilium、Katran（Meta LB）、Cloudflare DDoS 防护均深度依赖 XDP + eBPF 组合。

XDP vs DPDK：

七、虚拟化与隧道网络

云原生、容器网络（K8s/Docker）必遇词汇。

veth pair 工作原理： 每个容器的 eth0 实际上是 veth pair 的一端，另一端挂在宿主机的 bridge（如 docker0 / cni0）上。从容器发出的包从 eth0 进入 veth，直接从宿主机侧的 veth 另一端出来，无需经过完整网络栈。

八、Linux 网络性能机制层级全图

从应用层到网卡，每层对应的核心机制：

Application  ↕Socket 层  ↕  ← sk_buff 贯穿以下所有层TCP/IP 协议栈（校验和卸载：rx-checksumming / tx-checksumming）  ↕GSO / GRO 层（GSO · GRO · LRO 三选其一）  ↕QDISC / TC 层（QDISC · BQL · TC）  ↕Driver / XDP 层（XDP · BPF · NAPI · RPS · RFS · AF_XDP）  ↕NIC 硬件（SG · TSO · RSS · MSI-X）

说明： sk_buff 是内核贯穿整个网络栈的核心数据结构，从驱动层 DMA 入包到 Socket 层交付应用全程使用，不属于任何单一层。AF_XDP 是内核向用户态暴露的零拷贝套接字接口，工作在 Driver/内核边界，不是 NIC 硬件特性。

定位性能瓶颈时，从上到下逐层排查，每层有对应的工具和计数器。

九、排障必记的 16 个核心词汇

• 分段 / 聚合：
   TSO · GSO · GRO · LRO · SG
• CPU 多核扩展：
   RSS · RPS · RFS · XPS
• 中断 / 队列 / 高速路径：
   NAPI · MSI-X · BQL · QDISC · XDP · BPF · AF_XDP

十、三个高频排障场景

场景 1：tcpdump 抓到 64KB 超大 TCP 包

根本原因： GRO 在包到达抓包点之前已合并。

验证：ethtool -k eth0 | grep generic-receive

处理：ethtool -K eth0 gro off（抓包期间临时关闭）

场景 2：单核 CPU 100%，其余核空闲

根本原因： RSS 未启用或网卡只有 1 个 RX 队列，所有包打到同一核。

验证：ethtool -l eth0（Combined 是否大于 1）

处理： 启用 RSS 多队列 + 配置 irqbalance 或手动绑核

场景 3：高 PPS 时 CPU 软中断占用极高

可能原因： GRO 关闭 / NAPI budget 不足 / RPS 未配置 / MSI-X 未启用

验证：cat /proc/net/softnet_stat（第 3 列 time_squeeze 持续增长则 budget 不足）

处理： 调大 net.core.netdev_budget，开启 RPS，检查 MSI-X

十一、常用排障命令速查

# 查看所有 offload 状态（含 SG / TSO / GRO / checksumming 等）ethtool -k eth0# 查看 / 设置队列数ethtool -l eth0ethtool -L eth0 combined 4# 查看中断分布cat /proc/interrupts# 查看 softnet 统计（排查软中断压力）cat /proc/net/softnet_stat# 查看 RPS 配置cat /sys/class/net/eth0/queues/rx-0/rps_cpus# 查看 qdisctc qdisc show dev eth0tc -s qdisc show dev eth0

完整收包路径（排障藏宝图）：

NIC → DMA → RX ring → NAPI poll → GRO → IP layer → TCP → socket buffer → Application

每个节点出问题都有对应的计数器，按图索骥即可定位。

下篇预告：Linux 网络性能 30 个核心调优参数，涵盖 net.core / tcp / rmem / wmem / backlog 等关键内核参数。

基于 Linux 5.x+ 内核 · 部分特性在旧版内核上可能不完整