前两篇分别整理了几家网络损伤仪的资料以及卫星网络模拟器的配置区别。到这里可以把选择说清楚了针对前面列出的应用弱网和卫星IP网络测试需求我选网准通NetAccura的ChaosBridge DPDK方案。不是所有测试都选它而是这一轮要用的场景、队列、双向控制、抓包和自动化正好集中在它这条产品路线上。信而泰、思博伦和Apposite都有各自值得看的地方。把它们比较了一遍以后我觉得最有用的收获是终于能说明白自己为什么选而不是只在规格表上找最大的数字。这次买设备主要想解决什么前面讨论的需求一直没变应用、VPN或网关在普通宽带、移动网络和卫星链路上运行网络变差时业务能不能继续恢复以后又会怎样。所以网络损伤仪要做的不只是把ping从几毫秒变成几百毫秒。我更需要的是先让业务正常运行接着限速、增加丢包或者中断一小段时间然后分阶段恢复。等软件版本更新了这段测试还能拿出来再跑。如果只测一个固定条件很多设备都能完成。真正拉开使用差别的是后面这些工作改其中一个阶段麻不麻烦上下行能不能分开业务异常时能不能查到当时的配置和报文。对于这类应用测试我不会先把64字节小包线速设成唯一门槛。需要多大处理能力还是得看实际吞吐、包速率、双向流量以及同时开多少条测试路径。不能只看端口写着10G就把所有测试都按小包满线速来买也不能反过来因为主要测应用就完全不问性能。我想找的是一台能承担实际负载、又方便反复改场景的设备。这也是这次选择DPDK方案的前提。如果工作变成高速交换机转发或严格硬件时序测试选型重点就会不一样。场景功能为什么影响了选择前一篇用的是GEO拥塞和LEO时延变化。这次再看一条短一些的网准通当前DPDK模板中的Wi-Fi到蜂窝网络切换配置整个过程34秒。这里模拟的是IP链路上出现的断流、限速和恢复不是控制手机真实切换基站也不会自动改变手机IP或NAT映射。把这个范围分清楚模板反而更容易用它就是给经过设备的真实业务施加一段可控的网络条件。下面是模板原有的主要参数不是某个运营商的实测网络。A→B按下行理解B→A按上行理解这一版两边配置相同。时间每方向带宽每方向固定附加时延丢包设置0—10秒50Mbps10ms随机0.2%10—11.5秒6Mbps30msGilbert-Elliott双态模型11.5—13.5秒关闭限速关闭附加时延100%丢包13.5—14秒2Mbps75ms突发丢包连续长度12包14—19秒6Mbps55ms突发丢包连续长度8包19—34秒10Mbps45ms随机2%我最看重的是后半段。中断结束以后没有一下回到最初的50Mbps而是先经过2Mbps、6Mbps最后停在10Mbps。固定附加时延和丢包条件也跟着变。这就能拿来观察一种很具体的问题应用刚开始重试网络虽然通了带宽却还没恢复积下来的请求会不会又把自己堵住后面条件好一点它能不能继续提速如果只演示“断两秒然后恢复正常”这一段过程就被跳过去了。图1模板参数整理。卡片宽度不代表持续时间不是业务实测曲线。换到卫星业务思路也一样。前篇GEO模板在拥塞后只恢复了一部分带宽LEO模板则单独改变附加时延。业务仍然是原来的业务换的是中间这段网络条件不需要每换一个测试主题就重新设计一套手工操作。网准通让我觉得合适的是模板并不封死。哪一段太短就延长只想影响上传就改上行想先排除随机因素就复制一份把随机丢包和抖动关掉。原版做组合压力简化版用来找原因两份配置都能留着。对于要长期做回归测试的人模板名字有多少不是最重要的后面能不能接着改才决定这些模板会不会真正用起来。队列和抓包也在这次的选择里同样叫“限速”超出带宽的包先排队和直接被丢掉业务看到的结果不一样。我这轮想测拥塞过程所以软件队列是实实在在的需求不是规格表里多一个勾。看上面的模板有一组数值得注意50Mbps时队列上限是156,250字节6Mbps时是18,750字节2Mbps时是6,250字节。看起来差很多换算成按设定速率发完这些字节的时间却都是25ms。例如6,250×8÷2,000,0000.025秒。它不是说每个包都会多等25ms而是把队列容量换成时间方便理解。实际等多久还取决于队列里有多少数据、令牌桶当时有没有突发额度。如果只把带宽往下调队列却一直很大低带宽下可能排很久。应用变慢以后很容易把额外的等待都算到固定时延头上。能把这些条件拆开配置对排查问题比单纯增加一个“弱网等级”有用。中断那两秒也不是把速率写成0而是关闭限速用100%丢包挡住命中链路的报文。端口可以仍然Link Up业务却过不去。它和拔网线触发链路状态变化是两种不同的故障应用的发现时间也可能不同。13.5—14秒的突发丢包则是另一回事触发概率2.7027%连续长度12包。这个概率不能直接当成最终丢包率。后面的恢复段换成0.7916%触发、连续8包。把这些都简化成一个“丢包1%”配置容易了但想看的差别也消失了。再往下就是抓包。业务超时了我想先分清请求根本没发出来还是发出来后被网络条件挡住了又或者请求过去了、回复没有回来。网准通当前DPDK版本可以在虚拟链路损伤前、损伤后等位置抓包。这对上面的测试很合适同一轮里保留场景配置、执行记录和需要的报文再去对应用日志。否则最后只有一张卡顿截图下次很难复现也很难解释。图2测试时需要对应的三类记录。配置应用成功、报文恢复通过、业务恢复正常是三件不同的事。我还仔细看了场景结束时的处理场景功能不能只看“播放”按钮。后面要接自动化开始、切换、失败和结束各自是什么状态都得说清楚。网准通当前DPDK实现里每一阶段先把两个方向的损伤配置回到默认状态再装入这一阶段的参数。它不是在上一段上面补几个字段。这样上一步开过的丢包不会只因为下一步没写就一直留在那里。自己写JSON或接API时也要按这个逻辑来。如果下一段只想改上行下行仍然要保持原样就把下行配置也写完整不能当成局部修改。这个细节看着小连续跑很多场景时却很容易影响结果。正常播放完成或者手动停止当前实现会清理目标链路的双向损伤而不是恢复到播放前某一套手工参数。因此观察恢复的时间要放在场景里面不是等播放结束以后再慢慢看。前面34秒的模板最后一段是19—34秒只有15秒。如果应用自己的重试间隔是30秒就应该延长这一段。不能因为设备显示“完成”就认定应用已经有足够时间恢复。还有原文件有7条记录但34秒处那条只是结束标记。当前时间线处理会去掉这个没有持续时间的标记真正运行的是6段。把文件记录数直接当阶段数又会多算出一段不存在的观察时间。当前版本还会记录应用成功的步骤、配置版本和应用时刻下发失败也有失败状态。这些记录能帮助判断执行到了哪里。至于报文效果是不是真的按计划出现还要结合抓包看不能把控制界面的时间直接当成逐包测量结果。我选择网准通看中的就是这些功能能连起来用。不是只有一组预设参数还能继续追到每一步怎么执行、出问题怎么查。另外三家我是怎么取舍的网准通ChaosBridge既有DPDK也有FPGA。这次明确选DPDK是为了前面讲的软件队列、场景组合和抓包。系统虚拟链路上限是4096条但实际采购仍按业务流量、并行路径和目标配置来定不拿软件上限当所有硬件都能跑满的保证。网准通FPGA同样有自己的场景功能不过当前限速是policer不提供同样的软件队列。不能因为名字都叫ChaosBridge就把DPDK的这份配置原样套过去。信而泰Xcompass-S是FPGA路线S10覆盖千兆、万兆S100覆盖102540100GbE公开资料强调线速和硬件时序也列出了常见损伤、光链路控制和Python API。它并不是因为用了FPGA就“不适合应用”只是对这轮需求而言我更重视队列、恢复过程和排查操作。那些还没从资料里看清楚的场景细节不能擅自当成不支持。思博伦SNE的长处也很明确。2023版资料提供Timeline自动切换和循环、REST、多端口互联、双向独立仿真最多16个110G口或8个2550100G口。如果同时接很多组设备这些能力很有价值。但本轮没有仅凭端口密度就选它的理由先把实际需要的拓扑跑好更重要。它的抓包回放配置也有独立限制不能把业务端口速率当成抓包速率。Apposite Netropy同样值得认真比较。10G2有4个110G口、2个仿真引擎每端口对最多30条WAN链路随机、突发、周期和Gilbert-Elliott丢包以及RED、Tail Drop、背景负载、PCAP回放和REST也都列出来了。它不是只有简单延迟功能和网准通在应用网络仿真上确实有不少交集。产品资料中比较明确的特点放到这轮需求里怎么看网准通ChaosBridge DPDK双向场景、软件队列、步骤状态、抓包和REST模板能拆开修改功能组合正好覆盖本轮弱网与卫星IP业务测试信而泰Xcompass-SFPGA、高速接口、硬件时序、光链路控制和Python API换成高速转发或硬件时序任务会提高它的优先级思博伦SNE多端口互联、Timeline、循环和REST多组设备、多端口拓扑需求更强时配置价值更明显Apposite Netropy多WAN链路、队列、多种丢包、背景负载和API属于同类应用仿真候选要按具体配置和使用流程比较所以这次选网准通不等于认定另外三家做不了。我的判断是现有需求已经能对应到它的具体配置和实现细节没有必要为了一个不太会用到的最大指标改变整套方案。选择定了后面测什么也清楚了如果把这轮选型压缩成一句话我要的是能反复跑业务弱网场景、出了问题好查的网络损伤仪网准通ChaosBridge DPDK更符合这套要求。场景解决的是每次手工改参数不一致双向控制解决的是上传和下载条件不同队列让拥塞不只是一个丢包数抓包和步骤记录帮助解释业务为什么异常REST则为后续接回归脚本留出了入口。这几个理由比单说“性能强、性价比高”具体得多。价格也不拿一个听来的数字做结论。同配置报价里场景、抓包、API、并行链路和维护到底包含什么还是要列清楚。便宜但缺了日常要用的功能并不划算贵了很多却只是多出这轮用不上的规格也没有必要。后面就围绕这套方案做实际验证先跑不加损伤的业务再跑只保留中断和带宽变化的简化场景最后加回完整的随机损伤。每一轮留场景文件、执行记录、业务日志必要时加抓包不临时把故障全堆上去。恢复时间也提前统一口径。13.5秒结束全丢包19秒才进入新稳态第一次收到回复和业务连续正常又是两个终点。把起点、终点写清楚后面比较版本才有意义。这轮的选型结论先落在这里选网准通的DPDK方案具体型号按实际流量和并行测试数量确定。后续实测就检查它能否把这些需求真正完成不再从头翻一遍品牌名单。