微信号:frontshow

介绍:InfoQ大前端技术社群:囊括前端、移动、Node全栈一线技术,紧跟业界发展步伐。

下一代实时网络技术解析

2018-10-19 16:04 孙雨润
近日,声网 Agora 合伙人 & 高级架构师孙雨润在 Qcon 上海站分享了主题演讲《下一代实时传输体系结构的升级与应用》,以下为演讲实录。
声网 Agora 的成绩

2016 年 4 月份北京 QCon,我跟大家分享过我们技术的雏形,当时的题目叫“全球实时音视频传输的技术挑战”,演讲中分析了全球音视频传输的各项技术难点以及我们的解决方案,希望我们提供的服务能帮助各位开发者和工程师打造出成功的产品。

当时平台上每天会有 100 万分钟的实时音视频使用量,经过 3 年的发展,现在已经增长到每天 3 亿分钟。在平台上注册的项目数从 2,000 增长到 100,000,并且现在全球有超过 20 亿设备安装了我们的 SDK。

让我最兴奋的是同时每天通话分钟数从当时的百万级别到现在的几亿级别。几亿分钟是怎样的级别,大家可能没有概念。举个例子,中国联通大概一天的通话量在十几到二十亿分钟,中国联通已经做了几十年,是几千亿市值的公司规模,我们在互联网上经过三年的时间就做到了和运营商同级别的通话量。

我们的用户不仅来自比较发达的地区比如说中国、北美,欧洲,同时中东、中南亚、非洲、俄罗斯这些地方活跃用户数也在快速增长。

实时互动技术平台成为技术爆款

现在 Internet 发展的太成熟,以至于很少听到一项技术革新能催生大规模爆发式的用量增长。

目前大家所见的爆款基本都是在应用层面,比如抖音、快手、头条、微博、微信,每一个用的都是成熟的技术,在应用层面解决了用户的痛点,在产品设计和用户体验上取胜,成为爆款。但我们确实已经很多年没有在技术上拿出让大家眼前一亮的爆款了,VR、AR、MR 某种程度上肩负了可能成为技术爆款的使命,但从普及程度和用量增长的数据上就能看出,它们仍处于探索阶段。

为什么如此成熟的互联网此前却无法满足巨大潜力的实时互动需求?

大家可以想一个问题,Internet 到底能做什么。假设你是中国上海的电信用户。如果美国有一家电商把自己网站放上线,例如 Zulily 这家美国比较小众的母婴网站。为什么中国电信的用户就可以直接访问到 Zulily 这个网站呢?中国电信用户难道要告诉 Zulily 说“我这边有一个上海的用户”吗?或者 Zulily 公司要告诉中国电信要上线一个网站吗?都不需要。

全球有 18.6 亿网站,中国电信有 5.6 亿用户,两边都在不停地增长,如果通过两边互相注册、互相告诉的机制是不可能实现今天互联网的蓬勃发展的。那隔着大洲、大洋,大家如何知道彼此,并实现连接呢?答案在于 Internet 的两个支撑它迅速成长的技术特性:互联互通性、高可扩展性。

中国电信只需要告诉美国 Level 3 运营商哪些 IP 是自己的,美国运营商 Level 3 也只需要告诉中国电信他有哪些 IP,可通过这些地址访问我。这些就是路由信息,运营商通过边际网关协议 BGP4 来完成路由信息的交换。

进一步由于这些信息量量增长太快,所以他们会有路由的压缩忽略细节,比如说中国电信可以告诉对方从 1 到 10000 是我们的,美国运营商告诉他们从 10000 到 50000 是我们的。这样一个新上线的网站不需要专门通知中国电信的用户,而是在彼此交换的汇聚后的路由信息中包含了访问的方法。

Internet 是 Best-Effort 系统,没有高可用性的质量保证

虽然能随意的全球访问,但长期以来中国大陆的互联网用户都可能遭遇过以下三种问题。

(1) 当我们访问国内其他运营商的时候很容易失败、网速很慢。很多年前就有“南电信北联通”的说法:如果你是电信的用户在打游戏的时候会推荐你选择电信 1 区、2 区,但要是你登陆联通的区,打游戏可能会很卡。

