EN
首页 / 新闻资讯 / 行业新闻​ / 从视频会议应用谈下一代IDC

从视频会议应用谈下一代IDC

时间:2020-07-04 23:11 作者:小编 阅读量:0

今天和大家一起分享一个实例,从视频会议应用谈下一代IDC

伴随着疫情和在家办公和在家教育的需求,视频会议业务越来越火,而同时直播带货也对网络传输的要求越来越高。各个云公司招了一大堆人还在搞传统的SDWAN或者CDN期待来改善这类应用, 其实是完全错误的。

下面来看一个示例, 我在腾讯云上创建了4个主机,模拟四个需要参加会议的人,分别在硅谷,法兰克福,东京和广州。

从上海ping这些IP地址的延迟和丢包如下:

  从视频会议应用谈下一代IDC

其实本质上就是underlay的运营商BGP策略控制的,那么有一种做法就是类似于阿里云的BYOIP,把你的IP地址拿来,通过阿里云的全球骨干网走。其实这样的做法很大程度的对云提供商有了更多的依赖,企业上云本质上还是需要追求Cloud Agnostic的,毕竟三峡的水电比起大亚湾的核电推出来的HiFi音响声音有区别的只是一个梗而已,同样云作为一种公共服务,以后也会变得谁近谁便宜就用谁。

为了应对这样的问题,很多企业开始多租链路,例如webex,或者在多云那里购买CDN业务, 下面教你们一招如何通过一个新技术,QUIC-SR或者SRoUDP来实现,在云上随便启用一堆container,放一个QUIC-SR的fwd进程, 侦听端口UDP 443. 然后手机App或者Server侧使用QUIC协议通信,例如以quic-go为例:

session, err := quic.DialAddr(*remoteSock, tlsConf, config)

session.SetQUICSR(segList, flowid)

//segList = 106.52.60.176:443,49.51.243.80:443

其实这样就很容易的实现了上海-->广州--->美国--->法兰克福, 我们做了一个隧道实验。

通过隧道时,ping延迟和丢包如下(339ms/0%)

不通过隧道时,直接ping延迟和丢包如下(215ms/20%)

就这样轻松的在internet上实现了流量工程, 同时如果内部协议采用QUIC/HTTP3 over Multicast,或者UDP payload密钥相同,所有参会的人可以构建成一个非常有趣的P2P网络,并伴随着QUIC内生的CONNECTION-ID和Packet-Seq还可以实现adaptive的packet duplication来抗丢包。

而这样的技术,同时也宣告了对SDWAN的终结,我们为啥还要一个隧道呢,直接通过QUIC做代理就好啊,例如我们要访问VPC内的某个服务器,在VPC Gateway那里做个QUIC-SR forwarder就好了呀。

另外QUIC-SR还有好多好好玩的业务,例如运营商可以在它轻载的传输网上提供service-mesh服务来构建一堆QUIC-SR fwd instance,然后直播网红的访问质量就可以完全得到专网保证了, 不需要专门的5G也实现了网络切片的功能,这就是从做应用的角度来看网络。

给网络中每一个节点取一个温暖的名字,应用就能面朝大海春暖花开。

当然只说了转发面,控制面怎么做,各家自己玩吧~最近把QUIC-SR的RFC-draft提交了, 最后变成一个更通用的Segment Routing over UDP(SRoU)的草案,本质上还是为了解决一些视频流传输的问题。当然有人要问,已经有了MPLS/SR over UDP,在这里面SRoU做了什么?最关键的地方就是NAT-Traversal,以及IPv4/IPv6混跑,SRv6的可编程无隧道VPC访问。

其实当你把QUIC-SR-PE看做是路由器的LC, QUIC-SR-FWD看作是Fabric的时候,你已经构成了世界上容量最大的路由器了,要有多少路由就能做多少条,要有多大的带宽多开容器就行了, 而且所有的service,例如DPI/SSLProxy都可以在QUIC-SR-PE上做,例如server端用caddy+quic-go轻松搞定~客户端搞不定,第一跳接入的交换机AP路由器都可以搞定。

这就是网络发展的趋势,从硬件到NFV,再到云原生。未来IDC的市场将会是一个云原生的市场,我们很期待这样的市场到来。

400-028-9798
vecloud-微云