用网准通（NetAccura）ChaosBridge 混沌之桥 WE-101 模拟卫星网络：时延和带宽怎么配

用网络损伤仪模拟卫星网络，不能只填一个很大的时延。视频会议要看的，是长时延叠加上行受限以后，声音、画面和控制消息还能不能正常配合。WE-101 的双向损伤配置适合搭这种环境，但单向时延、往返时延和拥塞排队必须分开设置，否则设备确实在制造弱网，测的却未必是你需要的那种网络。

我们买的是网准通（NetAccura）ChaosBridge 混沌之桥 WE-101-N4G。前面写了过滤、抓包和场景回放，这篇接着整理卫星通信视频会议的参数配置。下面用一组明确设定的网络条件说明，不拿推算值当会议软件的实测表现。

要模拟 600ms，延迟框里不是直接填 600

先说这组条件：希望空载时的往返时延接近 600ms，终端上行 2Mbps、下行 10Mbps。这是本文选的一组测试输入，不代表所有卫星线路；低轨、地球同步轨道和不同地面路由，不能共用一个“标准卫星时延”。

这里最容易填错的是 600ms。假如它指的是 ping 显示的 RTT，也就是请求过去、响应回来的总时间，那么把两个方向都加上 600ms，光新增部分就有 1200ms。

配置前先保持原来的接线、过滤和转发路径，只关闭损伤，确认目标报文确实经过 WE-101。用小报文测一段空载 RTT，留下基线；不能今天拿直连结果做基线，明天换一条经过公网服务器的路来验证。

假设这条测试路径的基线是 20ms，那么要补进去的往返时延是 580ms。没有单向测量依据时，可以先按对称模型处理：A→B 加 290ms，B→A 也加 290ms，空载往返大致为 20＋290＋290＝600ms。

这里说“大致”，是因为报文还要串行发送，软件处理和调度也会花时间。这个算式用于确定输入量，不是承诺每个 ping 都精确显示 600.000ms。尤其不能拿带宽已经被视频挤满时的 ping，反过来修改固定时延，硬把 RTT 调回 600ms。

图 1：假设基线 RTT 为 20ms，新增 290ms＋290ms，形成约 600ms 的空载往返条件。图中数字是配置设计值。

上行 2Mbps、下行 10Mbps，要跟着终端方向填

我会把终端侧记作 A，服务端或对端网络记作 B。这样 A→B 就是终端上传，B→A 就是终端下载，不靠端口编号猜方向。接线换过、终端位置换过，这个标注也要跟着核对。

视频会议里，这两个带宽差得很大并不奇怪。但“上行慢”不等于“上行传播时延一定更长”。带宽不对称和传播时延不对称是两件事；没有另外的依据，不能因为上行只有下行的五分之一，就把上行固定时延也乘五。

这一组起步配置可以这样记。跟随带宽模式按后文说明的当前 DPDK 软件逻辑使用，先选固定速率的漏桶整形，不叠加令牌桶突发量。

“先关闭”不是说卫星网络没有丢包和抖动，而是先把长时延、带宽瓶颈和排队这组关系单独看清楚。一开始全部打开，后面声音断续了，很难知道该查连续丢包、带宽竞争，还是应用自己的缓冲。

过滤规则也要涵盖实际业务：媒体、信令和必要的反馈流量是否走同一个模拟出口，需要事先想清楚。只把视频 UDP 放进去，把控制连接留在好网络里，测到的是一种局部受损条件，不是整条卫星接入链路。

三个缓存数字，不能填进同一个框

配置到队列时，很容易想到“卫星时延大，缓存也得大”，然后直接用带宽乘 RTT。问题是，这个乘积回答的未必是队列框问的问题。

以 2Mbps 上行为例，有三笔不同的账。

第一笔是报文为了模拟 290ms 固定时延，需要在损伤仪里等待。若持续进入延迟阶段的数据速率按 2Mbps 估算，等待中的数据量级约为 2,000,000×0.29÷8＝72,500 字节。这里用的是单向附加时延，不是往返时延。实际内存还包含报文对象、管理结构及其他开销，这不是设备总内存的配置公式。

