Linux内核网络子系统排查：从收包路径到TCP调优-代码聚汇网

Linux内核网络子系统排查：从收包路径到TCP调优

Linux网络性能优化内核协议栈软中断

|难度：普通|阅读约 36 分钟

干过几年 Linux 服务器和应用开发的人，大概都遇到过这种场景：业务高峰期，用户反馈“页面卡了”；你上去一看，CPU 不高、磁盘不忙、内存也够，可 ssh 进去敲个命令都要转两秒。查到最后，问题往往不在应用，而在内核的网络路径上。这就是 Linux 内核网络子系统的怪脾气——它平时安静得像不存在，可一旦哪个环节失速，整个系统的服务质量都会被打回原形。

这篇文章想聊的，就是我踩过这些坑之后沉淀下来的网络子系统排查套路和源码阅读路径。我会从一次真实的收发包性能事故讲起，拆开网卡中断、软中断、协议栈、socket 队列这条完整链路，再把 TCP 调参、网卡多队列、NAPI、ftrace/perf/dropwatch 观测这些高级话题串起来。无论是做系统运维、内核开发，还是嵌入式 Linux 上的网络驱动移植，这条“从收包到应用”的流水线都是绕不开的主干道。

1. 开局先看一场真实事故：CPU 空闲但服务抖动

有次线上 Nginx 集群晚高峰出现诡异现象：带宽没跑满，总 CPU 使用率也就 20% 出头，但客户端超时率明显上升。我用 sar -n DEV 看流量，再用 top -H 看线程，发现一个规律——CPU0 的软中断（si）占用已经接近 100%，其他核心全部闲着。再配合 ethtool -S eth0 检查网卡计数，rx_missed 和 rx_dropped 都在缓慢上涨。

这就是非常典型的“中断收包集中在单核”导致的背压。这台机器是千兆网卡，默认只开了一个队列，硬中断基本落在 CPU0 上，小包并发一上来，CPU0 光处理软中断就忙不过来，内核的 netdev_max_backlog 队列一旦堆满，包就开始丢。应用层看到的表现是连接时断时续，请求偶发超时。

这个问题不复杂，但很能说明一件事：Linux 内核网络子系统不是黑盒，它更像一条流水线。硬中断只是按门铃，真正干活的是软中断和协议栈；任何一个“工位”堵住，整条线的吞吐都会降级。后面的内容，我就按这条流水线的顺序来拆解，从收包路径讲到 TCP 参数，再讲到观测工具和排查手法。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 网络包在内核里到底跑了多远

2.1 先建立“收包流水线”的整体认知

一个数据包从网线进入 socket，中间经历的环节远比你想象的多。简单梳理一下主干路径：

网卡通过 DMA 把包写入内存中的 ring buffer，然后触发硬中断。
CPU 响应硬中断，执行中断处理函数。这个函数不会做太多事，核心是调用 napi_schedule()，把后续处理交给软中断。
软中断（NET_RX_SOFTIRQ）唤醒，进入 net_rx_action()，开始轮询网卡的 poll 回调。
驱动从 ring buffer 取出 sk_buff，调用 netif_receive_skb() 把包交给协议栈。
协议栈按顺序处理：ip_rcv() 做 IP 层解析，路由查找，netfilter 钩子，最终进入 tcp_v4_rcv() 或 udp_rcv()。
包进入 socket 的接收队列，唤醒等待在 read() 上的进程。

理解这条链路的第一个关键点，是“硬中断只做最小工作”。真正消耗 CPU 的是软中断和协议栈处理。很多人查网络性能时只盯硬中断，其实大多数瓶颈都出在硬中断之后的阶段，尤其是软中断分配不平衡、协议栈锁竞争、netfilter 规则过多这几类问题上。

第二个关键点是“每一层都可能丢弃包”。驱动 ring buffer 满了会丢，netdev_max_backlog 满了会丢，netfilter 规则拒绝会丢，socket 接收队列满了也会丢。排查时如果只看应用日志，往往什么异常都看不到，必须一层一层查计数。

2.2 sk_buff：贯穿全程的“快递箱”

