企业官网建设流程全解析

上一篇记了买下 WE-101-N4G 之后的测试安排。这篇接着聊怎么用。我觉得最应该先弄明白的，不是把丢包率调到多少，而是让哪些报文进入弱网。只测会议媒体、测整台终端、把登录和媒体一起测，是三种不同的用法。网准通（NetAccura）混沌之桥 ChaosBridge WE-101 的过滤器、双向虚拟链路和抓包分析，正好可以把这些事拆开处理。

我们的对象还是用于卫星通信的视频会议软件。下面按 WE-101 的 DPDK 软件功能记设置方法，地址、端口和时延是为了说明配置关系，不是某次通话的成绩。

先弄清楚，测的是整台终端还是其中一项业务

“给视频会议加弱网”，实际配置时还得多问一句：从登录开始，所有网络访问都要变差，还是已经进入会议以后，只改变媒体传输的条件？

如果目标是模拟一台卫星终端的整个接入环境，那登录、鉴权、域名解析、音视频、心跳和重连，都应该处在相应网络条件下。只要终端其他出口没有绕过设备，把这条接入路径的两个方向都送入损伤链路，就比较接近这个目的。

如果目标是看媒体拥塞控制，例如上传受限以后视频是否降码率、声音是否还能维持，事情就不一样了。登录接口先超时，会议都没建立起来，反而看不到媒体阶段的问题。此时可以先把目标媒体流送进弱网，其他报文旁通，等媒体专项做清楚，再补完整接入环境的测试。

这不是把测试条件放宽，而是分清本轮在测什么。我会把用例直接写成“终端全部流量”“已确认的会议媒体流”“会议建立流程”这类名字，不统一叫“卫星弱网”。以后看到结果，至少知道受影响的范围。

WE-101-N4G 有四个千兆业务口，可以组成两对双向链路。上一篇安排两对分别接会议两端；这里先看其中一对。管理电脑仍走独立管理口，不把设备管理界面也放进正在折腾的业务路径。

虚拟链路配了参数，流量还得有规则带进去

WE-101 里，虚拟链路和过滤器是两件事。前者保存延迟、丢包、限速等条件，后者决定哪些报文使用这些条件。建好一条链路，再填上延迟，并不意味着经过设备的所有报文自动受损伤。

当前 DPDK 的处理方式是：按报文进入的物理端口查规则，优先级数字越小越先检查，命中第一条就执行动作。没有命中任何启用规则的流量，默认旁通。

刚搭环境时，我会先用最简单的配置把这层关系核对清楚：建一条有明确名字的虚拟链路，在端口对两侧各建一条“全流量”规则，动作都指向它。暂时不加随机丢包，只用固定时延检查方向；确认流量确实经过目标链路，再把规则收窄到业务。

“全流量”要选对应类型，不是随便选个 TCP 或 IPv4，再把输入框全部留空。后两种仍然带着协议或地址类型的含义，换个人接手很容易误读。

这里也要看仿真开关。Bypass 状态下流量直接旁通；切到 Emulation，并在损伤页面点击“应用”，才进入本轮需要的仿真配置。规则启用、链路选对、仿真打开，是三个不同的检查点。

只测会议业务时，先写清楚上下行分别匹配什么

拿一组便于说明的地址来说：终端是192.0.2.10，媒体服务器是198.51.100.20，已经确认服务器这一项业务使用 UDP/5004。假设终端接端口对的 A 侧，服务器方向接 B 侧，而且设备在这里看到的就是这组地址，没有发生地址转换。

这时两侧规则可以这样写：

注意第二行是“源端口5004”，不是把第一行原样复制过去。上传报文的服务端端口在目的端，返回报文的服务端端口在源端。终端临时端口如果会变化，规则里就不要无依据地固定它。

同时限制 IP、协议和端口时，用“高级”过滤器比较直接。单独的 IPv4 类型没有端口输入框；UDP 类型适合只按 UDP 端口分流。选对表单，比先填一堆字段再猜它们有没有生效省事。

图1：产品使用手册中的高级过滤器界面。图内是手册示例值，不是上表的会议配置；不同字段同时填写时，要同时满足。

字段也不是越多越好。源IP、目标IP、端口、MAC、VLAN 都填上，得到的是这些条件的交集，不是任选一个命中就算。实际报文没带 VLAN，却额外填了 VLAN ID，规则自然匹配不上。