(2) 你用二级小运营商的时候会很慢,其实小运营商自己是没有线路的,他们要借助中国电信、中国联通的线路。电信 100M 的宽带价格大概是 1000 块钱一年,但小运营商可以做到 300 块钱。小运营商租中国电信、中国联通的线路反而能够提供更廉价的服务,听起来很奇怪。因为他们把带宽、线路复用了,在晚上高峰期的时候小区楼可能就是一个局域网,导致带宽资源竞争。

(3) 在访问国外资源的时候会非常不爽,前年中国电信推出了“氮气瓶出国加速器”的服务,就是为了尝试解决高峰期访问海外资源非常慢的问题,比如说游戏从海外服务器下副本,或者你看海外的视频,体验很差。

这些问题的原因在于运营商之间、地区之间访问有很多政治、经济、商业上限制的条件。比如说 2018 年 1 月份的时候国家 CNIC 发布了一个报告,中国出口带宽电信是 3.6T,联通有 2T,移动有 1.5T。网民规模已经达到了 7.8 亿到 8 亿的量级,理论上如果人均出口只有几 K,即便是有 1% 的用户有出国的需求,也最多不超过 1M,这就是为什么我们在晚上高峰期的时候访问海外资源会感觉到非常非常缓慢,这还没算上出国流量不均衡等问题。

我们再回过头看一开始举的例子,在国内跟中国电信签约可以访问 zulily,因为 Internet 的互联互通和高可扩展性。但如果咱们工程师用 chrome 浏览器打开开发者模式看网站首页每个资源下载的时间,在我家里电脑上把整个所有的资源、图片加载到本地用了至少 1.5 分钟。

所以我们可以给这个问题一个结论:Internet 能解决什么问题?能解决你非常方便访问全球的资源,但是缺点是没有 QoS 保证,是 Best Effort 系统,没有保证,也没有办法满足 Inelastic 的应用需求。如果要求数据包必须在多少毫秒内到达、要求发 1000 个包必须要到达 995 个以上,这些 Internet 是做不到的。

为满足实时、有 QoS 保证的网络传输需求,业界做了哪些尝试?

难道只有我们团队注意到了这样一个事情吗?并不是。为了满足实时和有 QoS 保证的技术需求,从高校学术界、科研机构、到工业界,像思科等大公司都意识到了这样的问题。他们尝试过哪些解决方案呢?我给大家回顾一下。

第一个解决方案是用专用的 WAN。Internet 是一种互联网,但是互联网并不是 Internet。为了实现质量保证,能不能自己再建一个互联网?这需要铺设线路,搭机房,城市之间通过专线连在一起,成本非常高。如果不是家里有矿或者开运营商的,很难把这件事情做起来。

第二个解决方案是 MPLS 专线。美国一些运营商像 Sprint 他们在这方面做了早期的尝试,现在也做的比较成熟了。他们把 MPLS 的接入点叫 POP(Point of Present),放在全球的各个数据中心,在他们之间通过专用的线路连接在一起,这部分专线是不开放给 Internet 用户使用的,所以他们的带宽是有保证的,也很少有拥塞和丢包的问题。如果在座各位有来自大公司,比如微软,在西雅图、上海、北京都有办公楼,有可能就是通过这种方案实现互联互通的。

这个方案的缺点是,不能适用于移动互联网的使用习惯,同时它的地区覆盖存在限制,它的接收点大部分集中于发达国家,而像中东、非洲、南美这些地区仍缺少接入点。另外,还需要施工,把线拉到你所在的办公环境。

第三个解决方案是 SD-WAN,本质上还是通过 MPLS 的专线来实现有质量保证的传输,但是做的改进是当我不需要实时以及不需要保证的时候走公共的 Internet,它有软件控制的模块线路的选择切换,节省使用专线的成本。可想而知它还是基于上一代 MPLS 线技术,专线所遇到的局限缺点它也都会遇到。

第四个解决方案是 SD-WAN as a Service,云计算的时候大家听到了很多“as a Service”,PaaS、IaaS,像 Aryaka 等 SD-WAN 公司想把 SD-WAN 也 as a Service,也就是作为一项服务,给终端用户使用。用户需要通过 Internet 接入到 Aryaka 的接入点,之后数据就跑在 Aryaka 的骨干网上。传统的 MPLS 部署可能需要几个月,而现在一两天就可以了。

