1. 这个项目到底解决什么问题先说结论这不是一个非做不可的项目但做完之后你会发现它对理解 Linux 网络协议栈、流量统计方式和外设控制的帮助比读十篇博客都大。网络负载监测灯说白了就是一台 Linux 设备实时统计网卡流量然后把上行、下行速率或者连接数通过一串 LED 灯的亮度、颜色、闪烁频率直观地展示出来。网卡在“跑”什么你不用打开终端敲iftop抬头看一眼灯就知道。我觉得它特别适合三类人来参考一是刚学完 Linux 基础命令、想找个综合项目练手的同学这个项目会把 socket、netlink、定时任务、GPIO/I2C 外设全部串起来二是运维工程师办公桌上放一个随时感知内网流量是否异常三是嵌入式 Linux 的开发者因为最终你大概率会把它从 x86 移到 ARM 板子上提前踩一遍协议栈的坑很值。关于热词里那些 SPI、IIC、Modbus、MQTT 之类的协议我这个项目一开始并没有全用上。但我会在最后说明当你把“监测灯”升级成“设备状态网关”时这些协议分别在什么环节出现。还有一点需要先讲清楚“监测”和“限制”是两回事。本项目只做监测通过 Linux 原生机制读取网卡统计信息不会修改任何网络流向也不涉及封禁、代理或者中间人操作。所以它跑在办公网络、家庭网络、生产服务器旁边都是安全且无侵入的。2. 网络数据采集的技术选型netlink、libpcap 还是 nftables 计数器2.1 先看三个候选方案的底层差异做流量监测第一步是拿到网卡上的实时流量数据。Linux 下常见的三种拿法各有各的脾气。第一种是读/proc/net/dev。这是最朴素的方式内核在每次网络中断处理时更新每个网卡的收发包计数和字节数。你只要定时去读这个文件把两次读到的字节数做差再除以时间间隔就能得到平均速率。优点是零依赖、代码简单任何 Linux 上都能跑缺点也很明显——它只有总流量没有细分你不知道是 TCP 还是 UDP更不知道是谁在跟谁通信。适合做“整体负载灯”不适合做“连接级监测灯”。第二种是 libpcap 抓包。这个方案是旁路复制数据包内核在网络协议栈入口处把每个包复制一份丢给用户态。它能看到所有包的内容五元组、负载、协议类型全都能分析。对应到实时性上它最适合做精细化的流量可视化。代价就是 CPU 和内存开销大包一多就容易丢包跑在嵌入式板子上压力更大。而且很多发行版默认不带 libpcap 开发库交叉编译的时候也是一堆依赖要解决。第三种是 netlink socket 配合内核的路由、链路统计接口。它本质上是内核和用户态之间的一种通信机制你可以通过RTM_GETLINK请求某个网卡的统计信息返回的数据结构和/proc/net/dev的内容基本同源但是通过二进制结构体传递解析起来更规整。还有一点好处是你可以监听链路的实时状态变化比如网卡 down、up、IP 变更等灯可以同步做状态提示。2.2 这个项目为什么不选 libpcap说实话我在一开始调研时也心动过既然要做成“灯”那最好能区分每条 TCP 连接的颜色比如 SSH 连接显示红色、HTTP 显示蓝色。听起来很酷但 libpcap 的抓包模式对这个项目是杀鸡用牛刀。原因有三个。第一这个项目要长时间稳定运行一般就放在那儿几个月不重启。libpcap 抓包在高流量场景下会有 buffer 溢出丢包丢包之后统计口径就歪了你看到的灯会忽明忽暗跟真实负载对不上。第二抓包权限敏感。在生产环境或不对外的网络里一个常驻进程用pcap读所有包这在安全审计上是很难解释的。你做一个可视化小灯没必要给自己惹这个麻烦。第三它需要拆包、组流为了一个灯的颜色去维护一张连接表代码量会翻好几倍。维护成本和收益不成比例。所以我在这个项目里定的思路是——先读/proc/net/dev做总流量灯再用 netlink 监听链路事件做状态灯等主体流程跑通了如果确实需要按端口或协议区分再考虑上 eBPF。热词里提到的 TCP 协议栈数据流走读、Linux 常用命令这个项目的核心部分其实都在围绕着 Linux 内核提供的统计接口转而不是自己重新造一个协议栈。2.3 关于 eBPF 的补充如果你看到内核版本是 4.9 以上直接用 eBPF 挂到tc或tracepoint上做统计性能比 libpcap 高一个量级还能拿到每个 cgroup 的流量甚至可以精确到某个进程的上下行速率。我有个做容器平台的朋友就用 eBPF 统计每个 Pod 的实时带宽然后推送数据到 Grafana。但 eBPF 对内核配置有要求CONFIG_BPF、CONFIG_BPF_SYSCALL、CONFIG_BPF_JIT都得开嵌入式板子的内核镜像未必满足。作为初版选型还是/proc/net/dev加 netlink 最省心。等你想把灯变成全屋网络态势感知屏的时候再把 eBPF 加进去不迟。3. 流量数据怎么变成光的语言映射逻辑设计3.1 速率区间划分均值、峰值和滑动窗口拿到两个时间点的字节数差值后你得到的是一个平均速率单位是 Mbps。问题来了网络流量是突发性的你用一次采样算出的瞬时速率去驱动灯灯会疯狂闪烁看着像坏了一样。解决方法是滑动窗口。我实际用的是 5 秒一个窗口窗口内每 500 毫秒采样一次存 10 个点取平均值作为灯当前要表达的速率值。这样既保留了实时性又抹平了毛刺。另一个技巧是保留一个高峰缓存——把当天观察到的最大速率记下来用它做归一化。不然的话千兆网卡偶尔跑一下 900Mbps灯一直是满亮状态后面流量降到 100Mbps 你也看不出来因为灯已经是最大亮度了。我设计了一个三档映射逻辑供你参考档位速率占比当前速率/历史峰值灯的颜色闪烁频率空闲0 ~ 5%青色常亮无正常5% ~ 60%绿色呼吸2Hz繁忙60% ~ 100%红色呼吸5Hz有人会问为什么不是颜色越深代表流量越大因为人在看灯的时候对颜色变化的敏感度低于亮度变化。你用一个高亮红色表示 100%用一个暗红表示 60%区分效果并不好。所以我干脆用“颜色类别 闪烁频率”双通道传递信息这样余光一眼就能看出当前网络紧不紧张。3.2 上行和下行两个灯还是混合色网络负载有上行和下行之分。最直观的方案是两块灯条一条上行一条下行。但也有个更优雅的做法——用一粒 RGB LED下行速率控制明暗上行速率控制色相。下行大就偏红上行大就偏蓝两者都大就变成紫色。我最终做的是“一大两小”一个大的 RGB 灯环显示总流量两个小的 LED 分别显示上行和下行速率。每次刷新的信息量刚好不会造成认知负担。如果只做一个灯混合色看着好看可别人来问你“现在上行多少”你得再掏手机查就没意思了。3.3 更新频率和用户感知灯的刷新率不需要太高。我见过有人做成 30fps 刷新结果 LED 因为 PWM 和颜色转换频繁肉眼可见地发虚而且 CPU 占用率莫名其妙高了几个百分点。实践下来 3~5Hz 的刷新率就够了毕竟灯是给人看的不是给示波器看的。刷得太快反而和呼吸节奏、闪烁频率混淆。4. Linux 下实操从统计脚本到 LED 驱动4.1 最小实现先让流量数据输出到终端好开始动真格的。我先写一个最纯粹的网络负载监测脚本它只负责读取和计算流量不接任何灯。用 Python 写的好处是开发快、可读性强坏处是如果你要上 ARM 板Python 解释器 依赖库的体积有点大。但作为原型验证Python 完全够用。import time import subprocess from pathlib import Path def read_net_dev(interface: str): path Path(/proc/net/dev) for line in path.read_text().splitlines()[2:]: if interface in line: parts line.split() # 网卡名带冒号比如 eth0: rx_bytes int(parts[0].split(:)[1]) tx_bytes int(parts[8]) return rx_bytes, tx_bytes raise ValueError(fInterface {interface} not found) def main(): iface eth0 last_rx, last_tx read_net_dev(iface) last_time time.time() peak_rx 1 peak_tx 1 while True: time.sleep(1) rx, tx read_net_dev(iface) now time.time() delta_time now - last_time rx_rate (rx - last_rx) * 8 / delta_time / 1_000_000 # Mbps tx_rate (tx - last_tx) * 8 / delta_time / 1_000_000 last_rx, last_tx, last_time rx, tx, now peak_rx max(peak_rx, rx_rate) peak_tx max(peak_tx, tx_rate) print(fRX {rx_rate:7.2f} Mbps | TX {tx_rate:7.2f} Mbps | Peak {peak_rx:.2f}/{peak_tx:.2f})这段代码有一个细节值得多说一句/proc/net/dev每行的前两列是“接口名 冒号”和“收字节数”但接口名可能长度不一致split()之后列位置会偏移所以要先把eth0:整体拆出来再转int。如果你用split()后直接取parts[1]一旦网卡名超过 6 个字符比如enp3s0列序号就全错了。我在调试时花了不少时间在这里。4.2 用 netlink 监听链路状态监测灯要有“生命体征”光有流量不够你还得知道网卡是不是活着。否则网线拔了流量归零灯显示的却是“青色常亮空闲状态”这会误导人。我加了一个 netlink 监听线程通过socket(AF_NETLINK, SOCK_RAW, NETLINK_ROUTE)实时接收链路变化消息。import socket import struct import threading def link_listener(interface: str, on_change): sock socket.socket(socket.AF_NETLINK, socket.SOCK_RAW, socket.NETLINK_ROUTE) sock.bind((0, 0)) # 只需要 RTM_NEWLINK 和 RTM_DELLINK 类型的消息 sock.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 65536) while True: data sock.recv(65536) # 解析 netlink 头部 nl_len, nl_type, nl_flags, nl_seq, nl_pid struct.unpack(LHHII, data[:16]) if nl_type in (16, 17): # RTM_NEWLINK16, RTM_DELLINK17 iface_name extract_ifname(data) if iface_name interface: # 如果消息里带 IFF_RUNNING 标志说明链路是通的 flags extract_flags(data) on_change(interface, flags 0x40 ! 0) # IFF_RUNNING 0x40这段代码在树莓派和大多数 Linux 板卡上都能直接跑。但注意extract_ifname和extract_flags的解析依赖IFLA_IFNAME和IFLA_FLAGS这两个属性在 netlink 消息里的排列不同内核版本的属性顺序基本稳定但防御性编程还是要有——解析失败时宁可忽略这条消息也不要抛异常导致线程退出。4.3 LED 硬件接口从 GPIO 到 I2C/SPI 的选择灯本身怎么控制我见过很多新手上来就买 WS2812 灯带然后用 GPIO 引脚做时序模拟。诚然WS2812 是真彩 RGB 灯带效果很好看但它的驱动对时序要求极其严格——每一 bit 要靠 800ns 级别的脉冲宽度区分 0 和 1在 Linux 用户态用普通 GPIO 去翻转引脚哪怕用nanosleep都很难做到稳定。你需要依赖libgpiod的库函数或者是 SPI 控制器来辅助否则灯的指令流很容易被系统调度打断做出来的灯条会随机闪乱色。所以我这个项目换了一个思路主灯用 I2C 接口的 AW2013 或 PCA9685 这类 LED 驱动芯片上/下行辅助灯直接用 GPIO 控制的单色 LED。AW2013 是三路恒流 RGB LED 驱动I2C 总线的时钟是 100kHz~400kHzLinux 的 i2c-dev 驱动非常成熟用户态直接 open/dev/i2c-1用ioctl发寄存器指令就能点亮。稳定性远高于手工模拟 WS2812 时序。下面是一段控制 AW2013 输出 PWM 的代码片段#include stdio.h #include fcntl.h #include unistd.h #include sys/ioctl.h #include linux/i2c-dev.h int main() { int fd open(/dev/i2c-1, O_RDWR); if (fd 0) { perror(open i2c); return 1; } if (ioctl(fd, I2C_SLAVE, 0x45) 0) { perror(ioctl); return 1; } // AW2013 初始化关闭芯片配置模式设置最大电流 unsigned char config[] {0x00, 0x01}; // 写入芯片使能寄存器 write(fd, config, 2); unsigned char led_enable[] {0x01, 0x07}; // 使能三路 LED write(fd, led_enable, 2); unsigned char pwm_red[] {0x25, 200}; // 红色 PWM 占空比约 78% write(fd, pwm_red, 2); close(fd); return 0; }之所以选择 I2C 而不是 SPI主要考虑两点一是 GPIO 口占用少I2C 只占两根线SPI 至少四根二是板子上 I2C 可以同时挂多个设备以后你加温度传感器、OLED 屏幕总线还能继续复用。SPI 的带宽高适合大量数据连续刷屏但驱动一个小灯环属实用不上。4.4 数据流整合把 Python 读数变成 I2C 命令上面 Python 负责算速率C 程序负责控制 LED那它们之间怎么通信最粗暴的做法是让 Python 直接通过system()调用 C 程序但这样每秒钟要 fork 一个新进程CPU 和电量的开销都不小。我后来用的是 Unix domain socket——Python 启动一个本地 socket serverC 程序作为 client 连上来Python 每次都把“亮度值 颜色值”通过 socket 发过去C 程序只负责解析并写 I2C。这个分离还有个额外的好处C 程序在没有 Python 控制端时可以进入自检模式开机时依次亮红、绿、蓝证明硬件链路没问题。你一个人坐在工位上排查时不需要开 Python 就知道灯板是不是好的。5. 我从调试中踩过的坑链路排查过程实录5.1 坑一网卡名变化导致读取失败我最初把网卡名写死成eth0在公司台式机和树莓派上都能跑。但换到一台 Ubuntu Server 22.04 的机器上网卡名变成了enp2s0程序直接抛异常退出。这是因为现在很多发行版用了 systemd 的可预测命名规则网卡名不再按枚举顺序来。解决方法是启动时自动扫描/sys/class/net/下所有非lo的接口取第一个有 IPv4 地址的作为监测目标。这里有个判断经验的细节不要只排除lo还要排除docker0、virbr0这类虚拟网卡否则你的总流量统计会翻倍灯显示的速率是真实流量的两倍甚至更多。我当时在带 Docker 的主机上测试时没注意docker0也走/proc/net/dev结果上行速率从 10Mbps 被算出 25Mbps排查了很久才反应过来是虚拟接口叠加计数。5.2 坑二I2C 初始化时序冲突AW2013 芯片在上电后需要一小段复位时间如果 Linux 驱动在系统启动时就把 I2C 设备 bind 好了但你的用户态程序在开机脚本里立刻去写寄存器偶尔会写失败。我遇到的现象是每次开机之后红灯都亮但绿色和蓝色有一半概率不亮。后来用示波器对比了一下发现是 I2C 总线上有设备在芯片还没退出复位时就发了写命令芯片直接忽略了。解决方法是启动脚本里加上两秒的 sleep或者干脆在 C 程序里做三次重试。我选择了重试方案因为它在程序内部自己解决不依赖外部脚本顺序for (int i 0; i 3; i) { if (i2c_write_reg(fd, 0x00, 0x01) 0) break; usleep(100 * 1000); }5.3 坑三PWM 频率和呼吸效果抖得厉害呼吸灯效果是不断调整 PWM 占空比实现的。我最初在一个独立线程里做正弦波调光每 10 毫秒改一次寄存器效果在逻辑分析仪上很平滑但肉眼看就是一顿一顿的。原因很简单——I2C 的每次写操作要 1~2 毫秒在纯 Python 里这个循环的周期抖动可以达到 ±20 毫秒PWM 的刷新频率就变得不稳定。后来我把呼吸曲线计算出的 PWM 值通过 bulk 一次性发到 AW2013 的寄存器数组里然后让它自己按硬件寄存器自动更新。AW2013 支持 breathe mode你只要设置上升时间、下降时间、保持时间等参数芯片自己就能输出平滑呼吸波形不占用 CPU也不会抖。这个改动之后灯的效果立刻通透了很多。5.4 坑四流量统计回跳/proc/net/dev里的字节数并不是严格单调递增的——网卡重启、驱动重置时可能清零某些虚拟接口的统计还会合并聚合。如果你在计算速率时发现了负数别稀奇。处理方式很简单如果当前采样值小于上一次采样值说明设备发生过重置直接把上一次值清零从当前值重新开始累积。否则那一瞬间差值会是几十 GB灯会瞬间打满然后暗掉像鬼片一样。if rx last_rx: last_rx 0 # 设备重置忽略这次差值5.5 坑五守护进程和僵死进程Python 跑久了内存会涨这个大家都懂。我做了一个监控脚本每 5 分钟检查一次 Python 进程的 RSS 内存占用超过阈值就自动重启。还用 systemd 服务把 Python 监听端和 C 驱动端管理起来Restarton-failure这样即使进程崩溃了几秒内就能自动拉起来。整个过程没有写任何手动启动脚本非常省心。systemd 服务文件的核心部分如下[Unit] DescriptionNetwork Load LED Monitor Afternetwork-online.target [Service] ExecStart/usr/local/bin/led_monitor.py Restarton-failure RestartSec5 MemoryMax50M [Install] WantedBymulti-user.target这样配置之后你下班时把它插上电它自己会跑着不需要你来维持进程生命周期。6. 进阶扩展从协议原理到更完整的网络可视化6.1 加一层 UDP/TCP 区分用 nftables 计数器前面说过初版只统计总流量。如果你想区分 TCP 和 UDP最简单的不是抓包而是用 nftables 的计数器功能。nftables 规则可以在内核直接统计匹配到的包数和字节数用户态只需要定时读取规则计数器不需要抓包。配置命令大概是这样的nft add table inet monitor nft add chain inet monitor tcp_counter { type filter hook input priority 0; } nft add rule inet monitor tcp_counter ip protocol tcp counter nft add chain inet monitor udp_counter { type filter hook input priority 0; } nft add rule inet monitor udp_counter ip protocol udp counter然后在 Python 里用nft list ruleset解析计数器数据。虽然要调起子进程但频率可以降到 2 秒一次压力不大。这比 libpcap 抓包安全、高效因为防火墙规则本来就需要 root 权限配置你也只是读取统计值不涉及包内容修改。6.2 加上端口维度映射到灯光颜色如果你想看到“某个端口流量高”就把 nftables 规则里加上tcp dport 80 counter这样的限定每个端口对应一个计数器。这样做的好处是灯的显示逻辑完全在用户态控制你只根据一组计数器的增量决定亮哪个灯。比如说 SSH 端口 22 的增量高了主灯就偏红色HTTP 的 80 端口流量高了主灯就偏蓝色。灯的配色方案由你自定义本质上是“流量拓扑的可视化编码”。这种方案在协议层面的价值在于——你不必理解 TCP 会话状态机也不用处理包重组内核已经把这些事干完了。你需要做的只是读计数器、做差值、映射到灯的颜色整个系统的时间复杂度是 O(规则数)而不是 O(包数)。6.3 从协议走向设备SPI、I2C、Modbus 的位置热搜词里提到很多协议我在实际项目中遇到的细节是这样的I2C用于连接 LED 驱动芯片、温度传感器、EEPROM最轻量的板内总线。SPI如果你想用高分辨率显示屏或者需要高速刷新点阵SPI 比 I2C 有优势。同样一片 WS2812 灯带用 SPI 的 MOSI 做时序模拟稳定性会明显好过 GPIO 翻转。Modbus这是另外一个方向当监测灯变成工业设备状态灯需要接入 PLC 或者数据采集网关时Modbus TCP/RTU 协议就成了通信链路。你可以用同一个 Linux 板子做 Modbus 从站把速率、温度、连接数等寄存器暴露出来上位机直接读。我自己后来做的事是把这块灯板挪到了一个小型 ARM Linux 设备上通过 SPI 挂了 8×8 的 RGB 点阵屏配合 nftables 计数器做了个“端到端网络负载热力图”。文本日志、隧道工具我一样没用全是 Linux 原生的网络栈加用户态解析。6.4 如果数据要可视化Web 端还是 OLED 屏有人问既然都有数据了为什么不上 web 页面我试过用 Flask 做接口、前端用 ECharts 画曲线效果确实好看。但问题是你平时不会一直开着浏览器看它。灯的优势在于被动感知——它就在那儿亮着不占屏幕不用切窗口余光一扫就知道当前负载。如果你需要事后分析数据存 SQLite 就够了完全没必要做成一个在线监控平台。另外一个进阶方案是加一个小 OLED 屏比如 0.96 寸SSD1306 驱动显示实时的数字速率灯负责直观状态屏负责精确数值。这样既有模拟时代的感知力又保留数字时代的精度。SSD1306 也是 I2C 接口你可以在同一条 I2C 总线上挂 AW2013 和它Linux 的 i2c-dev 不限制总线上的设备数量只要地址不冲突就行。7. 写在最后做完这个项目后的一点心得我来说说做这个项目前后对 Linux 网络监测这件事的理解是怎么变化的。一开始我只看/proc/net/dev觉得很简单甚至有点“没什么技术含量”。但做到后来发现真正的复杂度不在读取数据而在于你如何理解数据的层次。内核通过 netlink 暴露给用户态的契约很稳定但它背后的网络协议栈细节是丰富的——为什么有虚拟网卡、为什么统计会回跳、为什么 netlink 属性会随内核版本扩展每一个都连接着更深层的设计考虑。当你开始从协议原理解释这些现象时遇到具体问题就不会慌了。经验上有一个最终的提醒如果你打算把这个项目用在工作环境一定要在开局前就考虑好命名空间和权限。不要用 root 跑整个 Python 程序而是创建一个单独的用户只给它读取网络统计和操作 I2C 设备的权限。系统安全不是小事监测工具本身不应该成为新的攻击面。我把 systemd 服务配置成动态用户后它稳定跑了两周再没出现过权限相关的事故。至于下一步我计划在这个基础上加一个 IR 遥控器接收头用红外遥控切换显示模式——从流量模式切到温度模式、从端口模式切到连接数模式。你甚至可以用同一个 I2C 总线挂一颗红外接收器GPIO 只需要额外一根线。硬件成本不高但交互感受会完全不同这也是做这种“看得见”的项目的最大乐趣。