5004 只是这里的示例，不能当成所有视频会议软件的固定端口。真正使用时，要先看当前会话的抓包。软件可能换媒体节点、走中继，或者改变传输协议；多个业务也可能共用同一连接。按一个端口筛出来的流量，不能未经确认就叫“全部音视频”。

如果想覆盖两台不同服务器，可以各建一条指向同一链路的规则。不要试图把“服务器一或服务器二”塞进两个本来表示不同含义的字段。IPv6 流量也需要相应规则，IPv4 条件不会自动覆盖它。

精确规则要放在全流量规则前面

规则顺序是一个很容易忽略的地方。假设第一条已经是“全流量→会议链路”，后面再加一条“指定管理连接→旁通”，后者就没有机会执行。报文在第一条已经被接走了。

只让指定业务受损伤时，我会把需要单独处理的精确规则放前面，最后才放兜底规则。比如，先保护经过业务口的那条管理连接，再把已确认的媒体流送到会议链路，其余流量旁通。这里保护的是确实穿过业务口的连接，独立带外管理口不用这样绕一圈。

图2：同一入口端口按顺序检查规则，第一条命中后就停止。另一侧入口有自己的规则列表，也要单独核对。

“其余旁通”可以依靠未匹配默认旁通，也可以显式建一条最后的全流量旁通规则。调试环境里，我更喜欢把这个选择写在规则列表里，别人打开页面就能看懂本轮到底覆盖哪些流量。

以后要改成整个接入环境都受损伤，再把兜底动作改为对应链路，并重新考虑之前保留的例外。否则媒体流测得很仔细，登录和重连却一直走旁通，最后得出的结论就不完整。

规则调整后，同一端口的优先级会重新连续编号。所以记录时不能只写“用了第3条”，还要保留名称、条件、动作和当时的顺序。

不想手抄五元组，可以从抓包生成过滤器草稿

这是我觉得值得单独记下来的功能。知道会议正在发流量，却不确定该填哪组 IP、哪边是服务端端口时，可以先在 Port RX 抓包，再从真实报文往回建规则。

这里优先抓入口，而不是一开始就只抓虚拟链路内部。如果业务根本没有被规则送进去，链路抓点可能看不到它；入口抓包才能先回答“设备实际收到了什么”。

在 Captures 里建立任务，选相关入口的 Port RX，采集包含目标业务的短片段。打开分析页后，找到相应方向的报文，查看 Packet Decode 中的协议字段，再检查过滤器草稿候选。需要按帧内特定字节筛选时，Hex Dump 也支持选择字节范围作为草稿依据。

当前软件提供的不只是把字段复制到输入框。草稿会结合报文上下文建议入口、条件和优先级；保存前还会读取现有规则，检查重复或重叠。有启用的无条件兜底规则时，建议位置会放在它前面，避免新规则刚建出来就被挡住。

草稿创建后仍是未启用状态。这个细节很实用：分析报文和改变正在运行的流量是两回事。先检查目标虚拟链路、入口方向、匹配范围，再决定启用，不会因为在分析窗口点了一次创建，就立刻改变测试条件。

图3：抓包生成的是待检查的规则草稿，不是自动识别后直接施加损伤。创建草稿和启用规则分开进行。

草稿的“命中范围”也要看统计对象。当前实现区分已加载报文的完整评估、抽样评估和只确认选中报文这几种情况。需要深入解析时，默认从已加载列表中最多选取50个报文作确定性抽样，并包含当前选中的报文。

这50个不是设备只能抓50包，更不是从整场会议里挑出50个“最典型”的包。它是这个预览步骤控制解析量的办法。若页面只加载了会议建立阶段，就不能拿这里的覆盖比例代表后面十分钟的媒体流量。

另外，临时端口、IP分配、媒体服务器切换之后，上一轮的精确五元组不一定继续适用。自动生成的规则省的是抄写和组合字段的工夫，不会替人决定哪些字段应该固定、哪些应该放宽。

配了弱网却看不出变化，我会按这个顺序查

第一眼先看入口端口 RX。如果这里没有目标流量，就先查接线、路由、终端出口，别急着把丢包率从1%改成10%。尤其终端还有 Wi-Fi 或其他网卡时，业务不一定走自己以为的那条路径。

