用网络损伤仪模拟卫星网络不能只填一个很大的时延。视频会议要看的是长时延叠加上行受限以后声音、画面和控制消息还能不能正常配合。WE-101 的双向损伤配置适合搭这种环境但单向时延、往返时延和拥塞排队必须分开设置否则设备确实在制造弱网测的却未必是你需要的那种网络。我们买的是网准通NetAccuraChaosBridge 混沌之桥 WE-101-N4G。前面写了过滤、抓包和场景回放这篇接着整理卫星通信视频会议的参数配置。下面用一组明确设定的网络条件说明不拿推算值当会议软件的实测表现。要模拟 600ms延迟框里不是直接填 600先说这组条件希望空载时的往返时延接近 600ms终端上行 2Mbps、下行 10Mbps。这是本文选的一组测试输入不代表所有卫星线路低轨、地球同步轨道和不同地面路由不能共用一个“标准卫星时延”。这里最容易填错的是 600ms。假如它指的是 ping 显示的 RTT也就是请求过去、响应回来的总时间那么把两个方向都加上 600ms光新增部分就有 1200ms。配置前先保持原来的接线、过滤和转发路径只关闭损伤确认目标报文确实经过 WE-101。用小报文测一段空载 RTT留下基线不能今天拿直连结果做基线明天换一条经过公网服务器的路来验证。假设这条测试路径的基线是 20ms那么要补进去的往返时延是 580ms。没有单向测量依据时可以先按对称模型处理A→B 加 290msB→A 也加 290ms空载往返大致为 20290290600ms。这里说“大致”是因为报文还要串行发送软件处理和调度也会花时间。这个算式用于确定输入量不是承诺每个 ping 都精确显示 600.000ms。尤其不能拿带宽已经被视频挤满时的 ping反过来修改固定时延硬把 RTT 调回 600ms。图 1假设基线 RTT 为 20ms新增 290ms290ms形成约 600ms 的空载往返条件。图中数字是配置设计值。上行 2Mbps、下行 10Mbps要跟着终端方向填我会把终端侧记作 A服务端或对端网络记作 B。这样 A→B 就是终端上传B→A 就是终端下载不靠端口编号猜方向。接线换过、终端位置换过这个标注也要跟着核对。视频会议里这两个带宽差得很大并不奇怪。但“上行慢”不等于“上行传播时延一定更长”。带宽不对称和传播时延不对称是两件事没有另外的依据不能因为上行只有下行的五分之一就把上行固定时延也乘五。这一组起步配置可以这样记。跟随带宽模式按后文说明的当前 DPDK 软件逻辑使用先选固定速率的漏桶整形不叠加令牌桶突发量。配置项A→B终端上传B→A终端下载固定附加时延290ms290ms带宽限制2Mbps10Mbps整形方式固定速率漏桶固定速率漏桶拥塞队列Tail Drop跟随带宽Tail Drop跟随带宽对应目标队列容量25,000 字节125,000 字节额外随机损伤先关闭丢包、抖动、乱序先关闭丢包、抖动、乱序“先关闭”不是说卫星网络没有丢包和抖动而是先把长时延、带宽瓶颈和排队这组关系单独看清楚。一开始全部打开后面声音断续了很难知道该查连续丢包、带宽竞争还是应用自己的缓冲。过滤规则也要涵盖实际业务媒体、信令和必要的反馈流量是否走同一个模拟出口需要事先想清楚。只把视频 UDP 放进去把控制连接留在好网络里测到的是一种局部受损条件不是整条卫星接入链路。三个缓存数字不能填进同一个框配置到队列时很容易想到“卫星时延大缓存也得大”然后直接用带宽乘 RTT。问题是这个乘积回答的未必是队列框问的问题。以 2Mbps 上行为例有三笔不同的账。第一笔是报文为了模拟 290ms 固定时延需要在损伤仪里等待。若持续进入延迟阶段的数据速率按 2Mbps 估算等待中的数据量级约为 2,000,000×0.29÷872,500 字节。这里用的是单向附加时延不是往返时延。实际内存还包含报文对象、管理结构及其他开销这不是设备总内存的配置公式。第二笔是带宽受限后拥塞队列允许积压多少。如果给它 100ms 的容量预算对应的是 2,000,000×0.1÷825,000 字节。这个数才和本例的带宽队列设置相关。它不是让每个包强制多等 100ms队列空时几乎不用等只有发生积压才会产生相应等待。第三笔是 TCP 的带宽时延积。以 600ms RTT 计算2,000,000×0.6÷8150,000 字节描述的是填满这条瓶颈路径所需在途、尚未被确认的数据量级。它可以帮助分析 TCP 窗口是否够用却不能直接变成损伤仪拥塞队列的推荐容量。图 272,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 作一个简要对照更容易看清差异在哪里。比较项网准通 ChaosBridge WE-101-N4GApposite Netropy N61实现与部署本文使用 DPDK 软件引擎的硬件设备专用网络仿真设备不据产品名称推定底层芯片架构测试端口型号资料列出 4 个千兆测试电口、2 对双向链路2 个千兆仿真端口电口或光口按配置虚拟链路规模型号资料列出全局最多 4096 条官方资料列出每端口对 30 条模型与队列当前 DPDK 支持双向延迟、限速、多种丢包、Tail DropRED公开列出延迟分布、多种丢包、Tail DropRED自动化Web、REST API、场景配置与回放Web、REST API本文相关用途千兆接口下的双向弱网、两对链路接入和应用回归千兆 WAN 仿真及卫星链路条件测试虚拟链路数量不是同时满速处理能力上表两家的统计范围也不同不能直接相除得出性能倍数。对于这组 2Mbps10Mbps 的会议测试我更关心两端怎么接、两个方向怎么管、队列怎么计量以及一份配置下次能不能准确复用。WE-101 对这类工作有吸引力的地方是两对测试链路、双向配置和应用排查工具可以放在同一台设备上组织。当前软件还能把队列容量的计算方式、动态带宽的峰值规则和延迟叠加逻辑解释清楚。这些细节让测试条件更容易说清楚比单独强调端口数字更贴近开发工作。保存配置时把参数为什么这么填也留下这次值得留下的不是一张“卫星网络推荐参数表”而是参数之间的关系600ms 是目标空载 RTT290ms 是每方向补入的时延2Mbps10Mbps 是两个方向的瓶颈25,000125,000 字节来自本例的跟随队列规则不来自 600ms RTT。配置备注里再写上 A、B 对应谁基线怎么测软件版本是什么固定带宽还是动态曲线。换人接手或过几周再跑时就不用对着几个数字猜上一轮的意思。WE-101 在这里模拟的是卫星路径给 IP 业务带来的延迟、带宽、排队和损伤条件不是射频、轨道或多普勒仿真。先把这个范围内的网络环境搭准视频会议后续出现的超时、积压和恢复问题才有一个能反复核对的起点。