第二笔是带宽受限后，拥塞队列允许积压多少。如果给它 100ms 的容量预算，对应的是 2,000,000×0.1÷8＝25,000 字节。这个数才和本例的带宽队列设置相关。它不是让每个包强制多等 100ms：队列空时几乎不用等，只有发生积压才会产生相应等待。

第三笔是 TCP 的带宽时延积。以 600ms RTT 计算，2,000,000×0.6÷8＝150,000 字节，描述的是填满这条瓶颈路径所需在途、尚未被确认的数据量级。它可以帮助分析 TCP 窗口是否够用，却不能直接变成损伤仪拥塞队列的推荐容量。

图 2：72,500、25,000、150,000 字节分别对应延迟等待、拥塞队列和 TCP 在途数据。三者回答的问题不同，图中为理想化计算。

如果把第三个数字 150,000 字节照抄进一个按 2Mbps 排空的队列，仅这些积压数据的理想排空时间就有 600ms。你原本只想模拟约 600ms 的往返路径，结果可能又引入了很长的拥塞等待。

同样，10Mbps 下行的三笔数分别是 362,500、125,000 和 750,000 字节。下行速率更高，需要更多字节才能表示相同的时间预算，但这不等于下行应该被人为拖得更慢。

本文 Mbps 按每秒一百万比特计算，表内直接写字节，避免把 kB 和 KiB 混着算。这些关系也不能拿来推导“视频一定卡多少秒”：媒体可能走 UDP 或其他传输，编码、重传和播放缓冲还各有自己的行为。

固定延迟不会把已经排队的时间抵消

这也是我觉得有必要把 WE-101 软件处理顺序写出来的地方。

当前 DPDK 实现里，报文受带宽限制排队，离开整形队列后，再进入后面的损伤处理和延迟调度。固定延迟的计时起点在这次排队之后；原始进入时间另行保留，不拿它去“扣掉”拥塞已经造成的等待。

所以，在其他损伤关闭的条件下，某个包如果确实排了约 100ms，再进入 290ms 固定延迟阶段，这两部分合起来约为 390ms。不是把 100ms 包在 290ms 里面，更不是两者只取较大值。

图 3：示意报文先排队 100ms、再附加延迟 290ms 的情况。100ms 是假设已经发生的等待，不是队列配置后每个包都会得到的固定延迟。

这对卫星视频会议很关键。长传播路径本来就让交互慢，再把终端上传挤满，排队会让它更慢。这种变化应当保留下来，才有机会观察应用如何降码率、控制重传或处理晚到数据。

因此，空载时延对上以后，我不会为了让带载 ping 仍然漂亮，就不断调低固定延迟。那样等于一边制造拥塞，一边人为替应用抵消拥塞后果。

“跟随带宽”省事，但动态曲线要多看一眼

网准通当前 DPDK 软件把队列容量分成“跟随带宽”和“手动设置”。下面这部分按 2026 年 9 月核对的软件实现说明；如果设备界面没有这个选项，要先核对软件版本，旧配置不能直接按新逻辑理解。

固定带宽下，“跟随带宽”采用 Tail Drop，容量目标相当于 100ms 的数据量。这里本方向各处理核心共用一个总字节预算，并且按包含所配置帧开销的长度计量。因此，2Mbps 对应 25,000 字节，10Mbps 对应 125,000 字节。这是容量目标，不是精确的排队时长保证。

如果重新把固定上行速率改成 500kbps，跟随容量相应变成 6,250 字节。这样做适合比较：当瓶颈速率改变、名义排队时间预算保持一致时，应用有什么变化。

动态带宽则不同。当前实现按整条曲线的峰值计算容量，应用后保持这份容量，不会在每个低速点都缩成新的 100ms。假设曲线峰值 2Mbps、低谷 500kbps，容量仍按 25,000 字节准备；在 500kbps 阶段，满队列的理想排空时间就接近 400ms。

