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

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

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

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

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

其实本质上就是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的市场将会是一个云原生的市场，我们很期待这样的市场到来。