网络在线直播系统，一般过程是：采集→前处理→编码→推流→分发→拉流→解码→播放，每一个阶段都会占用一部分的时间，所以说为了保障用户观看的及时性，这些流程都需要高度的配合统一，这样才能降低在线直播的延迟问题。

　　我们先来说说什么原因为导致直播延迟。

　　第一，网络波动

　　我们这里所说的网络波动就是说在排序好的数据包中，有任何一包被延迟，就会导致它不按照正确的抵达顺序到达用户端，自然也无法按照接受顺序把内容播放出来，呈现在用户的接收屏上。网路波动会导致网络的内容播放的延迟和直播卡顿，但是这个原因只能算作是直播延时的外部因素，与本身的在线直播源码没有多大的关系。

　　第二、网络丢包

　　在线直播源码使用的流媒体传输协议有：RTMP、HLS、HTTP FLV等，传输过程一般是：主播端向服务端发送连接请求→服务端同意→主播端确认连线。

　　经过上述的三个过程，主播端才会持续的进行数据的分批发送，每发送完一批数据都需得到服务端的反馈才能进行下一步，若为接收到反馈就是出现了网络丢包的现象，系统会自动传输丢失的包，这就是丢包的自动重传机制，这样中间的间隔就会造成直播的延时。

　　解决方案

　　抛弃传统的基于TCP协议的方案，从底层协议和布网上开始，使用基于UDP协议的方案。SD-RTN(Software-Defined Real Time Net work)，软件定义实时传输网络，是一种新型的专为内容实时传输而设计，基于UDP协议的网络架构。SD-RTN通过在互联网上不同地区的数据中心放置软件组网单元，相互连接互相调度，在现有的公共互联网基础上构建一层新的虚拟网络。能够实时根据各节点的连接、传输状况、负载状况、到用户的距离和响应时间，自动分配最优最通畅的传输路径，达到实时传输需要的质量保障级别。

　　CDN与SD-RTN对比情况如下：

　　基本原理不同。CDN是存储转发结构，设计目的是在各个边缘节点缓存待分发内容，结构上从源站到观众是伞状多级缓存放大方式。SD-RTN本质上一个实时传输网络，用户的数据在网络单元内部和传输线路上都以实时交换方式传送，UDP实现的传输协议，不会因为前一个包的丢失或延迟导致下后续包的延迟送达，而丢包可以用对延迟更友好的方式修复或补偿出来，从而能够保证最低延迟。

　　底层协议不同。SD-RTN采用了专为实时传输设计的UDP协议，避免了采用TCP的延时不可控缺点。能够大大缩短交互延时，延时可从CDN方案的数秒，降低到数百毫秒。

　　内容分发机制不同。SD-RTN是基于自定义路由，选择最优传输路径，直接将内容端到端传输，数据在网络单元中从不缓存，从而最大可能的降低延迟，同时内容安全性也更好。CDN是将内容缓存于缓存服务器中，再将内容就近下发，所以CDN更适合做内容分发，一对多的场景。

　　使用场景不同。SD-RTN适用于要求极低时延的实时互动场景，例如网络电话、视频会议、有主播与观众交互需求的互动直播等。CDN适用于对时延要求不高的场景，例如对延时要求不高、类似电视的单点直播、网站加速等。

　　SD-RTN的优势如下：

　　时延大大缩短。直播延时可从基于TCP的方案的数秒，降低到数百毫秒。这一延迟范围，属于实时通信或准实时通信延迟的范畴。在这一级别上，主播和观众可以基本重现在现场活动中的交互体验，从而大大释放了内容制作者的潜力，也为业务运营者创造新业务形式打开了无限的空间和可能。

　　抗丢包能力强。一般来说，SD-RTN中可以针对用户网络使用更多的策略模型和技术，这样在30%丢包时，依然能够进行正常直播。而基于TCP的直播方案在丢包2%时就明显卡顿，达到30%经常已断开连接，无法进行直播。

　　CDN难点：连麦