如果说网络子系统是一条流水线，那 sk_buff 就是在这条线上跑来跑去的快递箱。协议栈里的函数几乎都在跟它打交道，源码里见到 struct sk_buff *skb 的频率高到你不想记住都难。

很多人误以为 sk_buff 只是“一大块存数据的内存”，这理解偏差很大。它真正的设计精髓在于“分片视图”：数据本身可能存放在多个不连续的内存页里，而 sk_buff 通过 head、data、tail、end 这些指针描述当前协议层能看到的数据范围。TCP 层给包加头，就执行 skb_push() 把 data 指针往前移；IP 层拆掉头，就执行 skb_pull() 把 data 指针往后移。整条链路上数据基本不拷贝，只是指针在“拨来拨去”。

这套机制带来的实际收益是巨大的。一次标准的 TCP 收包，从网卡驱动到应用层，真正发生的数据拷贝可能只有最后那次从内核 socket 缓冲区拷到用户态缓冲区的动作。中间穿越 IP 层、TCP 层时，全是指针操作。所以如果你在读网络驱动源码，看到一堆 skb_reserve()、skb_put()、skb_pull() 的调用，不用慌，它们都是在调整那个“快递箱”的盖子位置，而不是把货倒来倒去。

2.3 协议栈的“分诊台”：路由查找与 netfilter

包到达 IP 层后，内核要做一个关键决策：这个包是发给本机的，还是需要转发的？这个决策由路由查找完成，核心函数是 ip_rcv() 之后的 ip_route_input_noref()。它查 FIB 路由表，结果决定包进入 ip_local_deliver()（本机接收）还是 ip_forward()（转发）。

在这条路径上，还有一个绕不开的坎：netfilter。Linux 的防火墙、NAT、连接跟踪全部基于 netfilter 钩子实现。数据包经过 PRE_ROUTING、LOCAL_IN、FORWARD、LOCAL_OUT、POST_ROUTING 这些挂载点，每一个点上可能有 iptables/nftables 规则等着它。

如果你在生产环境开启了 conntrack，那么每个连接都要在连接跟踪表里建条目。连接数一高，nf_conntrack 的哈希表查询和锁竞争会成为很明显的 CPU 热点。遇到流量高但吞吐上不去的场景，先看一眼 /proc/sys/net/netfilter/nf_conntrack_max 和当前表项，再用 perf 确认是不是 nf_conntrack_in() 在消耗 CPU，很多时候这才是真正的瓶颈。

3. socket 层与 TCP 协议的“内核参数生意经”

3.1 从 accept 队列说起：listen 的背压

TCP 服务端的连接建立，看起来就是一次三次握手，其实背后有两层队列：半连接队列（SYN 队列）和全连接队列（accept 队列）。

收到 SYN 后，连接进入 SYN 队列，此时状态是 SYN_RECV；三次握手完成，连接从 SYN 队列移到 accept 队列，状态变成 ESTABLISHED。应用调用 accept() 从 accept 队列取走连接。如果 accept 队列满了，内核会直接丢掉最后的 ACK，客户端那边表现为连接偶尔建不起来，要重试多次才成功。

这个队列的大小不是单个参数决定的。net.core.somaxconn 和调用 listen(fd, backlog) 时传入的 backlog，会取一个较小值作为 accept 队列上限。很多应用默认 listen(128)，但 somaxconn 也是 128，对于高并发的服务这个值根本不够。排查时用 ss -lnt 看监听端口的 Send-Q 和 Recv-Q，如果 Recv-Q 长期接近 Send-Q，说明 accept 队列在堆积；看 /proc/net/netstat 里的 ListenOverflows，如果持续增长，基本坐实了。

3.2 理解了队列再看调参：别盲目抄配置

网上流传的 TCP 调参配置很多，但同一个参数在不同场景下效果可能完全相反。我见过有人把 net.ipv4.tcp_tw_recycle 打开后，线上连接开始随机失败，最后排查到是 NAT 环境下时间戳判断出错。这个参数在内核 4.12 之后已经被移除了，但在老内核上仍然存在，强烈建议不要开。