这不是一个小差别。用固定速率分别跑两轮，与用一条“2Mbps 降到 500kbps”的动态曲线跑一轮，队列行为可能不同。比较结果前，要先确认自己究竟想模拟哪一种网络。

“手动设置”也不是跟随模式换一个名字。当前手动容量保留每个处理核心独立计量的方式，字节计量包含 CRC。多流分散到多个核心时，不能把界面里的一个容量数字直接当作整个方向的总缓存。切到 RED 后也会转入手动模式，不能还沿用跟随模式的共享预算解释。

对这篇起步配置，我更愿意用固定带宽加跟随模式，少引入一个总容量分配变量。要研究固定缓存设备在降速时的积压，再单独安排手动队列实验，并把处理核心和流量分布一并记下来。

视频会议里，我会把这两种慢分开观察

第一种慢是空载就存在的。还没把带宽用满，控制消息来回已经需要很长时间。建会、入会、请求响应是否超时，和业务能容忍多长的往返路径有关。

第二种慢是在媒体发送后增加的。上行受限，积压逐渐出现，带载 RTT 上升，音频或反馈包可能和视频一起等待。这时候应该看码率、队列丢弃和业务日志，而不是只盯固定延迟那个框。

具体记录时，至少把“只加延迟”和“延迟＋带宽队列”保存成两份配置，同一版本的会议软件、同一路径分别使用。之后只降低上行带宽，下行和固定延迟保持不变。这样如果业务出现差异，排查范围不会一下扩大到所有参数。

WE-101 的过滤、分方向配置、抓包和场景保存可以围绕同一条业务链路组织起来。抓包时要标清入口、出口和方向；入口看见报文，只能证明它到过设备，不能证明它已经越过了整形队列。应用日志还要单独记录媒体何时收到、何时恢复连续播放。

“丢包功能关闭”也不等于整条路径零丢包。带宽不足、队列满了，Tail Drop 仍可能丢弃。这种丢包是本例拥塞机制的一部分，不能看到丢包计数就先怀疑随机丢包开关没关干净。

另外，默认帧开销参与限速计量时，2Mbps 不等于会议软件可以持续发送 2Mbps 的视频净载荷。音频、协议头、反馈和重传都要占份额。只用编码器显示的平均视频码率判断“肯定没超过带宽”，容易漏掉这些流量。

同样是卫星网络模拟，设备比较要落到这几项

长时延、限速、丢包和队列并不是只有 WE-101 能做。Apposite Netropy 也有专门的卫星网络测试应用资料。拿同属千兆档的 N61 作一个简要对照，更容易看清差异在哪里。

虚拟链路数量不是同时满速处理能力，上表两家的统计范围也不同，不能直接相除得出性能倍数。对于这组 2Mbps／10Mbps 的会议测试，我更关心两端怎么接、两个方向怎么管、队列怎么计量，以及一份配置下次能不能准确复用。

WE-101 对这类工作有吸引力的地方，是两对测试链路、双向配置和应用排查工具可以放在同一台设备上组织。当前软件还能把队列容量的计算方式、动态带宽的峰值规则和延迟叠加逻辑解释清楚。这些细节让测试条件更容易说清楚，比单独强调端口数字更贴近开发工作。

保存配置时，把参数为什么这么填也留下

这次值得留下的不是一张“卫星网络推荐参数表”，而是参数之间的关系：600ms 是目标空载 RTT，290ms 是每方向补入的时延；2Mbps／10Mbps 是两个方向的瓶颈；25,000／125,000 字节来自本例的跟随队列规则，不来自 600ms RTT。

配置备注里再写上 A、B 对应谁，基线怎么测，软件版本是什么，固定带宽还是动态曲线。换人接手或过几周再跑时，就不用对着几个数字猜上一轮的意思。

WE-101 在这里模拟的是卫星路径给 IP 业务带来的延迟、带宽、排队和损伤条件，不是射频、轨道或多普勒仿真。先把这个范围内的网络环境搭准，视频会议后续出现的超时、积压和恢复问题，才有一个能反复核对的起点。