1 🛠️ PNETLab vs EVE-NG Pro 流量洞察功能底层架构技术白皮书
1.1 一、 核心架构设计与数据流向（Data Path）
1.1.1 1. PNETLab：死板的应用层 cBPF + 多套接字旁路监听模型
PNETLab 采用的是传统的 Linux 旁路抓包架构，数据从内核到 Web 前端经历了漫长的序列化与 I/O 搬运链条。
text
[ 网卡接口组 vnet ]
│
├─────────► [ 内核网络栈 ] ───────────────────► 正常实验流量
│ (数据包复制)
▼
[ 18+种固定规则 ] (前端死板的结构化菜单 ──► 拼装出 cBPF 字节码)
│
[ AF_PACKET Socket ] (网卡数量 × 过滤器数量 = 独立 Socket 缓冲区爆炸)
│ (高频唤醒 Python 的 epoll 循环)
▼
[ Python 守护进程 ] ──► (计算 pps) ──► [ json.dumps() ] (CPU密集型)
│ (写盘)
▼
[ /dev/shm 内存共享盘 ]
│ (HTTP 轮询)
▼
[ PHP & 前端 SVG 渲染 ]- 技术陷阱（死板且低效） ：由于 PNETLab 没有动态规则解析器，为了防止用户输入非法语句打满套接字，它在前端只提供了 18+ 种固定的协议菜单（如 OSPF, EIGRP）。Python 引擎必须为每一个监听的（网卡 ×\times× 过滤器）创建独立的
AF_PACKET套接字。在大流量下，成百上千个套接字频繁唤醒系统上下文切换，同时 Python 还要做高维度的json.dumps()写入内存盘，导致系统资源极易瞬间崩溃。
1.1.2 2. EVE-NG Pro：聪明的 cBPF-to-eBPF 混合架构与内核 Maps 零拷贝模型
EVE-NG Pro 的 Go 语言守护进程（lab-traffic-monitor）采用了一种极为精妙的混合架构：利用 libpcap 解决用户输入的易用性，利用 eBPF 解决内核执行的极限性能。
text
[ Web 界面用户输入自由文本 (如: tcp port 80 and host 10.1.1.1) ]
│
[ Go 引擎调用 libpcap (pcap_compile) ] ──► 编译为标准 cBPF 字节码
│
[ 核心转换层 (cBPF-to-eBPF) ] ───────────► 动态重构为高性能 eBPF 指令
│ (通过 Netlink libnl-route-3 注入内核)
▼
[ Linux TC clsatc / Block ] (多网卡接口统一绑定，套接字数量 = 0)
│
[ JIT 编译后的 eBPF 汇编 ] ◄──── (直接在内核层操作机器码解析 struct __sk_buff)
│
[ eBPF Maps ] ─────────────────► (内核原子锁内存计数: key=规则, value=counter)
▲
│ (bpf 系统调用直读指针，零拷贝，零序列化)
▼
[ Go lab-traffic-monitor ] ────► [ WebSocket 直达前端页面 ]- 技术优势（极致的高效与自由） ：EVE-NG Pro 动态链接了
libpcap.so.0.8、libnl-3.so和libnl-route-3.so。用户可以输入任何复杂的、标准的tcpdump语法。Go 引擎调用libpcap将其编译为 cBPF 字节码后，直接通过内核流行的 cBPF-to-eBPF 转换技术 ，将其升格为 eBPF 指令并注入内核 TC（流量控制）的共享块中。内核态直接通过eBPF Maps进行无锁计数，Go 引擎秒级直读内存指针。全链路 0 套接字爆炸、0 字符串序列化、0 磁盘 I/O。
1.2 二、 核心维度硬核技术对比
| 维度 | PNETLab (Network Watcher) | EVE-NG Pro (Traffic Filters) |
|---|---|---|
| 底层过滤技术 | 原生 cBPF ：直接依赖传统 AF_PACKET 依附过滤规则，在用户态沙箱中苟延残喘。 |
cBPF-to-eBPF 混合架构：应用层采用 cBPF 兼容生态，内核层采用 JIT 编译的原生 eBPF 执行。 |
| 规则解析自由度 | 极低：不支持自由文本输入，仅能通过前端死板的 18+ 种固定协议勾选框来拼装硬编码规则。 | 极高 ：动态链接 libpcap，支持任何复杂的标准 tcpdump 语法表达式（如：vlan 10 and ip proto 89）。 |
| 网卡扩展机制 | 笛卡尔积乘积爆炸：每个网卡对应的每个过滤器都要开辟一个 Socket。100网卡×20规则 = 2000个套接字，直接卡死。 | 内核 TC Shared Blocks ：利用 libnl-route 将所有虚拟网卡绑定至同一内核共享块，规则只跑一份，新开网卡套接字增量为 0。 |
| 数据同步机制 | 文件系统快照 ：Python 序列化 JSON →\rightarrow→ 写入 /dev/shm 内存盘 →\rightarrow→ PHP 轮询，大拓扑下刷新严重卡顿。 |
eBPF Maps 原子映射：内核态直接更新内存位图计数，Go 进程通过系统调用直接读取二进制字节流，毫无延迟。 |
| 系统资源限制 | 强行限流保命 ：通过 systemd 严格限制 Python 进程（CPUQuota=30%），一旦遭遇网络风暴直接丢弃统计包。 |
底气十足，不设上限：由于内核态 eBPF 开销通常仅占几个 CPU 周期，Go 服务常驻内存不足 30M，敢打出"毫无限制"的口号。 |
1.3 三、 两者技术优缺点客观详评
1.3.1 ⚖️ PNETLab 架构评析
1.3.1.1 🟢 优点
- 极强的安全隔离与容错（Sandboxed Units）：
PNETLab 为每个实验的监控进程拉起独立的 systemd 临时单元。虽然 Python 引擎效率低，但这种"给每个小弟戴上紧箍咒"的设计，确保了即使某个实验因为网络环路导致流量过载、监控进程 OOM 崩溃，也绝对不会波及到 Web 主进程或其他用户的拓扑，隔离性极好。
- 前端动效表现力极佳：
由于后端把大部分压力丢给了应用层和内存盘，前端得以专注做"表现层"。其 SVG 路径结合 CSS 渲染出的"蚂蚁搬家"式流量流动方向和速度，在教学演示中比 EVE-NG 更具视觉冲击力。
1.3.1.2 🔴 缺点
- 架构原罪：性能天花板极低：
受限于"网卡数 ×\times× 规则数"的套接字爆炸模型，它必须死死限制用户"最多只能开启 30 个接口和 6 个过滤器"。这种硬上限是底层 Python + 裸套接字架构无法逾越的鸿沟。
- 僵硬的规则扩展：
用户无法根据实际工程需求输入自定义过滤语句。如果你想抓取某个特定自定义端口的私有协议流量，在 PNETLab 的固定菜单里根本找不到对应选项，工具属性沦为"教学玩具"。
1.3.2 ⚖️ EVE-NG Pro 架构评析
1.3.2.1 🟢 优点
- 工程落地堪称艺术的"混合架构"：
EVE-NG 官方非常聪明地避开了"在 eBPF 中手写网络报文解析器（Hand-written Parsers）"的技术地狱。它通过动态链接 libpcap，直接白嫖了全球最成熟的 tcpdump 语法解析生态；同时又通过 cBPF-to-eBPF 转换，享受了内核级 eBPF 的神级性能。兼顾了顶级易用性与极限工业级性能。
- 真正的工业级高并发仿真：
基于 Linux Netlink 协议库（libnl）与 TC 的 Shared Blocks 架构，无论拓扑大到何种地步、规则多么复杂，底层的执行开销对 CPU 而言都只是九牛一毛。这才是真正能够支撑运营商级、大规模 Clos 架构拓扑进行真实业务压测的仿真平台。
- 零拷贝与无锁设计的丝滑体验：
内核 Maps 内存直读加上 WebSocket 的即时推送，使得 EVE-NG Pro 的流量图表和仪表盘数据绝对精准、零延迟、不丢包，能真实反映毫秒级的链路流量突发（Burst）。
1.3.2.2 🔴 缺点
- 内核绑定的维护地狱（Kernel Dependency）：
由于 eBPF 深度依赖 Linux 内核的 clsact 钩子和 BTF（BPF 类型格式），一旦 EVE-NG 底层的 Ubuntu 操作系统升级了内核版本，由于内核结构体的变动，这套精心设计的 Go + eBPF 链路极易遭遇校验器（Verifier）拒绝加载，维护成本和底层开发门槛高得令人发指。
- 黑盒调试极其痛苦：
规则在经过 libpcap 编译、cBPF 转换、eBPF JIT 三道工序后沉入内核，一旦用户输入某种奇葩语法触发了转换层的 Bug，由于运行在内核态，排查和定位故障将变成一场灾难（只能依赖 bpf_trace_printk 吐出的内核黑盒日志）。
1.4 四、 最终技术结论
- PNETLab 的流量洞察是一套"偏向前端视觉表现、通过严格限制功能（30/6 限额）来换取应用层安全"的实用教学级工具方案。
- EVE-NG Pro 则是一套"穿上了 libpcap 易用性外衣、在底层用 Netlink + eBPF Maps 疯狂堆砌吞吐量的内核级"工业仿真方案。这就是为什么它敢宣称"毫无接口与规则限制"的底层底层技术底气！
