用网络损伤仪做弱网测试不能只记一个“丢包率 1%”。零散丢包、隔一段连丢几包、网络持续变差考验的是不同的恢复能力。用网准通NetAccuraChaosBridge 混沌之桥 WE-101 配置时我会先用 Random 看基础容错再用 Periodic 做相同平均比例的连续丢包对照最后用 Burst 或 Gilbert–Elliott 增加不确定性。这篇接着记 WE-101 的使用方法重点是几个很容易填错、又会改变测试含义的参数。文中的包数和比例是配置推算方便核对设置不是视频会议软件的实测成绩。下面按当前 DPDK 版本的界面和处理逻辑说明。1. 先只让一条业务、一个方向丢包我的第一组配置会尽量简单会议终端到对端的流量单独命中一条虚拟链路只打开这个方向的丢包。反向先保持正常。固定延迟、带宽、队列等沿用同一组基线暂时不叠加抖动、乱序和背景流量。这里要分清“只测上行”和“只影响上传画面”。如果同一条链路里还混着控制报文、反馈和其他连接上行丢包也可能影响对端的判断。方向只是物理和逻辑上的 A→B不自动等于某一类业务。所以我会先看过滤器是不是命中了目标流量再看虚拟链路的包数有没有增加。端口收到了包不等于包已经进入这条丢包规则。只看整机收发统计很容易把旁路流量也算进去。如果当前目的就是比较丢包模型基线中最好没有队列溢出等额外丢包。否则接收端少掉的包可能一部分来自拥塞一部分来自主动损伤这个时候应用看到的总丢包率不一定等于 Loss 卡片上的数字。操作上进入目标虚拟链路选对方向打开 Loss然后再切模式。至少把链路名、方向、过滤条件和软件版本一起记下来。截图只截一个“1%”输入框过几天连损伤的是哪条连接都说不清。2. Random 的 1%不是每一百包固定丢一个Random 模式中Loss Rate (%) 填 1表示每个进入丢包判定的报文有约 1% 的概率被丢弃。它不承诺这一百包恰好丢一包也不承诺连续两次运行丢在相同位置。假设一轮有 10,000 个包进入这个阶段期望丢掉的数量是 100。实际的一轮可以多一些也可以少一些不能因为读数不是整整 1.0000%就直接认定配置不生效。如果目的是检查“给定比例下计数是否符合预期”Fixed Ratio 更容易对照。当前实现用累计比例决定丢弃位置。以状态从零开始、设置保持不变的 1% 为例每累计 100 个参与判定的包丢一个完整处理 10,000 包会得到 100 个模型丢包。两者适合做不同的事。Random 适合观察随机损伤下的表现Fixed Ratio 适合做规律性的计数对照。后者丢得更均匀不代表它更接近真实网络也不该用它替代所有随机丢包用例。通过 API 配置还有一个小坑网页输入的 1 表示 1%对应内部比例是 0.01。把网页里的数字原样写成 API 的 rate: 1会变成 100% 丢包。写脚本时我会先核对单位再保存界面读回值。3. 要比较“丢一个”和“连丢十个”Periodic 更直接想比较丢包分布对应用的影响又不希望平均比例跟着大幅变化周期模式很好用。当前界面有两个参数“周期总包数”和“周期内连续丢包数”。周期总包数包含通过和丢弃的包。连续丢包发生在周期末尾。比如周期总包数填 1000连续丢包数填 10含义是先通过 990 包再连续丢 10 包然后进入下一轮不是先通过 1000 包再额外丢 10 包。我会保存下面两组配置分别观察零散缺口和连续缺口配置项周期单包丢失周期连续丢失Loss 模式PeriodicPeriodic周期总包数1001000周期内连续丢包数110一个完整周期通过 99 包丢 1 包通过 990 包连丢 10 包完整 10,000 包中的模型丢包100 包100 包完整周期的平均比例1%1%这组对照的价值是把平均比例固定住只改变损伤的集中程度。会议软件能补回零散丢包不代表同样数量集中在一起也能补回但是否真的出现卡顿还取决于编码、冗余、重传和播放缓冲不能从这张表直接填出卡顿次数。图两种配置在完整周期内都是 1%。条带表示一轮的组成不按包数比例绘制。这里的“连续”按进入模型的处理次序计算。若发包是突发的或有多个队列并行处理不要把它理解成设备保证在某个精确的墙钟时刻丢十包。要确认应用究竟缺了哪些包还得结合序列号看。4. Burst 填 1%、长度填 5平均丢包率会接近 4.81%Burst 和 Random 最大的区别不在名字而在百分比到底控制什么。当前 Burst 有 Burst Prob (%) 和 Burst Length 两个输入框。前者是开始一轮连续丢包的触发概率后者是一轮要丢的包数。触发用的第一个包也算在这个长度里。以长度 5 为例触发时丢掉当前包再丢后面 4 个参与判定的包。丢完这轮才重新等待下一次触发。在这 5 包内部不会每包再各自启动一轮新的五包丢弃。因此触发概率填 1%并不等于最终只丢 1% 的流量。按理想独立触发模型平均每轮开始前约通过 99 包随后丢 5 包合起来约 104 包里丢 5 包也就是约 4.81%。这描述的是长期平均不是固定重复“通过 99、丢 5”的序列。设触发概率为 p一轮长度为 L长期平均丢包率可按下面的关系估算平均丢包率 ≈ L × p ÷ [1 (L − 1) × p]。如果希望长度保持 5而平均比例接近 1%反推得到的触发概率约为 0.2016%。所以界面的 Burst Prob (%) 应填约 0.2016不是 1。有限样本仍会波动不能拿这个理论值要求每次计数精确相等。图按当前触发逻辑计算的长期均值。这里没有设备测量曲线也不代表实际视频质量。还有一个容易忽略的现象上一轮丢完下一包就可能再次触发。因此“每轮长度 5”不保证抓包里最长缺口只有 5 包。相邻两轮连在一起接收端就可能看到连续缺 10 包继续相邻触发还会更长。如果严格要求每次只产生十包缺口并在两次之间保留确定的通过区间优先用 Periodic。Burst 更适合让发生位置带有随机性而不是拿来保证一个绝不超过的最大缺口。5. 连丢十包不等于断网十毫秒Periodic 的周期和连续长度以及 Burst Length单位都是包不是时间。同样十包在不同包速率下对应的时间尺度会差很多。假设目标流量匀速发送1000 包/秒时十个发包时隙约占 10ms50 包/秒时十个时隙约占 200ms。这只是时隙换算不是“从第一个丢包时间戳到最后一个”的精确跨度更不是画面卡顿时长。对卫星视频会议尤其要留意这一点。码率、包长和编码策略变了每秒包数也可能变化。输入框一直填着“连丢 10 包”并不意味着每个测试版本经历了同样长的损伤时间窗口。如果需求明确写的是“每隔一段时间中断 200ms”就应按时间编排损伤阶段例如在目标阶段让相应方向 100% 丢包再恢复。不要仅靠十个包去代替一个时间窗口。IP 层全丢包也不等于拔网线物理链路指示灯完全可能仍然亮着。Gilbert–Elliott 则适合描述好、坏两种状态交替。四个参数分别决定好转坏、坏转好的概率以及好状态和坏状态中的丢包率。当前实现按报文到达推进状态不是按每毫秒推进。比如 Bad→Good 设为 10%理想模型中坏状态平均持续约十个报文判定机会但如果 Loss in Bad 不是 100%这十个机会也不等于十个实际丢包。它适合研究损伤的相关性不会因为选了这个名字就自动变成某条真实卫星链路。6. 音频和视频共用一条虚拟链路会共用丢包状态这是比参数精度更值得先弄清楚的实现细节。当前 WE-101 所用 DPDK 实现中Fixed Ratio、Periodic、Burst 和 Gilbert–Elliott 的运行状态按“虚拟链路方向”保存。多个接收处理线程处理同一方向时共享这份状态不是每个线程各自偷偷数一遍。这意味着同一方向里有音频、视频、控制报文三类流量周期总包数统计的是进入该模型的这些包的合计。设置连丢十包不是给音频、视频各发一张“丢十包”的任务单。十个名额落在哪类流量上要看当时的处理次序。图左侧模拟多业务共同经历的损伤右侧用于分别控制业务条件。两种接法回答的问题不同。如果想模拟一条共享链路整体变差把业务放在同一条虚拟链路有意义。如果只想研究视频恢复、不想同时损伤音频就需要能区分业务的过滤条件并为目标业务安排独立虚拟链路。若音视频复用同一加密连接单靠 IP 和端口通常分不开要换可识别的测试流或应用侧统计方法。反方向有独立状态因此两个方向都填同一组 Burst 参数也不意味着它们会在同一时刻开始丢包。需要双向同时恶化时应把同步的时间阶段作为场景要求而不是期待两个随机过程自己对齐。重新开始一轮测试也要写清楚起点。当前版本会在相关丢包配置发生变化时重置对应状态原样再点一次保存不代表一定从第一个包重新计数。周期模式对链路启停也有重置处理不能把一种模式的行为直接套到所有模式上。7. 和 Apposite 对比我会看哪些地方这些模型不是只有网准通能做。Apposite Netropy 5 的手册也列出了 Random、Burst、Gilbert–Elliott 和 Periodic。它的 Burst 可以设置连续长度的最小值和最大值两者设成一样就是固定长度。当前这里讨论的网准通 Burst 则直接设置一个固定长度区别应当说明白。如果还在选购千兆网络损伤仪可以把 WE-101 N4G 和 Netropy N61 放在同一个应用层级里看对比项网准通 NetAccura WE-101 N4GApposite Netropy N61产品路线本文使用 DPDK 软件处理能力专用网络仿真设备公开资料未在此给出内部芯片路线仿真接口4 个千兆电口可组成 2 对双向链路2 个千兆仿真接口1 对双向链路逻辑规模数据手册列出系统全局最多 4096 条双向虚拟链路Netropy 5 默认单链路模式每引擎最多 30 条路径另有 per-client 模式不能拿 30 当作所有模式的用户上限本文涉及的模型Random、Fixed Ratio、Periodic、Burst、Gilbert–Elliott手册列出 Random、Periodic、Burst、Gilbert–ElliottBurst 支持长度范围回归与自动化Web、REST API、场景保存与回放Web、API 文档及录制参数回放这个系列中的用途两路千兆环境、按业务分流、组合损伤与应用回归千兆 WAN 环境、路径条件配置与应用性能测试路径数量不是吞吐成绩多种逻辑规模的计数方式也不同。对我这里的会议软件配置练习先用好几条能清楚区分业务的链路比一开始创建几千条空规则更有用。WE-101 对这类任务的实际吸引力是四个业务口可以安排两对物理路径再把过滤、双向条件、抓包和场景接起来。上行做连续丢包回程保留原有延迟要单独损伤某条业务时不必把整台终端的所有连接一起弄坏。这是具体的使用便利不需要靠“别家都做不到”来成立。8. 一轮测试结束我会留下什么配置里保留模式、全部参数、方向和过滤条件记录里保留进入模型的包数、主动损伤丢包数以及是否存在队列等其他丢包原因。只写“测试 1% 丢包通过”下一次几乎没有办法重做。对接收端还要看缺口的位置、连续长度和恢复时间。序列号暂时没到不一定永久丢了乱序、迟到和抓包漏采也可能造成表面缺口所以需要说明等待多久才判为丢失。传输层补回来了也不代表音视频赶得上播放截止时间。视频业务至少同时看音频是否连续、视频是否冻结、码率是否调整、是否触发重连。不同软件可提供的指标不一样没有导出的指标就保留观察和日志别用一个总丢包率替代所有体验结论。我会把 Random、周期单包、周期连丢、随机突发保存成几份名称明确的配置。这样下一版软件回来先复用相同条件再决定要不要加长时延或带宽竞争。网络损伤仪的丢包功能用得好不好最终不在于输入框能填多少位小数而在于测试者能不能说清楚丢的是哪些包按什么规则丢哪个方向受影响以及应用为什么在这种条件下恢复或失败。对 WE-101这几个问题弄清楚了后面的场景回归才真正有可比性。