tcp_tw_reuse 则要分场景。它只对主动发起连接的 socket 生效，也就是你的程序作为客户端去 connect() 外部服务时，可以复用 TIME_WAIT 端口。如果是 Nginx、Tomcat 这类监听型服务，开启这个参数的意义不大，因为监听 socket 收到的连接不会走这条复用逻辑。另外在 NAT 环境里启用它，也可能因为时间戳问题导致连接被 RST，所以要么不开，要么只在纯出站连接的机器上开。

要管控 TIME_WAIT 数量，更稳妥的做法是调大 net.ipv4.tcp_max_tw_buckets，让超出部分由内核兜底处理；同时配合 tcp_fin_timeout 缩短主动关闭方的 FIN_WAIT_2 超时时间。注意 TIME_WAIT 本身的持续时间受 2*MSL 控制，并不由 tcp_fin_timeout 直接决定，这个参数管的是 FIN_WAIT_2。

3.3 一套“高并发短连接”实测参数

下面是我在压测和线上环境里验证过的一套配置，针对“高并发短连接、服务端大量 accept、客户端频繁 connect”的场景。注意这不是万金油，必须结合业务调整。

ini复制# /etc/sysctl.d/99-network-tune.conf
fs.file-max = 2097152
net.ipv4.ip_local_port_range = 1024 65535
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 65535
net.core.netdev_max_backlog = 65535
net.ipv4.tcp_max_tw_buckets = 2000000
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 3

生效方式：sysctl -p /etc/sysctl.d/99-network-tune.conf。

参数含义拆开讲：tcp_max_syn_backlog 决定 SYN 队列大小，在 SYN 洪水或握手慢的场景下要调大；netdev_max_backlog 是协议栈入口的接收队列长度，小包冲击时很容易在这里丢包；tcp_max_orphans 限制孤立 socket 数量，应用崩溃后大量连接处于孤儿状态时，这个参数能防止内核内存被拖垮；tcp_keepalive* 那一组是调探活频率，对长连接服务比较重要。调整之后要观察 ss -s 和 /proc/net/netstat，确认各项指标确实在变好，而不是改了图个心安。

4. 网卡多队列、RSS 与 NAPI 收包细节

4.1 为什么单队列网卡扛不住高 PPS

回到开头那个事故现场。单队列网卡意味着所有硬中断都落在同一个 CPU 上，而软中断也大概率跟着跑在这颗核上。PPS 很高但带宽不大的场景里，比如每包 64 字节的小流量攻击，单核很快就会因为软中断处理饱和而丢包。

判断这个问题的命令很简单：top -H 看 si 是不是集中在某一个 CPU 上；cat /proc/interrupts 看网卡中断号对应的 CPU 分布。如果所有中断都堆在一个核上，要么换支持多队列的网卡和驱动，要么用软件方式把包分发到多个核。

4.2 RSS、RPS、RFS 到底怎么选

RSS 是硬件多队列机制。网卡把收到的包按哈希值分散到多个 ring buffer，不同队列触发不同 CPU 的中断。开启方式是用 ethtool -L eth0 combined 4 或者通过驱动模块参数配置。这种方式性能最好，但依赖网卡和驱动支持，虚拟机里的虚拟网卡通常不支持或者支持不完整。

RPS 是纯软件方案，在 __netif_receive_skb_core() 入口附近把包按哈希重新分发到指定 CPU 集合。配置路径是 /sys/class/net/<网卡>/queues/rx-<n>/rps_cpus，写入一个十六进制 CPU 掩码即可。RPS 适合老网卡、虚拟化环境，以及 RSS 队列数不够的场景。缺点是分发本身也有 CPU 开销，核数少的机器不一定划算。

RFS 在 RPS 基础上更进一步，目标是让包尽量送到正在处理对应 socket 的 CPU 上，提高 CPU 缓存命中率。开启 RFS 需要设置 net.core.rps_sock_flow_entries 和每个队列的 rps_flow_cnt。实际操作中，如果单机连接数很高、多核负载不均，RFS 提升明显；但如果命中率上不去，反而会增加重哈希开销，需要实测对比。

