Bean Network Tester 是一款开源的坏网络模拟器。所谓坏网络并不是指网络完全瘫痪而是指我们日常会遇到的延迟变高、丢包增多、带宽变窄、网络忽快忽慢等情况。这个工具的核心用途就是人为制造这些网络劣化条件让你在本地开发或测试环境里稳定复现真实用户遇到的弱网问题。如果你在做后端服务、移动端 App、Web 前端或者负责接口联调和线上问题排查这个项目值得你花一个下午跑一遍。它不是压测工具也不是监控工具更像一块可控的“网络刹车片”。下面我按实际使用顺序来拆先想清楚需求再准备环境然后跑通最小实验最后接入自动化流程。1. 先想清楚你缺的是弱网环境不是网络优化工具1.1 为什么真实弱网场景最难复现很多团队最初验证弱网问题靠的是带着手机去地铁、电梯或者信号差的地方。这种做法的最大问题是结果不稳定。同一个页面今天可能是因为网络延迟变成 3 秒明天可能是因为信号弱直接请求失败。你很难确定应用表现到底由哪个网络指标决定也无法在修复后做一次完全一致的回归验证。对于测试人员来说这种不可复现性是致命的。你提交了一个缺陷开发修完之后需要用相同的网络条件重新验证但真实网络无法精确还原。所以开发者会想办法把网络条件抽象成具体参数延迟多少毫秒、丢包多少百分比、带宽限制到多少 Mbps、网络抖动多大。只要这些参数可以调节并且能在测试结束后恢复问题就变得可控。1.2 Bean Network Tester 的定位Bean Network Tester 解决的是“如何把网络环境变差并且让变差的过程可控、可重复”这件事。它作为开源项目出现在技术社区最初是以 Show HN 的形式展示面向的是需要在开发阶段验证应用鲁棒性的工程师。这类工具通常包含几个关键能力指定要影响的网络接口或者目标地址设置延迟、丢包、抖动、带宽等参数启动模拟和停止模拟输出运行状态或者日志方便确认是否生效和直接修改系统网络配置相比使用现成模拟器的好处是恢复更干净也更容易沉淀成配置文件和测试脚本。你不需要记住一堆底层命令只需要维护一套网络场景参数即可。1.3 网络模拟器的通用能力清单不同的网络模拟器能力边界不一样但基本都会覆盖下面这些维度。你可以拿这份清单去对照 Bean Network Tester确认它支持哪些不支持哪些。能力维度说明常见验证方法延迟模拟网络往返时间增大ping 或者 curl 耗时丢包模拟数据包在传输过程中丢失ping loss 统计、请求失败率带宽限制模拟出口或入口带宽变小大文件下载、上传耗时抖动模拟延迟忽高忽低网络不稳定连续 ping 的延迟波动连接中断模拟网络闪断、直接断开观察重连和错误处理逻辑协议过滤只影响 TCP、UDP 或特定端口指定端口测试建议你拿到项目后先不急着配置参数而是打开文档看它的能力清单里有没有这些维度。如果支持再继续深入。2. 动手之前先理解网络故障对应用的真正影响2.1 延迟和超时之间的矛盾我见过不少后端服务在正常网络下一切正常但用户反馈“接口经常超时”。原因往往很简单代码里设置的超时时间太短没有把网络延迟余量算进去。当你给网络增加 200ms 延迟时一次原本需要 500ms 的接口请求可能就会变成 900ms。如果客户端设置的超时是 1 秒仍然能通过如果超时是 800ms就会开始失败。这类问题必须通过实际制造延迟才能暴露出来靠代码审查很难发现。所以在使用模拟器时第一组参数应该从延迟开始。先加一个固定延迟再用 curl 观察耗时变化然后对比应用的超时配置你会发现很多边界问题。2.2 丢包对 TCP 和 UDP 的差异化影响丢包是另一个容易引起误解的参数。很多人以为丢包就是请求失败实际上 TCP 协议会自动重传不会直接失败但重传会带来额外的延迟和乱序。后果是请求变慢而不是立刻报错。如果丢包率较高应用内部的重试逻辑还可能叠加放大延迟。UDP 场景则更直接比如视频通话、实时白板、游戏对战。即使丢包率只有 1%画面也可能出现卡顿。这些应用通常需要实现前向纠错、丢包重传或者画质降级策略但做得怎么样光看代码不够必须把丢包率调到 5%、10%、20% 分别测试。2.3 带宽限制对前后端性能的隐藏影响带宽限制对单次小请求影响不大但在两个场景下非常致命一是涉及大体积资源二是涉及大量并发请求。前端页面里的图片、视频、大 JSON 响应在窄带宽下会加载得很慢。这时候前端的懒加载、图片压缩、接口响应压缩就有意义了。后端如果在返回大文件时没有考虑分块或者流式传输窄带宽下很容易出现连接占用过久、线程池被占满的问题。模拟带宽限制时建议把带宽设置成略低于业务设计最低值比如移动端设计目标是 2Mbps就可以把它限制到 1Mbps 甚至 512Kbps。看应用是否还能正常完成主要流程。2.4 连接中断和应用自愈能力比网络慢更麻烦的是网络断开然后又恢复。很多应用在连续请求失败后不会主动重连也不会补拉断开期间的消息。这通常要等用户手动刷新或者重新登录才能恢复。网络模拟器可以很好地模拟这种场景启动时延迟 丢包运行一段时间后完全断网再恢复。观察服务端的连接管理、客户端的重连逻辑、消息是否补偿就能发现不少稳定性缺陷。3. 最小实验怎么跑从启动到确认参数生效3.1 环境准备网络模拟器最好在你能完全控制的机器、虚拟机或者容器里运行。Linux 是首选因为修改网卡参数、控制网络接口的能力最完整。macOS 通常也有方案可用但兼容性需要逐个确认不同系统版本的表现可能不一致。Windows 环境要看项目是否提供原生支持如果只是学习建议优先在 Linux 虚拟机里跑通。在下载项目之前先确认这几样东西系统是 64 位内核版本不要太老有管理员权限或者 root 权限因为修改网络参数普遍需要权限确认要测试的应用能够被访问比如本机服务或者容器内的服务准备一个简单的 HTTP 接口用来做延迟验证如果是第一次使用开源工具我建议先读 README不要跳过。很多问题其实都写在文档里比如依赖版本、系统限制、参数支持情况。跳过文档直接跑大概率会在启动阶段卡住。3.2 第一次启动和参数设置开源项目跑通的第一步是查看帮助信息和当前网络接口。以常见命令行网络模拟器的写法为例大概会是这样bean-network-tester --help bean-network-tester --list-interfaces具体参数名以 Bean Network Tester 的项目文档为准但思路是一致的先看有哪些接口再选择要控制的接口。如果你要测试的服务跑在本机可能还要确认是控制回环接口还是物理网卡。如果应用通过 localhost 访问而你把模拟器挂在物理网卡上模拟不会生效。第一组参数建议不要开得太极端。比如先设置 200ms 延迟、5% 丢包# 示例参数仅说明通用命令风格实际以项目文档为准 bean-network-tester --interface eth0 --delay 200ms --loss 5%设置完成后不要直接去看应用页面。先用独立的工具验证模拟器是否真的工作用ping看延迟是否增加到 200ms 左右用ping -c 50看丢包率是否接近 5%用curl -o /dev/null -s -w %{time_total}看接口整体耗时如果这些独立验证结果符合预期说明模拟器生效了再进入应用测试。3.3 不同接口和协议的影响范围第一次测试成功后要特别注意影响范围。有些模拟器默认作用于整个网卡那么该网卡上所有流量都会受影响有些支持按照目标 IP、端口或者协议类型过滤。为了不把环境搞得不可控我建议一开始就限定范围。如果你只测试某个后端接口就按 IP 和端口限定如果测试的是整个移动端 App 的弱网表现那可能需要限定到 App 使用的域名或者 IP 范围。判断标准很简单测试过程中SSH 会话不要卡死测试机本身不要失联。如果模拟参数把管理连接也影响了说明影响范围没有控制好。3.4 测试结束后如何恢复很多人忽视恢复这一步。模拟器如果正常退出一般会自动恢复网络参数但如果进程崩溃参数可能残留导致后续所有网络请求仍然很慢。稳妥做法是每次实验后主动确认恢复# 以通用命令风格示例 bean-network-tester --restore ping -c 3 www.example.com如果 ping 的延迟恢复到正常水平说明环境已经干净。想让整个流程更自动化可以在脚本里加上结束清理操作比如使用trap指令在脚本退出时强制恢复网络。4. 从单次手动测试到自动化接入测试流程的正确方式4.1 把网络场景固化成配置文件手动设置参数适合验证想法一旦进入正式测试就应该把网络场景固化下来。比如可以维护几个命名场景正常网络、弱网地铁、公共 Wi-Fi、断连恢复。每个场景包含一组固定参数测试前一键加载测试后关闭。这样团队里任何人跑测试得到的都是同一套网络条件结果才有可对比性。示例配置结构大概是这样# 示例场景配置 scenarios: weak_metro: delay: 300ms loss: 10% bandwidth: 1Mbps jitter: 50ms duration: 60s public_wifi: delay: 150ms loss: 3% bandwidth: 5Mbps jitter: 30ms duration: 60s实际字段以工具支持为准但思路是通用的把网络参数从命令行参数变成可维护的文件再和测试用例绑定。4.2 组合多种故障模型实际用户遇到网络问题很少是只有延迟或者只有丢包。更多时候是延迟升高伴随少量丢包同时带宽很不稳定。所以测试用例设计要从单一参数逐步转向组合场景。比如“弱网地铁”通常是高延迟 中等丢包 低带宽“公共 Wi-Fi”是中等延迟 少量丢包 带宽波动“电梯场景”是短时间断连 延迟急剧升高。组合参数跑完后不仅要看功能是否可用还要看应用是否采取了降级策略比如降低图片质量、切换备用接口、进入离线模式。没有这些策略的应用在组合场景下问题会暴露得特别快。4.3 记录结果时打包日志和参数网络模拟的测试结果不能只记录“通过了”或者“失败了”。建议每个测试用例至少记录这些内容使用的场景名称和参数组合测试时间、持续时长请求成功率、平均耗时、P95、P99 耗时服务端日志和客户端日志网络模拟器本身的运行日志这样做的目的是为了让后续回归测试能够精确复现。如果只是随便跑一下失败后排查会非常被动。4.4 在 CI 里运行要注意隔离如果要把网络模拟接入持续集成流程有一个重点不要直接跑在共享构建机上。原因是修改网络参数通常需要管理员权限而且会影响整个网卡的所有流量。构建机上的其他任务可能会被一起拖慢甚至直接失败。更稳妥的做法是把网络模拟测试跑在独立容器里或者单独分配一台测试机。配置好网络场景后再让 CI 任务通过脚本启动和恢复。5. 遇到问题时不要急着调参数先按这个顺序排查5.1 先确认模拟是否真的生效最常见的现象是设置了模拟参数但应用表现毫无变化。这时候不要急着加大参数先从头验证。先检查流量是否真的走了你设置的接口。回环地址和物理网卡是两条路径容器内外也是不同的网络命名空间。很多模拟器默认只影响物理网卡不会影响 localhost 访问。其次要检查新连接和已有连接的区别。有些网络参数只影响新建连接如果应用在运行期间复用长连接旧连接可能不受影响。可以先断开应用连接再重新发起请求。5.2 再看权限和依赖修改网络参数普遍需要 root 权限或者管理员权限。如果权限不足设置可能被静默忽略表面看起来没有报错实际没有生效。在 Linux 系统上某些网络模拟依赖内核模块比如netem、tbf、htb等。如果模块没有加载或者系统内核不支持参数同样不会生效。排查时可以用lsmod查看模块是否加载如果缺失先解决模块问题再继续测试。这里要强调一点日志里没有报错不等于配置已经生效。一定要用 ping、curl、iperf 这类独立工具做二次验证。5.3 检查单位、格式和参数边界网络参数经常因为单位写错导致结果完全不对。延迟单位是毫秒还是秒丢包率是 0.05 还是 5%带宽缩写是 Mbps 还是 MBps这些细节影响很大。在写配置时建议先跑一个“极端值”测试确认参数的边界行为。比如延迟设置成 10ms再用 ping 验证设置成 1000ms再验证一次。如果两次结果都符合预期说明参数单位理解正确如果结果和预期相差好几个数量级大概率是单位或者格式理解错了。5.4 用基线测试过滤隐患排查到最后如果仍然不确定问题来自应用还是模拟器最有效的方法是做一次基线测试。先把网络恢复成完全正常状态跑一遍应用记录正常耗时和成功率。然后只加一个单项故障比如只加延迟再跑一遍。确认结果差异后再加第二个参数。通过这种逐步叠加的方式能定位到具体是哪个网络因素触发了问题也能过滤掉应用自身条件变化带来的干扰。6. 聊聊使用边界和我的建议6.1 这个工具适合做什么不适合做什么Bean Network Tester 归根结底是一个开发测试工具适合在测试环境里模拟真实用户可能遇到的弱网情况。它可以帮助你提前发现超时设置不合理、缺少重试机制、弱网下 UI 卡顿等问题。但它不是压测工具。它并不会模拟大量并发用户也不会制造请求洪峰。如果需要做性能压测应该选择专门的压测工具两者结合使用。它也不适合直接跑在生产环境或者用于干扰非测试目标的网络。作为技术人员我们要在合法合规的前提下使用工具这样才能持续积累经验。6.2 我自己会更倾向于怎么用拿到任何一个新的网络模拟器我建议先跑最小实验不要直接上复杂场景。最小实验的目的是验证工具在你的系统上可用参数能生效恢复也正常。这一步通常只需要十几分钟。跑通之后再把常用的网络场景固化成配置文件比如弱网地铁、公共 Wi-Fi、断连恢复。以后每次测试直接加载配置文件不用每次手工设置。最后再考虑接入 CI 或者自动化测试流程。接入之前一定要先确认网络模拟的恢复机制是可靠的否则一旦模拟器崩溃后续所有网络请求都会受到影响排查起来非常痛苦。6.3 真正值得长期关注的不是工具本身使用开源网络模拟器最值得关注的不是它的界面多好看也不是参数有多丰富而是它能不能稳定地在你需要的系统环境里运行并且能够和你的测试流程很好地配合。如果你是做服务端稳定性的可以多关注协议级别的模拟能力以及是否支持按 IP、端口、协议过滤。如果你是前端或者移动端工程师可以关注它是否方便和现有 UI 自动化、接口测试框架集成。只要先把单条网络场景跑稳再逐步扩展这类工具能帮你省下大量靠真实弱网环境碰运气的时间。