技术改进的三个方向:软件化、共享化、服务化

回顾这四个阶段的改进发现它们有一定的规律,想通过软件化、共享化、服务化三个维度解决全球有质量保证传输的难题。

(1) 软件化:历史上我们做过很多硬件化解决问题的尝试,像 IP 的协议里有为 QoS 保留的字段,标注着不同 Level 的 QoS。本意是希望路由器交换机等设备保证多媒体包的传输质量,但是历史证明是失败了。如果这样有效果,所有的应用都会把这一个字段标成是一定要保证传输质量的,又回到了原样。想通过升级硬件设备来解决问题也解决不了,因为互联网实在太庞大了,交换机、路由器如果彻底更新换代太难了。

(2) 共享化:不需要各个运营商的专线资源。一边是专线专网建设成本高、增长速度慢,另一边是高带宽 inelastic 应用使得对 QoS 网络需求急剧增加,专线资源依然解决不了 Internet 上大规模大范围的用户的实时互动需求。

(3) 服务化:利用技术将 QoS 网络本身交付给客户,而非销售设备再继续增加客户的维护、管理成本。

2016 年我们做了一个尝试,Agora SD-RTNTM,对上述 3 个方向问题解决得更为彻底。软件化方面从需要特定的 SD-WAN 硬件设备,简化到只需要装有 linux 操作系统的 X86 服务器;共享化方面从需要各个运营商的专线资源,简化到只需要公共 Internet 带宽资源;服务化方面从需要在客户提供的场所进行部署安装,到账号开通立即使用,从特定场所接入的限制,扩展到 200 个国家和地区,对 LAN、 3G、 4G 用户的覆盖。

PaaS 服务平台要解决的问题

软件化、服务化、共享化不是我们提出来的,也不是业界在解决这个问题提出来的,是整个 PaaS 服务平台都需要满足的条件。大家想一下 Google 的实时翻译、高德地图、AWS,都需要沿着软件化、服务化、共享化推进。

那么 PaaS 服务平台解决的是什么问题呢?

  1. 一定是系统的基础模块 Fundamental part of a system;

  2. 开发者和公司都需要的某种能力;

  3. 大多数人不喜欢做的;

  4. 很复杂很琐碎的事物;

  5. 很难解决的问题;

  6. 同时还是 Application 体验,以及成功决定性因素之一。

总结起来:PaaS 服务要解决的是困难,但解决后能深得人心的问题。

它的价值是提供开发者所需要的基础技术,特别是非核心但又存在普遍需求的技术。

把 PaaS 服务平台当成水电煤来类比的话:平台就是提供水电煤资源,SDK 就是水龙头、电饭煲、燃气灶,开发者就是厨师。厨师关注的是做的菜怎么样,关注的是西红柿炒蛋味道怎么样,而不是关注怎么劈柴怎么生火。

PaaS 服务会像水电煤一样通用。下图是大家耳熟能详的 PaaS 服务,像即时消息 SDK。如果你想做一个类似 QQ 这样的 IM 功能放在客服的系统里,需要自己开发离线消息、上线下线通知等服务吗?有人把这些事情做了最好。还有地图导航、语音输入、留存统计、Crash 分析,当然还有我们声网提供的 RTC SDK,这样可以让 Application 开发者专注在业务逻辑、玩法、体验、创新、场景。

什么是好的 RTC PaaS 服务?

那什么是好的 RTC PaaS 服务呢?我们最初做这个技术平台的时候,也在时刻思考这个问题。因为市场上没有先驱让我们追赶,我们必须自己想清楚怎么定义好的 PaaS 服务。

好的 PaaS 服务第一是 Reliable,要稳定不出事儿,要像水龙水一样随时有水,如果家里水龙头不出水,那要打一个差评。

二要 Scalable 和 Efficient,也就是保证大规模、高并发,仍然拿水做例子,要能同时满足十几亿人的用水需求。RTC SDK 平台要做到今天,就算有 100 万观众的线上演唱会,也能够稳定支持,且质量不打折。

