上一篇把过滤器和抓包的用法整理了一遍。这篇接着写场景回放让带宽、时延和丢包按时间变化存下来下个版本继续用。网准通NetAccuraChaosBridge 混沌之桥 WE-101 的 DPDK 场景可以分别配置上下行比一边看会议画面、一边手工改参数更适合做版本对照。不过阶段怎么填写、结束后留下什么状态都得先弄清楚。我们买的是 WE-101-N4G测试对象还是用于卫星通信的视频会议软件。这篇整理设置方法下面三分钟的参数是我设计的一条基础用例不是某条卫星线路的实测数据。它先把问题缩小到一件事上传带宽变小中间又短暂不通恢复以后应用怎么处理。先做一条三分钟的场景我不想第一条就把雨衰、抖动、乱序和随机丢包全加上去。现象一多反而不容易判断。先保留明确的带宽变化和一段上行全丢包等这条用例解释得通再往上加条件。这里约定终端接 A 侧服务器方向接 B 侧。A→B 是终端上传B→A 是终端下载。不是所有现成模板都按这个方向命名套用之前先看描述。五个阶段安排如下。时间从本次场景开始计算区间左端包含、右端不包含。时间持续多久上传 A→B下载 B→A这一段看什么0—30秒30秒4Mbps不额外丢包8Mbps不额外丢包参考网络条件下的业务状态30—90秒60秒800kbps不额外丢包保持8Mbps上传受限后的发送调整90—91秒1秒保留800kbps丢包100%保持8Mbps上行短暂中断时的业务反应91—120秒29秒800kbps取消额外丢包保持8Mbps网络通了但上传仍然受限120—180秒60秒恢复4Mbps不额外丢包保持8Mbps带宽恢复后的业务表现五段里上行固定附加120ms下行固定附加60ms都不改变。抖动、乱序、重复和背景流量先关闭。这里刻意把时延固定住是为了先观察带宽和中断不把所有变化混在一起。带宽模式统一用漏桶队列用尾丢弃上行明确填20000字节下行填60000字节各阶段保持一致。数值不是给所有会议软件的推荐值而是把这份用例里的条件写全换人执行时不用再猜。表里的“不额外丢包”只表示丢包损伤项关闭。如果输入超过带宽限制、队列又装满仍可能发生队列丢弃。否则把丢包率设成零以后看到丢弃计数容易误以为设备没有按配置工作。图1本文设计的输入条件。五个阶段卡片不按时长比例绘制它们不是实测速率或恢复曲线。这条用例最值得保留的是91—120秒。只做“断一下然后全部恢复”看不到应用在低带宽下重新发送、重试和恢复媒体的过程。网络已经允许通包不代表它一下子又有足够的上传容量。在场景里填的是持续时间不是结束时间进入 Scenarios新建 DPDK 场景。我会把名字写成“会议上行受限_中断1秒_恢复观察_v1”备注里写清楚 A→B 是上传以及这条场景针对整台终端还是筛选后的业务。这样比“弱网测试1”好找得多。编辑器里依次填30、60、1、29、60秒开始时间会自动累计成0、30、90、91、120秒总时长180秒。第二段填的是“持续60秒”不是“到90秒结束”。这个地方如果填错后面所有阶段都会跟着推迟。图2产品手册中的编辑器示例展示阶段持续时间和参数入口。图内是另一条90秒场景不是本文的180秒配置。逐段打开“编辑参数”分别填两个方向。这份用例上下行不同不要为了省事一直保留双向镜像也不要把上传参数直接复制给下载。下载方向虽然五段都不变但每一段仍然要有它自己的配置。自己准备 JSON 时也要注意单位。时间字段用毫秒800kbps对应800000bps丢包率字段的1.0表示100%不是1%。网页输入框显示百分比时按页面单位填写不能把接口里的小数原样搬进去。我给这份笔记另外留了一个对应的场景 JSON五段都有持续时间和完整的双向设置。需要调整时先改副本并换版本名不在比较两个软件版本的中途悄悄改原文件。下一段只填带宽前面的时延就没了这是理解场景功能最关键的一点。它不是“到了30秒再追加一条限速命令”而是“到了30秒换用第二段的完整损伤配置”。比如第一段上行有120ms时延第二段只写了800kbps没写时延。按当前版本的场景逻辑第二段不会继续保留120ms。反方向也是一样只写上行不代表下行沿用上一段。当前实现是先重置两个方向的损伤配置再读入本阶段的参数不是在旧配置上补几个字段。因此在这里把“保持不变”理解为“这一段也填写相同数值”最不容易出错。恢复段同样不能留空。本文最后一段要恢复的是“上行4Mbps、下行8Mbps同时保留120ms和60ms附加时延”不是一条没有任何损伤的理想网络。如果最后一段什么都不填观察条件已经变了。队列还有一个值得单独记的细节当前 DPDK 开启带宽限制、但队列关闭时会自动补上默认尾丢弃队列。因此“不填队列”不能简单理解成“不排队”。做版本比较我宁愿把队列模式和深度也明确写进每一段。这也解释了为什么只记“800kbps”不够。带宽一样队列选择不同报文是多等一会儿还是早点被丢弃应用面对的条件就不同。本文保持队列不变是为了让第一轮的问题尽量单纯。保存以后要到目标链路里播放场景列表负责保存和编辑播放入口在目标虚拟链路的配置页。先回到仪表盘打开承载这轮业务的链路再从顶部“场景”控制条选择刚才的名字最后点击播放。这一步我会连着确认三件事当前选的是哪一个引擎、哪一对端口、哪一条虚拟链路。WE-101-N4G有两对双向业务链路场景存对了播到另一对上会议当然看不出变化。上一篇的过滤规则也不能省略。播放场景不等于自动替业务建好过滤器规则要启用、方向要正确目标流量要进入这条链路仿真模式也要打开。已经确认过的接线和过滤条件先不在这一轮同时改动。我更倾向于先在参考条件下建立会议确认双方音视频已经起来再开始这条场景。这样主要看正在运行的媒体如何适应变化。如果要测登录、鉴权和入会就单独做一条用例从相应阶段开始操作应用别把两类问题混在一次结果里。场景绑定后参数区域会显示“场景控制中”。这时候不要一边播放一边再手工改同一条链路。要换场景条件就编辑场景要回到普通手动配置就先按界面停止、解绑再核对当前参数。进度条走到了不等于报文已经证明了当前版本的步骤状态会在该阶段配置成功写入链路后推进首段还没应用时可能显示0步。相比只显示一个倒计时这个状态更有用至少能区分“计划到了下一段”和“配置已经成功应用”。但它仍然不是逐包测量结果。场景后台大约每10ms检查一次时间点这个10ms是调度检查间隔不是误差保证更不是承诺90.000秒那一瞬间每个报文都整齐切换。尤其本文的1秒上行全丢包不能直接写成“对端必然恰好1秒收不到任何数据”。前一阶段已经进入传输和延迟路径的报文、接收端缓冲、重传都可能影响接收侧看到的边界。配置时间、线上报文时间和画面时间要分开看。所以我会把场景执行状态、入口和出口抓包、两端应用日志放在一起核对。配置显示到了全丢包阶段先确认目标流确实命中配置恢复以后再看报文什么时候通过最后才看媒体什么时候连续正常。图3三种证据回答不同问题。没有测量数据时不能把“步骤应用成功”直接当成“业务恢复成功”。记录“恢复用了多久”之前还得先定起点。本文91秒是取消上行全丢包120秒才恢复上传带宽。两种恢复条件相差29秒。起点不同得到的恢复时间不能直接放在一起比。终点也一样。第一帧到达、声音重新出现、画面连续稳定十秒是不同的判定方式。我会按业务要求选一个写进用例里而不是测试完以后挑一个最短的数。第一轮先别开循环单次播放更适合检查这条场景有没有配对。五段的顺序、方向和时长都确认以后再考虑循环避免还没看懂一轮下一轮已经开始了。停止与播完的行为尤其容易想当然。当前 DPDK 版本正常停止或单次完成后会清空目标虚拟链路上的损伤保留场景绑定方便再次播放。它不会自动找回播放之前的那套手动参数。也就是说本文120—180秒仍然处于有带宽和固定时延的参考条件里180秒正常完成以后这些损伤也会被清掉。要在参考条件下多观察两分钟就把最后一段延长两分钟不要等播放结束后继续观察却仍按原来的网络条件解释结果。循环也不等于两个周期毫无缝隙地拼接。当前实现先清理上一轮损伤再重新启动下一轮不要把它当成严格连续、没有过渡的周期波形。需要连续观察的过程优先在一条足够长的时间线里写完整。还有应用自身的状态。场景重新从第一段开始会议软件不会因此自动退出、重新登录、清空缓冲。循环十次是在同一业务会话里连续施压不等于十次从相同初始状态开始的独立测试。做版本对照时我会把应用是否重启、是否重新入会、预热多久都固定下来。否则换了软件版本同时又换了运行起点很难说差别来自哪里。加随机丢包以前先留下这条基础用例这条场景没有额外随机丢包只有确定时段的100%上行丢包便于先看清大致过程。需要更复杂的弱网条件时可以复制一份再在指定阶段加入随机丢包、突发丢包或Gilbert-Elliott模型。副本名称、模型和参数一起改基础版本留下。不要今天在第三段加抖动明天又加背景流量最后所有文件都叫“最终版”到要复查时已经找不到最初那条简单用例。场景保存的是网络参数和时间安排不是会议本身。播放场景不会替终端发送媒体也不会自动重放用户操作。恢复同一份配置同样不表示每一轮恰好丢掉相同的几个包加入概率模型以后更需要多轮观察。网准通的场景模板库可以作为起点里面有移动网络、Wi-Fi以及GEO、MEO、LEO等目录。我会先读模板的方向说明、阶段和损伤组合再决定取哪部分。名字里有“卫星”不等于它自动匹配自己的接入速率、轨道和网关路径。这里做的是IP链路条件仿真不是射频信道、轨道运动或多普勒仿真。场景能把应用将面对的带宽、时延和丢包变化安排出来这些变化对应哪一种实际网络还需要自己的链路资料。场景文件要单独留不能只备份设备配置场景卡片上的“导出场景”会生成JSON可以保存名称、引擎类型、阶段和损伤配置。当前DPDK入口支持JSON导入不是随便拿一份CSV曲线就能直接播放。Settings里的“导出配置”不包含场景和模板库。我的归档会分成两部分设备配置负责接线对应的端口对、链路和过滤规则场景JSON负责这三分钟怎么变化。再把软件版本、执行记录和应用侧资料放到同一个测试编号下面。比较其他网络损伤仪时我也不会把“能自动改参数”说成网准通独有。Apposite Netropy公开提供REST自动化列有多种丢包模型和队列管理。具体看下面几个与日常使用有关的差别就够了。项目网准通 WE-101-N4G本文按DPDK功能Apposite Netropy 10G2及系列公开能力产品与接口四个千兆电口两对双向链路专用硬件设备四个1/10G SFP口、两个引擎不推定内部芯片路线虚拟链路规模资料列系统全局最多4096条公开按每端口对最多30条WAN链路介绍统计范围不同损伤与队列双向配置随机、突发、周期、GE等丢包Tail Drop/RED系列资料同样列出这些丢包模型和Tail Drop/RED自动化与使用重点双向阶段编辑、JSON复用、REST、抓包方便把千兆应用测试固化成用例REST、运行中调整参数、多引擎需要万兆接口时也应考虑其配置已经买了WE-101我更看重的是这条操作路径能接起来先用过滤器选中业务再用场景给它一段变化过程最后通过执行状态、抓包和应用日志查问题。千兆接口够用、需要反复改弱网用例时这些软件功能比再多背几个峰值参数实在。这篇先把三分钟的场景定清楚。以后软件换版本至少不用靠记忆重做一遍“先限速、再断一下、然后恢复”的手工操作。场景文件里是什么就按什么跑需要修改就留下新的版本。这样积累下来的才是一组能继续用的弱网测试用例。
 Polyfill：从跨 SAPI 兼容到请求头解析原理)
