合作伙伴：

【直播领域】

语音互动平台  轻寻（http://www.qxjiaoyou.com/）

视频直播平台 安客秀

【嵌入式应用】

国内水下机器人领导者：深之蓝海洋科技（http://www.deepinfar.com）

语音对讲机、北京地铁：北京恒胜东阳科技有限公司 （www.smartconn.cc）

政企项目：宏景科技股份有限公司 （http://www.gloryview.com）

 

一、方案特点

SRTP-Server是在RTP-FEC-QOS传输层基础上建立了一套轻量级RTP直播转发服务器集群，可用于一对多、多对多等场合的音视频实时互动，客户端支持全平台包括PC客户端、浏览器、Android APP、IOS APP。它具备以下特点：

• 超低延时，采用RTP（UDP）作为传输层解决方案，能获得低于300ms的系统延时，适用于实时互动等应用场景。
• 抗丢包能力强，采用RTP-FEC-QOS技术，保证上行线路和下线线路在弱网情况下依旧有良好表现。
• 基于虚拟的房间（教室）模式，支持在房间内广播音视频（RTP）和信令（TCP）。系统不限房间数量，不限单个房间内客户端的数量。
• 支持客户端之间的P2P打洞服务，支持在转发服务和P2P服务之间自适应切换。极大降低服务器带宽成本。
• 集群模式或单机模式可选，集群扩展简便，规模可大可小，灵活配置，避免单点故障。单机模式footprint极小，可用于嵌入式环境部署。
• 负载均衡，将流量（客户端）合理的分配到集群的各台服务器上。
• 自带CDN加速功能，为每个客户端优选最佳的服务器资源，保障用户体验。
• 支持在同一服务器上部署多套完全独立的集群，多套集群并发工作，可以实现不同业务单位的软件隔离，大家共享硬件和网络资源。亦可用于主从备份。
• 服务器同步推送RTMP流到指定服务器，可以与SRS、FMS、Nginx-rtmp结合实现RTP、RTMP、HLS流的同步播出，从而实现全平台的直播。
• 支持TS文件录制
• 客户端掉线自动重连功能，客户端因网络等异常掉线时，服务器将短时间内等待客户端的重连，获得更好的用户体验。
• 支持同一个房间内多达32路音视频，支持音频混音功能。
• 高并发、高稳定性，服务器7*24工作，支持开源NYX监控。
• 纯C++实现，代码精简高效，同时支持Win和Linux。注重编码规范，注释完善，代码可读性强。
• 除使用操作系统底层库外，系统不依赖于第三方库，纯静态编译，部署简易。
• 支持Telnet远程登录服务器程序，支持自定义命令行，管理和维护更加便捷。
• 剥离了业务相关，通用性强，可以快速加入自身业务。

客户端SDK说明：客户端接入sdk-api说明

客户端演示DEMO：

https://github.com/waterfoxfox/fec-qos-demo

https://github.com/waterfoxfox/DEMO_SRTPServer_Client_Win

https://github.com/waterfoxfox/DEMO_SRTPServer_Client_Android

 二、架构说明

                                         图1 一种典型的集群部署情况

1、数据流

图1是一种典型的集群部署方案，接下来我们将对图中各个服务的作用、客户端的登陆流程、数据的分发流程分别予以介绍。

SRTP-Server由Domain服务和Media服务组成，Domain服务有几个用途：

• 充当DNS的功能，为客户端CDN优选提供候选的Media服务器IP地址集合，后面详细介绍。
• 房间管理、用户管理、TCP信令的转发。房间是一个虚拟的概念，同一个房间可以跨多台Media服务器。同样，进入同一个房间的用户也会根据其自身情况登录到不同的Media服务器。Domain管理着这种关系，当一条房间广播信令从客户端A发往Media时，Media除了在本服务器上分发给该房间内所有用户外，还将消息上报Domain，Domain将消息分发给创建了该房间的其他Media服务器，后者将消息分发给各自旗下的该房间客户端们。私有信令的流程与广播信令稍有不同，当私有消息从客户端A发往Media时，若Media发现目标客户端B也位于本服务器上，则直接转发，否则发往Domain服务器，Domain服务器查询到客户端B所在的Media服务器并转发之。
• 维护与集群内众多Media服务器的连接，与Media形成CS架构。

需要说明，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可以实现命令行的交互。