4.3 NAPI 与中断合并：在高吞吐和低延迟之间选边

NAPI 是 Linux 收包的核心机制，它的思路是：中断只负责“叫醒”CPU，叫醒之后 CPU 进入轮询模式，一口气把 ring buffer 里的包处理完再休眠。这样做能避免高流量下中断风暴把 CPU 打满。NAPI 的处理预算由 net.core.netdev_budget 控制，默认 300，意思是每次软中断最多处理 300 个包（新内核还引入了 netdev_budget_usecs 时间预算）。

中断合并则是网卡驱动的行为，通过 ethtool -C eth0 rx-usecs 100 tx-usecs 100 这类命令配置。合并时间越长，CPU 开销越低，但延迟越高。做视频、RPC 这类低延迟业务，要把合并值调小；做文件传输、日志采集这类大吞吐业务，可以适当调大。

我在实践中遇到过把 netdev_budget 盲目从 300 调到 6000，结果延迟大幅上升的情况。预算越大，单次软中断处理时间越长，其他任务被抢占的概率越高。调这个参数必须先确认 softnet_stat 里的 time_squeeze 列在持续增长，否则根本没有调的必要。

5. 用 ftrace 和 perf 把内核网络路径“可视化”

5.1 在源码里找函数：先找到“锚点”

读内核网络源码最怕的是“大海捞针”。我的习惯是先找一个固定的“锚点”函数，再顺着函数调用关系向外扩展。比如从 /proc/kallsyms 里确认 netif_receive_skb 存在，然后在源码树里 grep -rn "netif_receive_skb" net/，一下子就找到了 net/core/dev.c。再从这个函数出发，看它调用了谁、被谁调用，很快就能把整条收包路径串起来。

内核源码目录也很有规律：net/ipv4 放 TCP/UDP/ICMP，net/core 放通用网络框架，net/netfilter 放 netfilter，net/packet 放 AF_PACKET，drivers/net/ethernet 放各种网卡驱动。需要看哪个层次，直接进对应目录。

5.2 用 ftrace 跟踪收包路径

ftrace 是内核自带的追踪器，开销低，适合观察函数调用序列。想直观看到一次收包从驱动进入协议栈的完整路径，可以用 function_graph：

bash复制mount -t tracefs tracefs /sys/kernel/tracing
echo function_graph > /sys/kernel/tracing/current_tracer
echo 'netif_receive_skb*' > /sys/kernel/tracing/set_ftrace_filter
echo 1 > /sys/kernel/tracing/tracing_on
# 触发一次流量，然后停止
echo 0 > /sys/kernel/tracing/tracing_on
cat /sys/kernel/tracing/trace

如果不想追踪所有函数，只想看某个事件是否发生以及基本信息，用事件追踪更轻量：

bash复制echo 1 > /sys/kernel/tracing/events/net/netif_receive_skb/enable
cat /sys/kernel/tracing/trace

事件追踪的好处是内核在关键路径上已经预埋了 tracepoint，你不需要猜函数名，也不用担心 kprobe 带来的稳定性风险。熟练之后，这套东西比看半天日志有用得多。

5.3 用 perf 看热点：到底谁在吃 CPU

ftrace 回答“函数怎么调的”，perf 回答“哪个函数最费 CPU”。网络性能排查中，我常用的是这两板斧：

bash复制perf top -C <cpu>            # 看某个 CPU 上的热点函数
perf record -a -g -- sleep 10
perf report                  # 看全系统的调用火焰图数据

重点观察的符号一般是 netif_receive_skb_core、ip_rcv、tcp_v4_rcv、nf_conntrack_in、queued_spin_lock_slowpath。如果锁竞争成为热点，queue_spin_lock_slowpath 会非常靠前；如果 netfilter 规则太重，nf_hook_slow 和 nf_conntrack_in 会显现出来。perf 的好处是它把问题从“玄学”变成“统计”，你总能找到第一个吃 CPU 的入口。

5.4 dropwatch 和 bpftrace：精准定位丢包位置