第三,Performant。这是立身之本,要解决技术难题,要有门槛,这是 PaaS 平台与外包团队的本质区别。

第四是 Self- Service 和 Easy to use,自助服务和易用性。我用你的服务做音视频实时通信、实时互动,当音视频卡顿的时候我要知道为什么,我还要知道全球 1000 万用户有百分之多少是对质量满意的。这个识别不仅要准确,还要把质量给透明出来,提供给开发者。要做一个成功的 App,开发者和 App 运营者需要对数据门儿清。

第五是 Cost-Effective,要节省成本。像 AWS 等云服务成功的原因之一是他们相对于 dedicated server,能提供较低成本的服务。

我把它放在这样的图里,划分的更清楚:要支持千万 CPU、千万 PCC,任意速度涌进频道、在全球能够覆盖多少国家和地区,网内传输达到什么样的水平,这些都是我们要追求的技术目标。

声网 SD-RTN™当前的技术水平之一:传输

接下来给大家讲一下,目前平台的技术水平能做到什么程度。首先是全球海外覆盖,接入节点在全球覆盖是非常重要的,如果没有办法在某个地区提供在当地有质量保证的用户接入服务,我们客户的产品很难在这个地方运营。客户问我们服务质量的时候,经常会问在中东有没有接入点,有没有质量保证?如果没有保证客户花了钱投了人力在中东、非洲这些地方出海运营了,但是效果不好、体验不好,那么我们这个云服务是有问题的。

作为一个开发者怎么确定在非洲到底有没有覆盖,在巴拿马、阿尔及利亚有没有覆盖呢?有一个经验的公式。如果一个统计周期里丢包小于 5% 的话,传输层面可以通过 FEC、ARQ 等手段把信息恢复出来,因此可以把丢包小于 5% 作为优质传输点。

优质传输点与该地区所有统计数据点做比值,占所有统计点里的比例就是在这个地区的优质传输率,当然,实际使用时针对各地区各运营商还有很多细节要补充矫正。优质传输率能够直接反应 PaaS 服务的覆盖水平,在中国大陆对电信、联动、移动、华东、华南的覆盖率到底是多少。目前为止在平台上全球分钟数过万的国家有 120 个以上,覆盖水平良好和优秀的能够超过 90 个。

第二个立身之本是网内传输的技术目标。网内传输要达到专线级别的水平,这是用 PaaS 服务、实时传输服务最关键的指标。一个用户在澳大利亚,第二个用户在山西,第三个用户在俄罗斯,他们能不能得到很好的传输体验呢?

刚刚说到有 20 亿的 Application 在平台上跑,大家可能好奇到底是哪些应用在用,我可以给大家列举一些比较有代表性的。2017 年比较火的是《狼人杀》,为什么一个历史很悠久的游戏在 2017 年的时候在线上突然火起来了呢?也是由于背后 RTC 技术的驱动,技术能够解决一个房间里 13、14 个人无论在全球任何地方都可以实时交流,就像人在身边一样玩游戏。

2017 年全球有 80% 以上的《狼人杀》都是跑在声网 Agora 这个技术服务平台上的,类似的应用场景还有很多,都集中得到了满足,这也是为什么这个 PaaS 服务在短时间内实现了从百万级到几亿级别的分钟数增长。

除了像《狼人杀》这种游戏类产品,还有一些更典型的应用。有一家公司做了一个眼镜,它能解决什么问题呢?某运营商把自己的机房布在全球的各个角落,甚至是荒山野岭、山上等等人迹罕至的地方,他们派工程师到现场解决问题的时候经常遇到很难解决的问题,需要传回来给专家解决。那家供应商做了一幅眼镜,眼镜把现场的录像实时传到总部、或者专家所在的任意地方,邀请该运营商的全球专家来分析解决问题。

眼镜背后的数据传输这也是基于这个平台来做的,大大提高了该运营商在全球设备故障诊断修复的效率。反过来这些设备的快速修复也帮助了 Internet 更加稳定,事情就这么有趣。

