[用户案例:领先的视频直播平台 安客秀(http://www.),多人互动上麦,极低延时, 大容量并发! ] 一、方案特点 SRTP-Server是在RTP-FEC-QOS传输层基础上建立了一套通用型RTP直播流媒体服务器集群,可用于一对多、多对多等场合的音视频实时互动,播发端支持全平台包括PC客户端、浏览器、Android APP、IOS APP、微信。它具备以下特点:
二、架构说明 图1 一种典型的集群部署情况 1、数据流 图1是一种典型的集群部署方案,接下来我们将对图中各个服务的作用、客户端的登陆流程、数据的分发流程分别予以介绍。 SRTP-Server由Domain服务和Media服务组成,Domain服务有几个用途:
需要说明,Domain服务并不和音视频数据打交道,无数据和计算压力。另外,客户端与Domain之间并无TCP或者RTP的通讯,客户端只与其登录的Media服务器存在TCP长连接和RTP数据通讯。 Media服务负责所有音视频的处理并与客户端直接打交道,同一个Domain旗下的所有Media之间创建了P2P的RTP通讯链接,用于音视频数据在Media之间的传输。图1中,当发布客户端A的音视频数据上行到Media服务器A时,Media将在本地房间内广播该音视频数据,同时将数据转发给其他Media服务器,后者在各自的本地房间内向客户端下发。对于接收端与发布端位于同一台Media或者不同Media,数据的传输路径始终是最短的,没有多余的传输链路。 按照架构设计,同一个房间内有多个音视频发布者,且服务端不做多画面合成时(画面数较少),各个发布者可以登录于不同的Media服务器。观众客户端将通过与其Media服务器之间的唯一AV通道获得各个发布者的音视频数据,业务层根据索引来区分音视频数据在属于哪一个发布者,从而显示到对应的位置上。这种情况下,Media之间的地位是对等的。 当服务器端需要做多画面合成与混音时,要求房间的所有音视频发布者登录到同一台Media,此时Media可以称为“代理”,其他Media则称为“中转”。这种情况下,所有房间的所有发布者登录到代理服务器,而所有的观众则登录到众多中转服务器上。 一个集群内Media服务器的数量是不受限制的,当观众规模增长较大到原有系统无法支撑时,只需要扩展新的Media即可,整个部署过程非常简单。正因为“房间”或者称为“教室”是一个跨服务器的存在,所以可以实现不限房间数量,单个房间不限客户端的数量的效果(当然要想在业务层限制也比较简单)。 需要说明集群的规模可大可小,最小的情况下只需要单台服务器即可,此时Domain服务和Media服务均部署于同一台机器。 2、负载均衡 & CDN加速 集群内的各台物理机的处理性能(CPU、内存等)以及网络带宽各不相同,因此能够服务的客户端数量也不尽相同,通过配置文件,我们可以指定每台Media最大支持的客户端数量。当某台机器的负载(处理性能或者带宽)消耗达到较高的比率时,应该优先将客户端安排到其他机器上。Domain维护了域下每台Media的当前负载值以及最大支持负载值,所以可以合理的影响客户端的登录情况。 CDN的重要性不言而喻,当前国内的网络状况相当复杂,形成了“南电信北联通”的局面,还有长城宽带、铁通、教育网也占有较大市场份额。由于跨运营商的数据传输在运营商内部是需要费用结算的,所以运营商主观上并不保障跨运营商的传输质量,音视频媒体传输经常面临延时大、丢包率高等特点。即便是同一个运营商,用户登录就近的服务器也比登录地域上更远的服务器获得更好的传输质量,传输路径最短化是CDN的目标之一。曾有机构做过相关的统计,接入相同的运营商并且地理位置最近的情况下,网络延时最优,小于15ms。跨省同运营商的网络延时为25~50ms,同省跨运营商则达到了50~100ms,跨省更高。 常见的CDN方案是通过用户使用的DNS服务器来判断客户端所在的网络位置,从而返回对应的服务器IP。这种方式的缺点:第一,调度的准确度是完全依赖用户配置的DNS(通常运营商指定),而这些DNS大多数是省级的,比如它只能确定为广东电信,但常常分不出来是广东广州电信还是广东深圳电信。第二,我们不得不在流媒体服务器之外通过另外的WEB服务器实现DNS的IP判定。第三,这种静态的分配方式也许并不能真实的反映线路的传输状况,服务器本身可能出现故障、线路也可能遇上蓝翔,所以需要动静结合。 综上所述,我们在域服务器上实现了一套自己的CDN优选服务,客户端在登录Media之前,将访问Domain服务器,Domain服务器综合考虑当前各台Media机器的资源利用率、运营商类型、地域分布情况以及客户端的运营商类型、地域等生成一组可供客户端使用的候选Media服务器IP地址集合。客户端在拿到该集合后,使用UDP进行测速,并根据测速结果得到最优Media服务器IP地址。 需要说明的,Media服务器工作在“代理”状态时,建议使用BGP多线服务器,因为各种网络类型的发布客户端均需要登录该服务器。 3、抗丢包 & 实时性 SRTP-Server是建立在RTP-FEC-QOS传输层基础上,RTP-FEC-QOS的最大优势就是在保证低延时指标同时能较强的抵抗弱网(WIFI、3G、4G)带来的乱序、抖动、丢包等问题。具体的说明请参考RTP-FEC-QOS传输层说明文档。这里主要说明传输链路的创建情况。 图2 客户端与服务器媒体传输通道的建立 客户端登陆Media服务器时,服务器为其从端口库中分配一组连续的4个端口,分别用于音视频RTP和RTCP(这些端口将在客户端下线时回收)并使用这组端口创建一个服务器类型的RTP-FEC-QOS传输对象。客户端TCP登录成功并收到服务器分配的端口后将使用这组端口创建一个客户端类型的RTP-FEC-QOS传输对象(客户端本地端口和远端端口都使用这组分配端口,这样可以实现客户端的单机多实例)。至此,客户端和服务器之间的媒体通道建立成功,即便双方没有音视频数据交互,通道也会有定时的内部NAT保活包。 4、集群隔离 一组Domain-Media的组合称呼为一个域,同一套服务器集群里可以部署多个域,它们之间将采用不同的端口段以避免冲突。不同域之间是完全独立隔离的,这样我们可以将不同的用户局点隔离开来,避免相互影响,大家共用硬件和网络资源,节省成本。多域隔离的另一个好处是可以实现外网正式版本与测试版本共存,测试环境更加真实。 5、全平台播放支持 RTP协议需要客户端才能予以支持,PC浏览器、移动端浏览器(微信)只支持RTMP、HLS、HTTP-FLV、DASH等流格式,为了做到全平台的播放支持,SRTP-Server支持向用户配置的指定地址推送RTMP流,借助第三方流媒体服务器FMS、SRS、Nginx-rtmp便可以实现全格式输出。 图3 支持rtmp流推送的一种情况 图3是SRTP-Server支持RTMP推送的一种情况,我们在Media服务所在的服务器上部署了Nginx-rtmp,这样Media在收到媒体数据后只需要向rtmp://127.0.0.1/live/roomXX地址(XX为Media自动添加的房间号)推送媒体流即可,这样本地socket延时也非常小。需要说明的是WEB播放器也应该使用websocket通过Domain获得优选的Media服务器,这样我们可以通过Domain控制整体的负载。 6、维护手段 SRTP-Server除了提供日志输出外,还支持远程telent连接,通过telnet可以实现命令行的交互。 三、方案价格 方案以源码方式出售,该方案同时也包括了RTP-FEC-QOS方案,价格另议
|
|
来自: 昵称19447302 > 《直播优化相关》