　　直播中，主播如果要与用户交互，常见有两种方式：

　　第一种方式：文字，这种比较常见，实现也比较简单，这里不再进行分析;

　　第二种方式：连麦，这样主播可以面对面与观众进行交互，增加了互动性;

　　由于连麦方式比较复杂，这里进行详细分析。

　　1. 多路RTMP流实现

　　前面提到，RTMP是目前主播中最常用的协议，使用RTMP协议，可以实现最简单的一种连麦方式，如下图。

　　当有连麦者时，则主播端和连麦者端，都分别推一路RTMP流到CDN，CDN再将这两路RTMP流发送给观众端，观众端将两路RTMP流合成为一个画面。这种方式的优点是实现简单，但缺点比较多：

　　主播与连麦者如果要进行交互，则考虑到上面分析的延时问题，在这里延时需要至少加大一倍，这样对于实时交互来说，完全无法接受;

　　主播与连麦者交互时，声音会产生干扰，形成回音;

　　观众端要接收两条视频流，带宽、流量消耗过大，并且两路视频流解码播放，耗费CPU等资源也非常多;

　　这样看来，这种方式弊大于利，基本不可取。

　　2. 主播端与连麦者P2P

　　第二种方式，是主播端与连麦者之间使用P2P方式进行交互，然后主播端将自己和连麦者的视频进行合并，再推到CDN上，CDN再发送给观众端，如下图：

　　这种方式的优点有两个，一是主播和连麦者之间使用P2P，网络质量较好，延迟较小，保证了两者之间交互不会有非常大的延时;二是可以解决声音的干扰问题，消除回声。缺点是：

　　P2P在某些网络下无法穿透，有些观众根本无法与主播端进行交互;

　　主播端需要上传两路视频：一路P2P与连麦者进行交互，一路使用RTMP推到CDN。还要下载一路视频：连麦者P2P发送过来的交互数据。所以主播端要求带宽需要较高，网络较差时无法进行主播;

　　主播端要进行多路视频的编码、解码，要求主播端设备配置比较高，较差的设备也无法进行主播;

　　只能支持一个连麦者，不能支持多个连麦者;

　　由于主播端和连麦者经过CDN合并成一路，因此，不能实现主播端和连麦者视频大小窗口切换。

　　综合来说，P2P方式在一定程度上可以解决连麦的问题。

　　3. 服务器端合图

　　另外一种方式，是主播和连麦者都将视频推送到CDN中，然后CDN内部对这几路视频进行合图，再将其发送给观众端。如下图：

　　这种方式的优缺点如下：

　　优点

　　主播和连麦者各路视频都使用RTMP推送到CDN，可以保证延时较小;

　　由于CDN进行视频合图和发送，所以主播不需要很高的带宽;

　　由于CDN进行视频合图，所以主播的设备不需要配置非常高;

　　没有声音干扰问题;

　　可以支持多个连麦者连麦;

　　缺点

　　CDN需要进行视频的合图，需要额外开发工作，并且逻辑比较复杂;

　　CDN需要进行视频的合图，需要消耗较高服务器资源;

　　CDN合图后的布局难控制;

　　据目前所知，还没有CDN支持这种方案;

　　解决方案

　　使用前文中提到的SD-RTN方案，由于其延迟较低，主播和观众可以通过音频实时交互，而不会感到延迟过大而不自然。使用SD-RTN，可以很好的解决多路RTMP、P2P连麦、服务器端合图这几种方案的弱势，并且开发难度降低，合图布局等都可以很好的在客户端上进行控制。

　　客户端均通过UDP连接SD-RTN架构服务，通过SD-RTN的就近接入策略，让使用者就近接入质量最好的数据节点，经过传输延迟和质量优化的最优路径，自动避免网络拥塞和骨干网络故障的影响，将数据发送给其他客户端。若有常规的长延迟旁路直播，则可以将主播与连麦者合成一路直播流，通过RTMP推到CDN，进行下发。连接这一路的观众，不能参与连麦互动，达到了最佳直播效果。