用网络损伤仪做弱网测试，不能只记一个“丢包率 1%”。零散丢包、隔一段连丢几包、网络持续变差，考验的是不同的恢复能力。用网准通（NetAccura）ChaosBridge 混沌之桥 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 包。

我会保存下面两组配置，分别观察零散缺口和连续缺口：

这组对照的价值，是把平均比例固定住，只改变损伤的集中程度。会议软件能补回零散丢包，不代表同样数量集中在一起也能补回；但是否真的出现卡顿，还取决于编码、冗余、重传和播放缓冲，不能从这张表直接填出卡顿次数。

图：两种配置在完整周期内都是 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 包/秒时，十个发包时隙约占 10ms；50 包/秒时，十个时隙约占 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 放在同一个应用层级里看：

路径数量不是吞吐成绩，多种逻辑规模的计数方式也不同。对我这里的会议软件配置练习，先用好几条能清楚区分业务的链路，比一开始创建几千条空规则更有用。

WE-101 对这类任务的实际吸引力，是四个业务口可以安排两对物理路径，再把过滤、双向条件、抓包和场景接起来。上行做连续丢包，回程保留原有延迟；要单独损伤某条业务时，不必把整台终端的所有连接一起弄坏。这是具体的使用便利，不需要靠“别家都做不到”来成立。

8. 一轮测试结束，我会留下什么

配置里保留模式、全部参数、方向和过滤条件；记录里保留进入模型的包数、主动损伤丢包数，以及是否存在队列等其他丢包原因。只写“测试 1% 丢包通过”，下一次几乎没有办法重做。

对接收端，还要看缺口的位置、连续长度和恢复时间。序列号暂时没到，不一定永久丢了：乱序、迟到和抓包漏采也可能造成表面缺口，所以需要说明等待多久才判为丢失。传输层补回来了，也不代表音视频赶得上播放截止时间。

视频业务至少同时看音频是否连续、视频是否冻结、码率是否调整、是否触发重连。不同软件可提供的指标不一样，没有导出的指标就保留观察和日志，别用一个总丢包率替代所有体验结论。

我会把 Random、周期单包、周期连丢、随机突发保存成几份名称明确的配置。这样下一版软件回来，先复用相同条件，再决定要不要加长时延或带宽竞争。

网络损伤仪的丢包功能用得好不好，最终不在于输入框能填多少位小数，而在于测试者能不能说清楚：丢的是哪些包，按什么规则丢，哪个方向受影响，以及应用为什么在这种条件下恢复或失败。对 WE-101，这几个问题弄清楚了，后面的场景回归才真正有可比性。