日本有些医院也在用我们这项技术,国内一些小孩儿不幸患有很特殊的病在国内没有合适的主治医师和外科大夫做手术。这些医院和日本的医院有合作,日本医生远程与国内医生一起会诊,给出关键的专业意见,跟国内医生一起完成小孩子的手术。

看到这些案例的时候,我们做技术的会有满满的成就感。这些应用的背后都是对于跨国、跨地区有非常强烈的要求,这也就是为什么我们要把网内传输做到接近专线级别的水平。下图是美国第三大供应商 Sprint 提供的专线质量,分为 Intra-Reglon 和 Inter-Region,这是他给的 SLA 来约束自己提供服务的质量。

SD-RTN™与它质量接近,另一方面给大家对比一下声网 SD-RTN™与运营商专线在成本的巨大差别:Sprint 提供的专线服务成本大概是 600 美元左右 1Mbps,换算成人民币 4000 元左右。那么公共互联网 1 兆大概是专线 1% 的成本,如果能够通过软件技术、利用公共互联网的成本实现几千块钱的专线质量,对于开发者和普通 Internet 用户就太友好了。

我们在平台上抽取过各个地区两秒之间的质量,除了印度和国内有的时候会质量不好之外,其他的时候都已经达到了专线级别的质量。大家在评价平台的时候除了看刚才的丢包小于 5% 的比例,还有一点是更严格的:是以 1 分钟为统计周期,这 1 分钟丢包要小于 0.5% 就认为传输不稳定。一天 24 小时有 1440 分钟,一共有多少分钟传输不稳定,这个能衡量传输网的核心能力,也是大家对比其他相同 PaaS 服务的参数之一。

左边是通过公共互联网没有改进时候的不稳定质量,像中国到东亚一天又 377 分钟是不稳定的,中国到欧洲有 247 分钟是不稳定的,但是经过软件技术保证以后都能够降低到个位数甚至 1 分钟以内。

软件路由技术能够实现专业级别的数量是大家过去 30 年都想做到的成就,但是在学术界有限制,学校实验室里不具备这么大流量、机房、实际的带宽跑,有很多问题是需要实际跑出来才能知道的。

除此之外还有一些技术是我们要来探索的。小学的时候《自然》课本里有土电话:跟隔壁房间通话,用两个杯子中间系一根绳子做的土电话,反而比经过运营商网络绕一圈更好。我们也发现,像在大学宿舍里和隔壁宿舍做实时通信、玩《狼人杀》,通过 SD-RTNTM 网络绕一圈的质量,有时候可能没有直接发给隔壁宿舍更好。

下面这张图里,我们把传输分成 3 种,绿线代表不同的区域、不同的国家,蓝线是相同的区域不同的国家,红线是完全相同的国家。完全相同的国家,再加上相同运营商、地理位置比较近的时候,理论上某些情况下使用 P2P 技术能获得更好效果,但要以质量和体验为目标。

做我们技术驱动的云服务公司成就感来自当你技术改进的时候,用户的使用量和用户的体验是以非常直观的数字能够告诉你结果的。我做了 A/B 的对比,印度地区带优化之前和之后,降低了丢包率、延时,最后用户的使用时长得到了大幅增长。

印度的高端人口喜欢往美国走,而很多普通民众会到中东打工,所以印度到 UAE(阿拉伯联合酋长国)之间的数据流量是很大的,这里面有强烈的需求。当你优化这里面传输质量的时候,同样的场景,同样的 Application 平均使用时长有大概 40% 、50% 的增长,质量是决定 Application 体验的关键因素之一。

声网 SD-RTNTM 当前的技术水平之二:Scale

服务的另一个关键点是 RTC PaaS 的稳定担当是 Scalable 和 Efficient,互联网所有的硬件设备,包括网线、交换机、路由机都会出故障,经常看到新闻一些大的互联网公司说网线又被挖断了,引起了服务故障。不过声网在历史上基本没有出现过全网故障,怎么保障高可用性呢?

关键原则之一是一个区域内至少做足够的对等的部署,当任何一个线路出现问题的时候可以无缝地切换到另一个线路,在用户没有感知的情况下切换。另外在架构设计的时候还要遵守第二个原则,再大的故障也不能超过 20% 的影响范围,20% 在技术要求里是一级故障,技术设计上要做分区、隔离。第三个原则是任何技术改进都以不打扰用户为底线,做好预埋、兼容、灰度上线、A/B 测试,我们内部叫飞行中换引擎。

