接着前面的选型记录这篇把网准通 NetAccura ChaosBridge 网络损伤仪的使用方法写具体一点怎么接线怎么把视频通话的上行限到800kbps以及画面卡住以后去哪里找原因。这一轮适合用DPDK引擎重点是上下行分开设置、队列对照和分阶段恢复不需要先把端口跑满。下面是一套准备执行的测试方案。参数可以照着配置计算示例也可以复核业务恢复时间要等实际跑完再填。设备怎么接先用两台电脑建立视频通话一台作为被测端另一台看接收到的画面。第一轮用有线连接把办公室Wi-Fi的干扰先排除掉。以后测手机时再把专用AP接到被测侧让它的出口流量经过损伤仪。损伤仪串在被测电脑和网关之间。靠电脑的一侧记作A靠网关的一侧记作B。按这个接法A→B是上行B→A是下行。这个方向是接线决定的不是看到模板里写着A→B就一定代表上行。管理电脑走单独的管理口不跟着业务一起限速。否则测试刚进入全丢包阶段自己的配置页面也打不开很容易把管理连接中断误当成设备故障。图1A、B是本次接线约定。实际媒体可能经过SFU或TURN图中云端不表示固定采用某一种转发方式。在网准通界面里选DPDK引擎、对应端口对新建一条专门放这次通话流量的虚拟链路。两侧入口都要有指向它的过滤规则。如果整个端口对只给这次实验用两侧匹配全部流量比较省事如果还有别人的业务就按被测电脑的IP或专用VLAN划分。网关做NAT时还要看损伤仪插在NAT前还是后不能拿转换前的地址去匹配转换后的报文。这里不建议上来就只过滤某个UDP端口。媒体、反馈和连接控制不一定都走这个端口重连以后端口也可能变化。第一轮先模拟这台终端完整的上网条件后续定位问题时再缩小范围。配置好后先在不加损伤的情况下确认通话正常再开启Emulation。核对端口和虚拟链路的双向计数都在增长不能只看端口灯亮着就开始计时。第一轮只改上行我想先回答一个很具体的问题上传能力明显变差以后应用会不会及时降低发送量条件好转后它又是怎么恢复的因此下行保持10Mbps上行从5Mbps降到800kbps。这里的800kbps是整条上行虚拟链路的额度音频、视频、重传和控制报文都要使用它不是给视频编码器单独预留800kbps。上下行各加20ms固定时延其他损伤先不启用。第一轮带宽模式用漏桶队列用Tail Drop单位明确选Bytes。上行先设40,000字节下行固定40,000字节。这些值是为这次对照选择的测试输入不是某个运营商网络的标准参数。场景时间上行限速上行主动丢包这一段看什么0—20秒5Mbps关闭记录参考条件下的发送量和画面20—50秒800kbps关闭发送量是否调整队列有没有积压50—52秒800kbps100%连续两秒不放行上行报文时的表现52—82秒800kbps关闭仍然限速时声音和画面怎么恢复82—120秒5Mbps关闭带宽恢复后清晰度和发送量怎么变化全程下行保持10Mbps双向固定时延保持20ms。表里的“主动丢包关闭”不等于不会丢包队列满了Tail Drop仍然会丢弃新来的报文。图2这是待执行的参数时间线不是业务实测曲线。每个阶段都保存完整的双向配置。这也是我愿意用场景功能的原因。手动拖滑块很难在两次测试里准确保留相同的阶段时长。保存成场景后换应用版本时可以复用同一套输入。网准通当前版本的阶段配置是完整快照不是“只改这一项”。例如52秒恢复阶段除了关闭主动丢包还要写上800kbps、20ms和队列参数不能以为前一个阶段的其他值会自动继承。另外50—52秒做的是报文全丢包不是拔网线。端口仍可保持Link Up。已进入后续处理环节的包也可能在切换边界附近继续出现所以具体生效时间要结合场景执行记录和抓包看。同样800kbps队列不能漏记第二轮复制这套场景只把上行队列从40,000字节改为4,000字节其他参数不动。两份分别命名为RTC-UP800-Q40000和RTC-UP800-Q4000。为什么还要跑这一轮因为“发送不出去”可以变成排队也可以变成丢弃。两种情况对视频通话的影响不一样。先算一个数。800kbps按十进制换算是每秒100,000字节。假设前面已经积压了40,000字节按这个速率排出去对应400ms积压4,000字节对应40ms。这里算的是积压数据的理想排空时间队列字节数×8÷带宽。它没有计入逐包开销和调度也不是“设了40KB每个包就必定增加400ms”。队列空着时自然谈不上这么长的排队。图3400ms和40ms来自计算不是网准通或其他品牌的实测时延。KB在本例中按1,000字节计算。大队列能多接住一阵突发但也可能留下更多来不及播放的旧数据。小队列更早丢包积压少一些却可能增加重传或画面损坏。哪一组更适合当前应用要看它如何调整编码、处理丢包和安排播放不能直接认定4KB一定更好。翻当前版本的实现还有一个值得记下来的细节启用带宽限制、但没有手动启用队列时系统会自动配置Tail Drop队列先按100ms的数据量估算包数再把结果限制在64到100,000包之间。在800kbps、名义包长1,500字节的条件下100ms的数据量是10,000字节向下取整只有6包。由于有64包下限最后得到的是64包不是6包。如果只是为了理解量级假设64个包都恰好是1,500字节这批数据就是96,000字节以800kbps排空约需960ms。真实通话包长不同不能把这个数当作实际缓冲时延更不能把“按100ms估算”理解成“固定增加100ms”。所以这次对照不沿用自动队列直接用字节数指定容量。以后复盘时记录里不能只剩下“800kbps、零主动丢包”还得有带宽模式、队列单位、容量和帧开销设置。还有一个很容易误读的现象网准通当前DPDK处理路径中固定时延是在带宽排队之后叠加的。页面填20ms并不表示经过损伤仪的全部时间只有20ms。限速队列已经积压时继续加大固定时延只会把两件事混在一起。画面顺不顺要看对端上行变差以后被测电脑上的摄像头预览仍然可能很流畅因为那是本地画面。真正要观察的是另一台电脑收到的声音和图像。拍摄内容也要固定。一直对着静止背景和镜头前有人走动、共享屏幕快速滚动发包情况未必一样。做版本对照时尽量复用同一段授权测试素材并固定分辨率、帧率和编码设置应用如果会自动降档也把实际档位记下来。如果是自己开发的WebRTC应用可以每秒采集一次统计。发送端看发送量接收端看帧率、卡顿和播放缓冲。两端都记录才好区分“没有继续发”和“发过来了但没及时播”。有个容易算错的指标是jitterBufferDelay。它是累计值不是当前延迟。看某一个时间段时应使用同一条接收流前后两次采样缓冲平均停留时间(ms) ΔjitterBufferDelay ÷ ΔjitterBufferEmittedCount × 1000分母没有增长时不填零连接重建、统计对象改变时也不能跨对象相减。音频和视频分开算。ICE统计中的currentRoundTripTime是网络往返测量不是用户看到画面的端到端延迟。如果是拿不到内部统计的商业软件就用它自己的通话统计页、两端录像和应用日志。能记录多少写多少不要拿损伤仪里的20ms去填“视频延迟”。卡住以后抓包怎么配合看这里我会同时记录虚拟链路损伤前、损伤后两个抓点必要时再加物理端口RX/TX。网准通DPDK版有这些抓点可以把“包有没有进来”和“处理后有没有出去”分开看。举个排查顺序如果应用显示正在发送但虚拟链路入口一直没有相应报文先查实际路由、过滤条件和入口方向。如果入口有、出口少再看队列丢弃和主动丢包计数。如果损伤仪出口持续有包对端却没有画面还要接着查后面的网络、接收和播放不能到这里就宣布是应用的问题。损伤前后出现同一个包是两个观察位置不等于设备把包复制了一次。分析时按抓点拆开不要把混合导出的全部包一起统计吞吐或重传。视频通话通常还有加密抓包看到报文持续流动也不能直接证明某一帧已经被用户看见。这正是抓包和对端录屏要一起保留的原因。当前网准通抓包使用一次性内存缓冲写满后会停止不是一直覆盖旧数据。开始前检查缓冲容量和截断长度结束后确认实际覆盖到120秒否则最后的恢复阶段没抓到前面记录再完整也不够分析。这轮为什么用网准通DPDK前面比较过几家这里只补充它们和这次测试的关系不再做一遍品牌排名。产品已公开或已核对的能力对这次测试的意义网准通 NetAccura ChaosBridge提供DPDK与FPGA路线本次DPDK用一组业务端口、一条虚拟链路双向独立设置支持漏桶/令牌桶、Tail Drop/RED、阶段场景、抓包和API能把限速、指定字节队列、两秒全丢包和恢复阶段放在同一条测试流程里保留配置与报文记录信而泰 Xcompass-SFPGA架构S10覆盖1G/10G接口S100覆盖10/25/40/100G公开列出时延、抖动、丢包等损伤及Python API高包速率和硬件时序测试值得比较若重点是本例的排队对照还需要确认具体队列模型和可配置容量思博伦 Spirent Network Emulator公开数据手册列出双向独立损伤、可配置带宽缓冲、Timeline和RESTful API按配置最高16个1G/10G口或8个25/50/100G口同样具备编排网络条件的基础多端口实验室也有相应组织方式Apposite Netropy例如10G2有4个1G/10G口、2个引擎公开列出每端口对最多30条WAN链路、Tail Drop/RED、多种丢包模型和REST API同样适合应用弱网和队列测试已有这套环境的团队可以沿用所以选择网准通做这轮测试不是因为其他产品都做不了。对我这套方案更直接的理由是上下行、队列、场景和抓包都有明确的配置入口当前实现也能核对出了问题有地方往下追。DPDK和FPGA都可以做弱网测试但不能只凭架构名字推断队列行为。就网准通当前引擎能力来说FPGA带宽控制是超额丢弃型policer这次要比较的是可配置队列中的等待和丢弃因此选DPDK更贴题。这条区别不能直接套到所有厂家的FPGA产品上。最后把结果怎么记清楚两份配置各做至少三轮初步对照穿插顺序。每轮都回到相同的起始条件等通话状态稳定再开始不能让上一轮还没降下来的码率或还没恢复的连接直接带进下一轮。三轮只是起步不代表已经覆盖所有波动。恢复时间要分两笔记。52秒结束全丢包后仍然只有800kbps观察的是“受限带宽下重新工作”82秒恢复5Mbps以后观察的是“网络变好后恢复质量”。如果统一写“恢复用了几秒”以后就不知道是在回答哪一个问题。记录表里我会保留场景文件、应用和浏览器版本、队列容量、每个阶段的实际执行时间、发送与接收统计、队列丢弃增量以及录屏和抓包文件名。声音首次恢复、画面首次更新、随后连续正常的时间分别填写。某项没采集到就写未采集。我希望最后能回答的不只是“800kbps还能不能通话”而是应用在什么条件下开始积压调整发送量花了多久报文恢复后画面又等了多久。把这些事情分开看网络损伤仪才不只是一个限速开关。对视频会议、远程协作这类产品网准通的双向配置、软件队列和场景回放正好能把测试输入固定下来再用抓包和业务记录去解释结果下一次改版本才有东西可比。