直播技术简介直播技术的方向从产品上分类 : 传统直播 : 直播购物、娱乐直播、游戏直播实时互动直播 : 音视频会议

从产品上分类 :

实时互动直播和传统直播的最大的不同点就是: 能否实现多人的实施音视频互动

不同的技术路线

两种技术对比

商用直播技术解决方案需要把上述两种直播技术进行融合:

真实场景是: 既需要多人的实时互动有需要大量的媒体分发.

在实时互动直播中, 包含边缘节点和自建网络两部分, 不同地区的客户端要加入互动, 首先要连接离自己最近的边缘节点, 然后通过核心网络与另一端进行互联, 如果有直播需求, 那么还需要对音频流和视频流进行合并, 通过RTMP协议推送到CDN网络, 观众从CDN网络拉流即可观看.

视频数据经过编码后发送出去, UDP包最大1500字节, 除去包头还剩1300+ - 1400+字节数, 也就是需要由很多个UDP包把一帧数据从一端传输到另一端.

其中REMB技术已经被淘汰了, 目前TCC是主流.

通过对比可以得出实时互动直播的难度大于传统直播的结论.

为什么会有TCP /UDP 之争?

在优质网络状况下是不存在这个问题的, 只有在极端网络下, 会出现丢包、乱序的情况, TCP会出现延迟比较大的情况, 而实时互动直播对延迟的容忍度最大是500毫秒, 这一指标就直接把TCP剔除出去了.

以下通过TCP的ack机制来分析为什么TCP的延迟大

客户端向服务端发送数据后需要服务端回一个ack消息以证明收到了客户端的发送数据, 然后客户端在继续发下一个数据包, 基本原理就是每一个包都需要服务端进行确认.

当客户端向服务端发送的包丢失或者服务端返回的ack丢失, 在客户端等待超时后都认为是丢包了, 就会重新发包重传.

上图为TCP重连超时的退避机制: 为了避免重传导致网络拥塞和抖动, 每次重传后超时时长都会增加.

在极端网络情况下, 频繁丢包在以上TCP的机制下就会导致延迟大大增加.