开源坏网络模拟器Bean Network Tester：弱网故障一键注入

做网络联调的时候最怕的不是功能没写完而是功能写完了一上线才发现弱网下一塌糊涂接口超时、图片加载失败、WebSocket 频繁断连、音视频卡成 PPT。这类问题靠“正常网络”很难复现所以需要一台能主动制造故障的机器。这次我们看的 Bean Network Tester 就是干这个的一个开源的坏网络模拟器专门给应用制造丢包、延迟、抖动和带宽限制帮你把弱网问题提前暴露在测试阶段。它最值得关注的点是四个开源可自部署、规则可以灵活组合、能把常见的网络故障变成可重复的测试场景、非常轻量。它是纯网络工具不依赖显卡不需要大内存普通开发机或者一台小服务器就能跑。对做前端、后端、移动端、音视频和实时通信的同学来说这篇文章可以直接收藏。下面按部署流程来讲环境准备、启动服务、配置干扰规则、验证效果、观察资源占用最后给一套排错清单和最佳实践。部分命令和路径是通用模板实际使用时需要替换成本机项目的真实值。1. 核心能力速览能力项说明项目类型开源网络干扰/弱网模拟器开源状态开源项目发布于 Hacker News Show HN主要功能模拟丢包、延迟、抖动、带宽限制、乱序、连接异常等网络故障工作方式在网卡或网桥上注入网络规则影响经过该接口的流量硬件要求无特殊要求普通 x86/ARM Linux 主机即可操作系统优先推荐 Linux 环境依赖内核网络模块启动方式服务进程启动 Web 界面/命令行配置具体以项目 README 为准接口 API视具体版本而定可提供 HTTP 接口供自动化调用批量任务支持通过场景预设和脚本批量下发规则适合场景开发自测、联调测试、CI/CD 故障演练、性能压测辅助从资料来看这个项目最大的优势是“把坏网络变成可重复的实验”。不依赖实体网络设备不需要手动拔网线也不需要两台机器之间来回切直接用软件在协议栈层面制造故障测试完一键清理。有一点要提前说明这类工具只能用于你自己拥有的、或明确获得授权的测试环境不能对生产环境、公网服务、第三方系统做干扰测试。这个边界后面还会反复提到。2. 适用场景与使用边界2.1 适合谁Bean Network Tester 最典型的用户是这几类前后端联调工程师。接口在弱网下超时、重试、降级逻辑是否正常通过模拟 10% 丢包或 300ms 延迟就能快速重现。移动端和桌面端开发。App 在 2G/3G 网络下的表现通过限制带宽和增加抖动来模拟。音视频与实时通信开发。通话质量、推流稳定性、WebRTC 的拥塞控制都需要延迟和丢包这两个关键参数来做故障注入。后端故障演练。服务在依赖链路不稳定时熔断、限流、降级是否正确触发。CI/CD 质量门禁。在自动化流水线里加一段弱网用例每次发布前自动跑一遍。2.2 能解决的问题这类工具解决的核心问题只有一个让网络故障变得可控、可量化、可复现。假设你的应用在用户反馈里出现“视频通话经常卡”你可以在本地搭建一套测试环境把延迟设为 200ms、丢包率设为 5%然后反复重启通话、切换网络、调整码率观察应用是否有合理表现。这个过程完全可重复并且每次的参数是确定的比依赖真实弱网环境要高效得多。2.3 不适用和不允许的场景这里必须画一条清清楚楚的线不要对生产服务器做干扰测试。不要对公网域名、云厂商的 SLA 探测或第三方 API 做延迟/丢包注入。不要对你自己没有完整控制权的环境做网络干扰。未经授权不要对同事的机器、客户的网络、学校或公司的公共网段下发规则。不要用它去攻击、绕过安全机制或做任何形式的影响他人行为。它的正确用法是在一个你能完全掌控的网络命名空间、虚拟网卡或 Docker 容器里做故障注入。测试前留好清理手段测试后确认规则已撤销。3. 环境准备与前置条件3.1 操作系统优先准备一台 Linux 主机发行版不限Ubuntu/Debian/CentOS 都行。这类网络模拟工具通常依赖 Linux 内核的流量控制模块最常见的是tc和netem模块。如果项目本身提供 Docker 镜像那也可以通过容器方式运行降低对宿主机内核模块的直接操作。如果你手头只有 macOS 或 Windows建议先开一台 Linux 虚拟机或者在 WSL2 环境里测试。Windows 的 Hyper-V 虚拟网卡对流量控制支持不完整直接用可能会遇到规则不生效的问题。3.2 依赖项检查清单检查项作用怎么确认root 权限或 sudo修改网卡流量控制配置需要权限sudo -vtc命令检查链路是否支持规则注入tc -s qdisc show内核 netem 模块延迟/丢包/抖动模拟的基础modprobe sch_netemDocker可选的容器化部署方式docker --versionNode.js/Python取决于项目服务端的运行时node -v/python3 -V磁盘空间一般占用极小几百 MB 足够df -h如果modprobe sch_netem报错说明当前内核没有加载该模块。需要确认内核版本并安装linux-modules-extra之类的扩展包。不同发行版包名不同具体以当前系统的包管理器为准。3.3 网络环境测试时最好准备一个独立的网卡接口。如果你跑在本地虚拟机可以用一个独立的虚拟网络接口如果跑在容器里优先使用 bridge 网络模式这样干扰规则作用于容器网卡不会影响宿主机其他流量。临时测试可以不用独立网卡直接对当前接口操作但风险在于如果规则配置错误可能把自己 SSH 远程连接都断掉。所以“通过 SSH 远程操作时不要对管理网卡做高延迟、高丢包实验”这条要作为铁律来执行。4. 安装部署与启动方式4.1 通用安装步骤先从项目仓库 clone 代码再按 README 的说明安装依赖并启动服务。下面是通用模板# 拉取项目源码路径需要替换为实际仓库地址 git clone https://github.com/your-org/bean-network-tester.git cd bean-network-tester # 如果是 Node.js 项目 npm install npm start # 如果是 Python 项目 pip install -r requirements.txt python main.py具体是npm还是pip以项目 README 为准。启动后一般会输出一个监听地址格式类似Listening on 0.0.0.0:xxxx这个地址就是你的访问入口。4.2 通过 Docker 启动如果项目提供了 Docker 镜像部署会更干净。通用模板如下# 构建镜像 docker build -t bean-network-tester . # 启动容器端口映射需要根据实际监听端口调整 docker run -d --name bean-net \ --network host \ --cap-add NET_ADMIN \ -p 8080:8080 \ bean-network-tester特别注意--cap-add NET_ADMIN这个权限缺失会导致容器内无法修改流量控制规则。如果你看到 Operation not permitted 一类的报错优先检查这一项。4.3 启动后要确认什么服务启动不是结束启动后第一件事是确认三件事服务进程还活着没有反复重启。接口地址能访问本地 curl 能通。日志里没有权限相关报错。# 查看服务进程 ps aux | grep bean-network # 访问本地接口端口按实际日志替换 curl -I http://127.0.0.1:8080如果服务正常返回响应说明基础环境没问题可以开始配置干扰规则了。5. 功能测试与效果验证下面按“测试目的、操作步骤、预期结果、失败排查”的格式逐一覆盖核心干扰能力。这里的所有规则参数都是示例使用时以项目和本机网络环境为准。5.1 丢包模拟丢包是最常见的弱网表现。测试目的是验证应用在数据包丢失时的重传、重连和降级机制。操作方式有两种。如果工具自带界面直接建一个 rule设置丢包率 5% 或 10%如果走命令行底层通用tc命令如下# 在 eth0 网卡上引入 10% 丢包 sudo tc qdisc add dev eth0 root netem loss 10%验证方式# 从另一台机器 ping 测试机的 IP ping -c 30 192.168.1.100预期结果ping 的丢包率接近 10%响应时间会略有波动。应用侧应该能看到连接超时或重试日志。如果丢包率远低于设置值说明规则没生效或者测试流量根本没走这个网卡。排查时先看tc qdisc show是否有输出。5.2 延迟模拟延迟影响的是用户体验页面加载速度、接口响应时间、实时通话的端到端时长。# 在 eth0 网卡上引入 200ms 固定延迟 sudo tc qdisc add dev eth0 root netem delay 200ms # 增加 jitter让延迟在 180ms 到 220ms 之间波动 sudo tc qdisc add dev eth0 root netem delay 200ms 20ms验证时用ping观察往返时间ping -c 20 192.168.1.100预期看到 RTT 比基线增加约 400ms因为 ping 是来回两条链路各加一次延迟。如果配置了 jitter会发现 RTT 数值在上下跳动。应用侧观察点接口请求时间是否符合预期超时配置是否触发了重试逻辑前端 loading 状态是否有兜底。5.3 抖动模拟抖动是实时通信里影响最大的参数之一。它会导致音频断续、视频卡顿、画质自适应频繁切换。操作时设置“基础延迟 抖动幅度 相关性”三个参数sudo tc qdisc add dev eth0 root netem delay 100ms 40ms 25%这里的参数含义是基础延迟 100ms抖动幅度 40ms相邻数据包之间抖动值有 25% 的相关性。相关性越高抖动越接近真实网络的状态。验证方式用 iperf3 打流观察带宽和丢包曲线或者跑一段 WebRTC 通话看接收缓冲和分辨率变化。5.4 带宽限制带宽限制用来模拟弱网下的限速场景。最常见的验证是低带宽下图片是否懒加载、视频是否自动降清晰度、上传任务是否走分片。# 限制 eth0 带宽为 1Mbps sudo tc qdisc change dev eth0 root netem rate 1mbit验证方式用iperf3两端打流看实际吞吐是否被限制到设定值附近。iperf3 -c 192.168.1.100 -t 10应用侧验证上传一张大图看是否走了分片上传播放视频看是否自动切换低码率。5.5 乱序与连接异常乱序对 TCP 有影响对 UDP 影响更大常见于弱网环境下的实时音视频。连接异常则是直接模拟服务不可达或连接被重置用来验证应用的异常兜底逻辑。通用命令示例# 让 25% 的数据包延迟 50ms 后再发出模拟乱序 sudo tc qdisc add dev eth0 root netem delay 50ms reorder 25% # 清理所有网卡规则 sudo tc qdisc del dev eth0 root连接异常这类功能如果工具提供了开关可以直接触发如果没有通常用“防火墙丢包”或“暂停容器”的方式配合测试。应用侧预期表现是错误提示明确、自动重试机制生效、崩溃兜底可用。5.6 功能测试总结从实际测试流程看建议按下面的顺序执行先测延迟因为最简单效果最直观。再测丢包观察应用重试逻辑。然后测抖动重点看实时链路。最后测带宽限制验证自适应码率和流控逻辑。每一项测完都清理规则再做下一项。这样能保证每一次干扰只改一个变量定位问题更准确。6. 接口 API 与批量任务6.1 API 接口设计绝大多数网络模拟器都可以通过接口自动下发规则。由于不同项目的接口路径不同下面给一个通用调用模板实际使用时需要用项目文档里的真实路由替换。# 通用 POST 接口示例路径和端口需要按实际项目调整 curl -X POST http://127.0.0.1:8080/api/scenario \ -H Content-Type: application/json \ -d { target: eth0, loss: 10, delay_ms: 200, jitter_ms: 20, bandwidth_mbit: 10 }如果项目支持删除规则通常是对应一个 DELETE 接口# 清理规则 curl -X DELETE http://127.0.0.1:8080/api/scenario注意调 API 之前先确认目标网卡没有在跑重要业务流量。一旦规则下发影响会立刻生效。6.2 Python 批量任务示例批量任务的典型使用方式是把多个场景串起来按顺序执行并输出结果。下面这个 Python 脚本是通用模板它的逻辑是先并发下发三个场景等待几秒然后清理。import requests import time BASE_URL http://127.0.0.1:8080 scenarios [ { name: mild, loss: 1, delay_ms: 50, jitter_ms: 5, }, { name: medium, loss: 5, delay_ms: 150, jitter_ms: 20, }, { name: severe, loss: 15, delay_ms: 400, jitter_ms: 80, } ] for sc in scenarios: response requests.post(f{BASE_URL}/api/scenario, jsonsc, timeout5) print(f{sc[name]}: {response.status_code}) # 每个场景保持一段时间方便应用侧观察 time.sleep(10) # 测试结束统一清理 requests.delete(f{BASE_URL}/api/scenario, timeout5) print(cleanup done)6.3 批量任务注意事项批量任务真正的价值不是同时制造大量故障而是让多个测试环境共享同一套“故障模板”。推荐做法是把一个场景定义为一个 JSON 文件入库到测试方案仓库。每次 CI 跑批之前先清理所有旧规则。每个场景执行完自动记录应用侧指标如成功率、延迟分位数、错误码分布。失败时先检查规则是否生效再检查应用日志。另一个关键点是做失败重试。网络测试本身有波动一次失败不代表应用有问题。建议在每个场景上设置重跑次数例如每个场景连续跑三次两次以上失败才标记为回归问题。7. 资源占用与性能观察7.1 工具本身的开销Bean Network Tester 这类工具本身的资源占用很低。它只是在协议栈层面配置规则不做数据包代理也不转发流量所以 CPU 和内存消耗可以忽略。部署在 1 核 1G 的轻量服务器上完全没有问题。真正需要关注的是干扰规则生效后对被测应用性能的影响。这个影响正是你想要的但要把“工具开销”和“干扰效果”区分开。7.2 怎么观察资源占用观察宿主机和被测服务的资源占用用这几个命令就够了# 查看 CPU 和内存 top # 查看网络流量 nload iftop # 查看网卡错误和丢包统计 ip -s link show eth0 # 查看当前流控规则 tc -s qdisc show dev eth0在测试时每秒记录一次被测服务的响应时间、错误率、重传率对比有无干扰规则时的差异就能量化故障造成的影响。7.3 干扰参数对效果的影响参数影响调整建议丢包率连接成功率、重传次数先 1% 再 5% 再 10%逐步加压延迟接口耗时、RTT100ms 起步根据业务容忍度调整抖动实时链路稳定性配合延迟一起调整带宽吞吐量、自适应码率1Mbit 到 10Mbit 之间做梯度批量数规则下发的并发压力一般不需要超过 5 个场景同时生效一个常见误区是把丢包率和延迟同时设到极端值导致应用直接不可用无法定位到底哪个因素造成的。更合理的做法是逐项调整记录每项的效果。7.4 降低测试干扰风险的方法如果测试环境是远程服务器可以通过这几项操作降低风险不要在管理网卡上做高丢包实验。所有规则设置一个自动过期时间或用脚本在 N 秒后清理。测试前保存当前规则的快照出问题可以一键回滚。尽量在 Docker 容器或网络命名空间内测试隔离到独立接口。8. 常见问题与排查方法问题现象可能原因排查方式解决方案规则下发后没有效果网卡接口选错了tc qdisc show dev eth0确认规则挂在哪个接口换到实际流量的网卡接口报 “Operation not permitted”权限不足或容器缺少 NET_ADMIN查看服务日志和启动方式用 root 运行或给容器增加 NET_ADMIN 权限启动后提示缺少内核模块sch_netem 模块未加载modprobe sch_netem测试安装 linux-modules-extra 并重启加载高延迟时 SSH 断连对管理网卡做了干扰用另一个终端登录检查规则清理规则后续只对非管理接口操作端口冲突服务默认端口被占用ss -tlnp查看端口占用情况修改启动配置或杀掉占用进程清理规则后依然有延迟/丢包多路径或多层网络设备叠加在测试机上逐层检查 tc 规则和路由器配置清理所有 qdisc并检查链路中其他设备API 调用返回 404接口路径不是项目默认路径查看项目文档的接口定义替换为正确的路径批量任务跑到一半卡住场景数据量过大或并发过高查看应用日志和资源占用减少并发场景增加超时和重试容器内规则正常宿主机流量不受影响Docker 网络模式隔离确认容器运行方式和网卡连接方式改用 host 网络模式或直接对宿主机接口配置规则在重启后失效qdisc 规则没有持久化重启后tc qdisc show查看写启动脚本自动恢复规则这里重点提示两个最容易踩的坑第一个是接口选错。你配置规则时觉得“明明下发了怎么没效果”实际可能是流量走的是 eth1你配置的是 eth0。先用ip route get 目标IP确认数据包真正走哪张网卡。第二个是权限问题。很多网络模拟工具在普通用户下无法加载内核模块启动时不会立刻报错但配置规则时才会失败。日志里出现 Operation not permitted 时优先检查运行用户的权限和容器的cap-add配置。9. 最佳实践与使用建议9.1 建立测试环境基线使用干扰工具之前先在没有干扰的条件下跑一遍完整业务记录延迟、丢包、吞吐的基线数据。基线的意义在于干扰后的指标和谁对比、优化效果如何衡量都需要数字支撑。9.2 场景模板化把常见弱网场景固化成配置模板而不是临时手工调整参数。推荐的模板包括场景名延迟丢包抖动带宽用途弱网-轻度80ms1%10ms10Mbit日常自测弱网-中度200ms5%30ms2Mbit联调验证弱网-重度500ms15%80ms500Kbit故障演练无响应1000ms50%200ms100Kbit极限兜底测试模板文件建议纳入版本管理每个模板说明适用场景和预期影响团队成员共同维护。9.3 自动化集成如果项目提供了 API可以把弱网测试接入自动化流水线。推荐的流程是先执行单元测试和功能测试。再拉起测试环境下发弱网场景。跑冒烟用例和应用层性能测试。记录指标与基线对比。退出前清理所有规则。这样做的好处是每次发布前都能自动化覆盖“弱网兼容性”这一维度不用等用户反馈。9.4 合规与安全使用最后再强调一次安全边界这个工具只能用于你拥有或已获得授权的测试环境。禁止在生产环境、公网服务、第三方系统、未经授权的网络设备上使用。测试前要确保不会影响到其他业务测试中要有专人盯着测试后要确认规则完全清理。任何形式的网络干扰行为都要在权限范围内执行。9.5 输出结果管理测试产生的日志、指标、截图建议统一存放。比如按日期和场景名建立目录./test-results/ 2025-01-15/ mild/ app-logs/ network-metrics.csv summary.json severe/ app-logs/ network-metrics.csv summary.json这样事后复盘时可以准确知道某个问题是在什么网络参数下出现的修复后又能用同一场景回归。10. 总结与下一步Bean Network Tester 是一个值得放进测试工具箱的开源网络模拟器。它解决的问题很具体用可控、可重复的规则注入让弱网问题在开发阶段就暴露出来。它不复杂也不吃硬件轻量到一台小服务器就能承载完整的故障注入场景。最先建议验证的功能是延迟和丢包模拟因为这两个参数最能体现弱网问题的根因也最容易观察效果。最容易踩的坑是“接口选错”和“权限不足”测试前先把这一点检查清楚后面会顺利很多。如果你正在做前端页面、后端接口、移动端 App、实时音视频或者 IoT 相关的开发调试可以先用它跑一遍基础弱网场景看看应用的表现是否匹配预期。后续值得继续深化的方向是把场景模板接入自动化 CI形成持续回归能力再叠加多节点、多链路组合故障模拟更接近真实弱网环境的情况。这类工具的最终价值不是“能把网络搞坏”而是“能在可控范围内把网络搞坏再用测试结果把应用修得更稳”。下一篇文章可以围绕具体的接入案例展开例如怎么把弱网模拟器嵌入 Webrtc 通话质量测试流程欢迎收藏备用。