网络丢包最烦人的一点是“不知道在哪丢的”。内核提供了一个叫 drop_monitor 的机制，配合 dropwatch 工具，可以直接告诉你 kfree_skb() 是在哪个调用栈上被触发的。这在定位驱动丢包、协议栈丢包、socket 队列丢包时简直是指路明灯。

bash复制# 先加载内核模块
modprobe drop_monitor
# 用 root 启动 dropwatch，加载内核符号
dropwatch -l kas
# 交互界面里输入 start 开始监听
> start

等一会儿，屏幕上会打印丢包时的内核函数调用栈。看到栈顶是 tcp_v4_rcv 且下一步进了丢包分支，就去查接收队列是否溢出；看到栈顶停在驱动入口，就回去查 ring buffer 和中断合并配置。bpftrace 则更灵活，比如想统计收包函数被哪些进程触发最多：

bash复制bpftrace -e 'kprobe:netif_receive_skb { @[comm] = count(); }'

这条命令统计每个进程触发收包函数的次数，对理解特定进程的网络行为很有帮助。bpftrace 语法简单，但生产环境使用前建议先在测试机验证，避免 kprobe 太多影响稳定性。

6. 常见故障排查速查与经验

6.1 先看哪几条命令，包才知道去哪了

网络排查最怕瞎猜。我给团队定的规矩是：先看计数器，再下结论。下面这几个命令基本能覆盖 90% 的瓶颈定位：

检查项	命令	关注点
网卡丢包计数	`ethtool -S eth0`	rx_dropped、rx_missed、rx_errors
软中断分布	`top -H`	si 是否集中单核
中断分布	`cat /proc/interrupts`	网卡中断是否多核分散
协议栈丢包	`netstat -s`、`/proc/net/netstat`	ListenOverflows、TCPBacklogDrop
背压队列	`softnet_stat`	dropped 列、time_squeeze 列
连接队列状态	`ss -lnt`	Recv-Q 是否接近 Send-Q
conntrack 状态	`sysctl net.netfilter.nf_conntrack_count`	是否接近 max

这套组合拳打下来，问题基本能框定到硬件、中断、队列、协议栈这四个层面之一。我的经验是：先看网卡环形队列有没有丢，再看 softnet_stat 背压，然后是 listening 队列溢出，最后才轮到应用本身。

6.2 丢包但应用毫无感知的坑

有几种丢包非常隐蔽，应用日志完全看不出异常。第一种是网卡 ring buffer 溢出，表现是 ethtool -S 里的 rx_missed 在涨，但应用只是偶尔超时。处理方法是调大 ring buffer，比如 ethtool -G eth0 rx 4096 tx 4096，但注意这会增加内存占用和硬中断延迟。

第二种是 netdev_max_backlog 溢出，表现是 /proc/net/softnet_stat 第二列的 dropped 在涨。这个参数默认 1000，在小包高并发场景下很容易被冲垮，调到 32768 甚至更大通常有立竿见影的效果。

第三种是 accept 队列溢出，应用不调用 accept()，或者调用太慢，包在 TCP 层反复重传后才丢弃。这个要回到第 3 节讲的队列调优去解决。第四种是 nf_conntrack 表满，内核日志里会出现 nf_conntrack: table full, dropping packet，这时所有新建连接都会间歇性失败，要么扩表，要么排查连接泄漏。

6.3 端口耗尽与 TIME_WAIT 的真实形态

出站方向的端口耗尽，最典型的表现是应用报“Cannot assign requested address”。此时 net.ipv4.ip_local_port_range 限制的端口区间已经被 TIME_WAIT 和 ESTABLISHED 连接占满。诊断命令是 ss -s 看 TIME_WAIT 数量，如果几万甚至几十万，先查是不是客户端连接没有复用、连接池太小，或者服务端处理太慢导致连接堆积。

入站方向的 TIME_WAIT 问题则表现为连接状态堆积但应用无感，直到 tcp_max_tw_buckets 到达上限后内核开始强制回收 TIME_WAIT socket，日志里可能出现相关提示。这个问题在新内核里通常只是“看着吓人”，并不直接导致新连接失败，真正的风险是 NAT 场景下旧连接的重传包被新连接接收，造成数据错乱。所以我的建议是：先确认业务是否真的因 TIME_WAIT 而失败，再决定要不要调参，不要一看到 TIME_WAIT 多就慌。

