linux内核网络队列未调优是go视频转发服务卡在10gbps、cpu打满吞吐上不去的主因，关键参数net.core.netdev_max_backlog默认值过低导致接收队列溢出丢包，需结合rx队列数、udp gro/gso配置、conntrack绕过及软中断绑核综合优化。
Go 视频转发服务在高并发小包场景下卡在 10Gbps、CPU 打满但吞吐上不去，八成是 Linux 内核网络队列没调好，不是 Go 代码写得不够快。
net.core.netdev_max_backlog 被低估导致接收队列溢出
这是视频转发最常踩的坑：网卡收到大量 UDP 小包（比如 RTP 流），但内核软中断处理不过来，net.core.netdev_max_backlog 默认值（通常 1000）远低于万兆网卡实际接收能力。包还没进协议栈就被丢弃，ethtool -S eth0 里 rx_dropped 或 rx_missed_errors 会明显上升。
- 查当前值：
sysctl net.core.netdev_max_backlog - 临时调大（建议从 5000 起步）：
sysctl -w net.core.netdev_max_backlog=5000 - 配合网卡 RX 队列数调整（如 8 队列）：
ethtool -L eth0 rx 8，避免单队列瓶颈 - 注意：该值不能无限制增大，过大会拖慢 softirq 处理延迟，实测超过 10000 后收益递减
UDP GRO/GSO 关闭不当引发分片与重组开销
视频流常用小包（ReadFromUDP 按原始包边界读取时，GRO 合并反而破坏了应用层包结构，导致解析失败或额外拆包逻辑——这会把 CPU 压在内核态。
- 确认是否启用：
ethtool -k eth0 | grep generic-receive-offload - 关闭 GRO（对视频转发更稳）：
ethtool -K eth0 gro off - 同时关掉 LRO（若存在）：
ethtool -K eth0 lro off - 注意：
udp4_ufo_fragment在 GSO 开启时才生效，视频转发一般不需要 UFO 分片，保持gso off即可
Go runtime 与软中断 CPU 绑核冲突
Linux 网络软中断（NET_RX）默认在任意 CPU 上执行，而 Go 程序可能用 GOMAXPROCS 锁定了部分核心。结果就是：软中断挤占了 Go goroutine 的调度资源，或者反过来——Go 抢占了软中断处理时间，造成接收延迟抖动。
- 查软中断分布：
cat /proc/softirqs | grep NET_RX - 将软中断绑定到非 Go 主业务的核心（如 CPU 0–3 处理中断，4–7 跑 Go）：
echo 0f > /proc/irq/*/smp_affinity_list（需按实际 IRQ 号操作） - Go 侧显式设置：
runtime.GOMAXPROCS(4)并用taskset -c 4-7 ./your-app启动 - 关键点：别让软中断和 Go 的 GC mark worker 落在同一核上，否则延迟毛刺明显
ip_forward + conntrack 对视频流的隐性拖累
如果视频转发走的是 Linux 路由转发（net.ipv4.ip_forward=1），且未禁用连接跟踪（conntrack），每个 UDP 包都会被 nf_conntrack 查表——这对每秒数万小包的视频流是灾难性的，nf_conntrack_entries 占满后直接丢包。
- 确认是否启用：
sysctl net.ipv4.ip_forward和lsmod | grep nf_conntrack - 纯转发场景应绕过 conntrack：
iptables -t raw -A PREROUTING -p udp -j NOTRACK - 再禁用 conntrack 模块（如无其他依赖）：
modprobe -r nf_conntrack - 注意：
NOTRACK后需手动确保不会触发rp_filter丢包，建议同步设net.ipv4.conf.all.rp_filter=0
真正卡住视频转发的，往往不是 Go 的 ReadFromUDP 性能，而是内核从网卡 DMA 收包到交付 socket 这一段的排队、合并、跟踪逻辑。调参前先看 /proc/net/snmp 里的 UdpInErrors 和 /proc/net/dev 的 rx_dropped，数字一高，基本就能锁定是哪一层在丢包。