端口 RX 有流量，再看目标虚拟链路对应方向的 RX。前者增加、后者不动，优先查规则所在端口、启用状态、条件、处理动作，以及前面是否有更宽的规则抢先匹配。不是先怀疑“延迟设置太小”。

链路 RX 已经增加，再看仿真模式和应用状态，并对照链路出口、物理端口 TX 和抓包。这里看的是目标业务，不是端口上所有流量的总和；其他旁通业务还在传输，端口总速率当然不一定等于这条会议链路的限速值。

还得选对探测方式。只配置 UDP 媒体规则，却用普通 ping 去验证，ICMP 可能走的是旁通，RTT 没变化并不能证明规则无效。要么观察已经命中的 UDP 流，要么为这次方向核对单独安排 ICMP 或全流量规则，做完再恢复。

比如，去程固定增加80ms、回程增加120ms，在探测报文确实命中这两侧规则、没有额外排队等变化的前提下，RTT 的配置增量应约为200ms。它是两个方向相加，不是看到80ms就要求往返也只增加80ms。

抓包里有 Port RX、Port TX，以及虚拟链路损伤前、损伤后几个位置。同一个包可以在不同位置留下多条记录，核对数量时要分抓点，不能把所有记录相加当成业务发送包数。

当前 Web 页面也不提供单条过滤器的独立命中计数。目标链路 RX 能帮助判断流量是否进来；若多条规则都指向同一链路，仅凭这个总数还不能说明究竟是哪条命中了，需要结合报文字段继续核对。

域名过滤和 App ID，留到基础规则清楚之后再用

如果服务端 IP 经常变化，域名过滤值得考虑。但“DNS过滤器”和“域名过滤器”不是一个功能。

前者处理 DNS 报文本身，例如给解析请求加延迟；后者利用可见域名、SNI 或 DNS 关联等信息识别业务流。只损伤 DNS，不等于后面的媒体和 HTTPS 连接也进入了弱网。反过来，域名规则利用 DNS 信息建立关联，也不代表它会把 DNS 报文本身送进去。

App ID 则需要目标应用的签名库和可用识别证据。自研会议软件不能因为属于“视频会议”，就默认能按一个通用名称完整识别。没有合适签名时，先用已确认的终端、地址、端口、VLAN 等条件更容易解释结果。

对卫星会议的分阶段测试，我会先保证能准确控制一条已知业务，再逐步加入更多连接。要测整个卫星接入环境，则回到整条接入路径的覆盖问题，不能把精确筛选媒体的用例冒充完整网络环境。

这也是我看重 WE-101 这套软件功能的原因：可以从整条接入链路开始，再收窄到一组业务，发现条件不对又能回到抓包里核对，不需要把每轮测试都做成同一种粗放的全流量损伤。

测完恢复网络，不一定要点 Reset

临时取消这轮损伤时，可以把当前测试对象切回 Bypass。它不删除已有规则和链路，切回 Emulation 后，配置会恢复生效。第二天继续测试前，要先看当前选中了哪个引擎和端口对，再看它处在哪个状态。

Reset 不是同一件事。它会删除当前端口对的虚拟链路、过滤器和 QoS 通道，不适合当作日常的“暂停”按钮。要保留的配置先导出，再决定是否清理。

有抓包结果需要留存时，也先下载到电脑再删除任务。按当前使用手册，删除抓包任务还会删除该任务已经保存到设备磁盘的文件和下载缓存，不能以为按过一次“保存”就永远还在。

顺带说一句，按业务分类不是网准通才有。Apposite Netropy 的公开资料同样列了 IP、VLAN、TCP/UDP 端口等分流条件，以及延迟、丢包、队列和 REST 自动化。拿四口配置对照，Netropy 10G2 是四个1/10G SFP+口、两个引擎；WE-101-N4G 是四个千兆电口、两对双向链路。Netropy公开按每端口对最多30条WAN链路介绍，网准通资料列系统全局最多4096条虚拟链路，统计范围不同，不能直接相除当性能倍数。Netropy具体芯片路线在这里不作推定，本文操作针对网准通的DPDK功能。

已经选了 WE-101，后面更值得花时间的是把这套用法固定下来：先确定测试范围，让正确的流量进入正确的方向；再用抓包生成和检查规则；最后拿对应的统计、报文和应用表现一起判断。网络损伤仪的价值，不只是能把网络调差，还在于能说清楚，这一次究竟把哪部分网络调差了。