在大规模用户的支持上还是很有挑战的,一开始 SD-RTN™这个传输平台是针对一对一来优化的,但后来发现有实时大频道的需求。

2017 年的时候和沪江合作,做了 50000 人学生的大课,把中国山区和偏远地区的学生都组织起来上公益性质的教学大课。这些地区的师资力量很差,不过在中国经济飞速发展的一个结果是他们的网络条件是很好的,都有 4G,家里都有电脑。

沪江会联系英国、美国的外教,外教们会把很多学生拉“上麦”,带他们一起读英语,一个个纠正山区小孩儿的发音。山区小孩儿可能从来都没有见过外教,也没有体验过真人带着他们读英语,沪江和声网通过 SD-RTNTM 这个传输网络,把外教和山区学生拉到了一起。

50000 人实时互动的技术难点在于流量与传输的模型会实时变化。比如说一开始只有一位老师,码率是 1 兆,算下来是 50 个 G 的流量,这个时候如果有学生来连麦作为第二个主播加入进来,网络上的流量都会翻倍成 100G,如果有 5 个 10 个小孩儿都加在线上的话流量还可能继续翻倍。

流量突然增长的话对每个节点会有很大冲击。比如对于 G 口网卡的服务器,本来可能已经跑了六七百兆了,再来 5 个 10 个小孩儿的时候怎么办呢?这里面就要架构的实时调整,还要让终端用户没有感知。

总结

怎么衡量好的 RTC PaaS 服务就是这几方面:架构能水平扩展,能够支持高并发、大频道,能够支持任意蜂拥速度进频道。同时在全球各个地区的覆盖水平、在网内传输质量水平等 Perfomant 方面有非常苛刻的要求,能够满足医疗、教育、游戏等方方面面应用的需求。

全球最大的实时应用技术平台实现了迅速的增长,此前 Internet 为什么需求没有释放呢?因为没有 QoS 保证。我们通过软件化、服务化、共享化解决难题,实现 Carrier Level QoS,从而带来用户从百万到几亿规模的增长。相信在接下来三年用量仍然能够实现 1000 倍的增长,让全球凡是有智能手机的用户都能够享受全球范围的、实时有 QoS 保证的技术服务。

谢谢大家!

Q&A

提问:在现在成熟互联网应用技术较为成熟的前提下,能不能在局域网里,或比较复杂的异构网络中使用您这边提供的 PaaS 服务?

孙雨润:你提的问题是私有化部署。我们的大服务是建立在 Internet 基础上,但其实很多客户、开发者都有这样的需求,尤其是在金融、政府等行业。现在我们也在和银行、金融机构、运营商做合作,已经基本解决了此类问题。

提问:如果在内容传输过程中需要对内容的审核,你们在软件层会不会有通用的解决方案?

孙雨润:尤其是出海的直播,海外国家都面临内容审核的问题,尤其中国更严重,但是中国一般比较保守,海外的妹子们都比较开放,他们这类产品在海外运营的时候受到政府更为严格的监管。目前我们自己没有提供这样的技术,但是我们有和其他公司合作,提供对图片、视频,进行分析并过滤。现在会为用户提供深度集成的解决方案,不需要用户自己开发。同时我们也预留裸数据的接口,开发者也可以灵活地接入其他供应商接口来完成对内容的审核、鉴黄。

 
前端之巅 更多文章 Vue CLI 2&3 下的项目优化实践:CDN + Gzip Mozilla是如何提升JS和WASM之间的调用速度的? Chrome 70正式版发布:Windows端将支持PWA ECMAScript 2016\/2017\/2018新特性详解 浏览器页面渲染机制,你真的弄懂了吗?
猜您喜欢 梯度下降法求解线性回归之python实现 DaoCloud启动分享写作计划,让开发者的声音更响亮 编程神童?澳洲10岁男童自制5款app,库克都为他疯狂打call! 程序员的成长路线 学员面试,8个错误不要犯,切记!切记!