7. 再往下：这个网络子系统还能怎么深入

7.1 硬件卸载与零拷贝：从“软件处理”到“硬件加速”

网络子系统的高性能方向，很大程度上是“减少内核参与的环节”。TSO（TCP 分段卸载）让大包由网卡硬件分片，GSO 在软件层面模拟类似效果；GRO 把多个小包合并后再交给协议栈，降低 CPU 处理次数。用 ethtool -k eth0 能查看这些卸载特性是否开启，如果关着，打大流量时 CPU 消耗会明显偏高。

应用层面，sendfile() 和 splice() 可以在内核里完成数据搬移，避免一次用户态拷贝。再往下还有 DPDK、RDMA 这类完全绕过内核协议栈的方案。但我的看法是，“绕过内核”意味着你放弃了内核提供的协议栈、安全、连接管理能力，代价非常大。大多数业务先把 TSO/GRO/多队列这些常规手段吃透，性能提升就已足够。

7.2 eBPF/XDP：在协议栈入口之前拦截

XDP（eXpress Data Path）让 BPF 程序跑在网卡驱动最早期，数据包还没进入协议栈之前就能决定丢弃、转发或者继续上抛。这个位置对 DDoS 防御、简单报文过滤、流量统计特别有价值，因为它的处理成本极低，适合高 PPS 场景。

写一个最简单的 XDP 示例比想象中容易：

c复制#include <linux/bpf.h>
#include <bpf/bpf_helpers.h>

SEC("xdp")
int drop_all(struct xdp_md *ctx)
{
    return XDP_DROP;
}

编译后通过 ip link set dev eth0 xdp obj drop_all.o sec xdp 挂载。把返回码改成 XDP_PASS 就是放行。这个例子虽然简单，但展示了 eBPF 时代网络子系统的扩展方式：以前想在内核收包路径上做点事情，要么改源码重新编译内核，要么挂 netfilter 钩子；现在写一段 BPF 程序就能安全地注入，这才是高级话题里最有想象力的方向。

7.3 虚拟化与容器网络：veth、bridge 与 OVS

热词里反复出现“Linux 内核虚拟化”，这也是网络子系统里的重头戏。容器的 eth0 实际上大多是一对 veth 设备的一端，另一端插在宿主机的 bridge 或者 OVS 上。数据从容器出去，先经过 veth 的 ndo_start_xmit 到对端，再到 bridge 查 FDB 表，最后到达宿主机协议栈或另一台容器。

理解这条路径，对排查容器网络延迟非常有帮助。veth 本质上是纯软件网卡，它不经过物理链路，但也因此丢包点更多、排查更难。遇到容器访问另一个 Pod 偶尔超时，不要只看应用日志，先在宿主机上用 tcpdump -i vethxxx 和 ss -lnt 对照，确认包是否真的走到了对的设备上。容器网络出问题，往往不是内核协议栈的问题，而是虚拟设备链路的某个环节配置错了。

8. 写在最后的个人经验

我实际排查网络性能问题时，最大的体会是：面对“慢”和“丢包”，先忍住改参数的冲动，先搞清楚包是在哪一环节被拖住的。网络子系统不是玄学，它就是一条由中断、队列、协议栈、socket 组成的流水线，每个环节都有对应的计数器。把 ethtool、ss、softnet_stat、dropwatch 这些工具用熟之后，你会发现大部分问题都能精确归因。

另外一个小建议：读内核网络源码时不要从头到尾通读，而是从你熟悉的现象切入。比如你遇到 accept 队列堆积，就从 listen() 系统调用追到 inet_csk_accept()，再追到 sk_acceptq_is_full()，那样你记住的不是孤立的函数，而是一整条因果链。时间久了，这套“现象 -> 计数器 -> 函数 -> 原因”的思维方式，会让你的排查速度比大多数人快一个数量级。