MENU 导航菜单

虚拟云网络专辑｜VMware SD-WAN：实验验证，实时语音及影像的质量优化

奇正资讯 > 奇正要闻 更新时间：2022/4/15
这个技术主要是针对语音及影像等 UDP 串流应用，在传输时如果碰到线路质量不佳，针对网络流封包本身进行的优化。

在展示前，下图可以给大家一个概念即 Velocloud 对于不同的应用网络流型态，会进行哪些优化机制：

图片

在上图内，大家可以看到针对被定义为 Real-Time 且会是Multi-Path  (受 Tunnel 保护) 形态的应用。

除了在多线路上会采用 Per-Packet Steering 的方式去做线路的选径与优化，同时也会对应用进行 FEC 与 Jitter Buffer 的优化 (Remediation)。

当然，通常我们对于重要的语音或影像，比如网络电话、影像会议等等，都会列在这一类。

在这个的展示内，我们需要实验组与对照组，因此与前几篇不同，我们的网络环境配置会变成下面这样：

图片

从 Branch-03-Linux (10.100.103.12) 往右上角的 Hub-01-Linux (10.100.101.12) 间，是有建立 Velocloud DMPO Tunnel（绿色虚线），受到保护与优化的线路。

但在左下角的 Branch-06，这个分点并没有安装 VCE，而是透过基本的路由与其他分点或资料中心连接。

因此由 Branch-03-Linux 到左下角的 Branch-06-Linux (10.100.106.12) 的网络流（红色虚线），就是一般未受优化、未受保护的线路。

在这个实验内，我们利用广域网路模拟器，限制 Branch-03这边的 MPLS 线路频宽上下行都是 1 Mbps，然后将Packet Loss调到3%。

大家可以看到，在VCO界面上，Branch 03 VCE 的线路状态有反应出这个状况：

图片

接下来我们先看正常环境内，没有受到 Velocloud 保护的线路（前面的红色线），在这样的对照组网络状况下会有什么情形。实验的方法如下：

· 在 Branch-03 / Branch-06 的 Linux 机器上都安装 iperf3 测试工具。


·将Branch-06-Linux 作为 iperf3 的 server 端：# iperf3 -s -V。


· 从 Branch-03-Linux 上启动 iperf3 的 client 端发动测试，指令为 # iperf3 -c 10.100.106.12 -b 400k -t 300 -u 。


这个指令要求从 Branch-03-Linux 发动 UDP 的测试网络流 (-u) 到目的地 100.106.12，测试频宽为 400 kbps，然后持续 300 秒。

下面是测试结果的画面：

图片

上图内，大家可以看到发动这个命令后，在 Server 端  (Branch-06-Linux-1) 总共于 300 秒内接收到 1831 个 UDP 的封包，平均频宽为 400 Kbps，里面丢掉或错误了 287 个。

也就是说，虽然在线路的 Packet Loss 是 3%，但实际测试内，有造成接近 1/6 的封包出现问题。

大家可以猜想一下如果你们实际的语音或影片传送时，有 1/6 的封包出错了，这个电话还打得下去吗？

而在上面这个测试内，从 VCO 可以看到 Branch-03 的VCE 线路状态，MPLS 线路上有平均为 400K 的网络流。

图片

接着是真正的实验组，也就是由 Branch-03 到 Hub-01间，受到保护的 Tunnel 线路（前面的绿色虚线）。

首先，在我们的 Business Policy 内，设定 UDP 的传输保护方式如下：

图片
图片

上面两张图内我们可以看到，对于 UDP 型态的封包，我们Business Policy 的要求为：

· 必须要走 Tunnel (Multi-Path)


· 强制走 MPLS 线路 (Transport Group: Private Wired, Available)


· 把这类封包定义为高优先权 (High) 的实时类应用 (Real-Time)。在这种交通型态内，等下我们要展示的 FEC 机制将会启用。


做了这样的设定后，我们在 Branch-03-Linux 内做与前面一模一样的测试，只是目前的目标改成指向 Hub-01-Linux (10.100.101.12)。


结果如下：

图片



一模一样的频宽与时间，大家可以看到在 Server 端 (Hub-01-Linux-1) 总共于 300 秒内接收到 1830 个 UDP 封包，平均频宽为 400 Kbps，但里面丢掉或错误仅仅有 14 个，比率为 0.77%。

和前面同样情况下有 16% 的封包错误，大幅优化了 95% 。

但是 FEC 的机制是怎么做的呢？发生了什么魔法让封包丢失率大幅下降呢？

其实很简单，看下图就一目了然了：

图片

虽然我们发送的是一个平均 400 Kbps 的串流，但 MPLS上 DMPO Tunnel 实际的传输量却是超过 800 Kbps。

为什么？因为 FEC 的运作机制如下：

· 对于被设定为 High / Real-Time 形态的网络流，如果侦测到线路掉包率过高，则启用 FEC 机制。


· 此时在 DMPO Tunnel 的串流来源端，会直接把网络封包多复制一份，每个封包在线路内都丢两个出去。


· 这时候即使线路质量不好会丢包，可能运气也没有这么差，两个封包都丢掉吧。


此时在 DMPO Tunnel 的串流目的端，如果收到两个一模一样的封包，就移除其中一个传出。


如果同样封包只有一个（表示一个遗失了），那就把这个留下来的继续送出去。


运气很糟的状况下还是有少数两个都丢包了，那在应用端才会感受到有掉包的状况。


透过上述的机制，当 Velocloud 方案在实际客户端用语音或影像串流验证时，客户能够确实感受到重要的实时应用质量受到保障。

当然这个机制不应该套用在所有的 Application，因为频宽会大幅上升，但对于高阶长官或是业务重要的语音应用，有这样的优化保护，网络管理者的压力会减轻不少。



本文章转载自VMware公众号

下一篇：虚拟云网络专辑｜NSX 分布式逻辑路由器概述 上一篇：工业软件上云的矛与盾