奇正科技_ADOBE福建的唯一授权金牌经销商_微软公司的核心经销商_autodesk的福建区核心经销商_COREL福建省独家经销商_Unity福建授权技术服务商_金山公司(WPS)福建金牌经销商_PTC核心经销商_Altium福建核心经销商

虚拟云网络专辑|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公众号

Copyright©2018-2022 www.qizsoft.com All Rights Reserved 奇正科技(厦门)股份有限公司 版权所有
备案号:闽ICP备05021918号-1
服务热线 0592-2208610
点击QQ咨询
微信客服扫一扫 微信客服