帮助与文档
热搜关键词:直播系统短视频源码一对一
在直播平台开发过程中,为何不使用TCP协议?
发布来源:云豹科技    发布人:云豹科技    Date:2020-03-10 09:57:53

直播平台开发过程中,常用的流媒体协议有RTMP、HLS、WebRTC等,但是却很少看到TCP协议。其实目前已有的直播业务,包括图片传输、文件传输、点播服务等都是在TCP通信基础上实现的。所以有些开发者在建立流媒体时,的确考虑过TCP,但是由于种种原因,不得不放弃这一方案。那么具体原因是什么呢?

直播平台开发

由于直播业务大多建立在短延时直播上,所以为了好说明问题,将短延时定义为“延时800毫秒以内”。通常,一次直播的延迟会来自于推流端延迟、CDN产生的延迟和播放端产生的延迟这三个方面,从经验角度来看,播放端的延迟会比较严重,主要是两方面,一方面是开播时候卡前一个关键帧所带来的延迟,另一方面如果CDN服务器到播放端有抖动,累积的延迟会越来越多。

我们来看一下TCP,当网络抖动出现丢包的时候,TCP是ACK确认机制的,也就是发送方发送一包之后,一定要等过对方回应,才会继续发包。若网络一旦出现丢包,就会在一个RTO之后重传,RTO的值和RTT有关,并且RTO的最小值是200ms。如果想保证流畅性,直播平台的播放端一定要至少能容忍200ms以上的抖动,但播放端的jit.buffer太多又无法满足低延时的要求。

直播平台开发

这里再对比一下WebRTC中使用中的NACK机制,NACK的丢包反馈更加及时。如果网络是偶然性抖动居多的时候, NACK机制效果更加好。某项统计显示,在全网平均RTT小于15ms、且CDN节点覆盖足够好的情况下,延迟理论上会很低。以1.5Mbps码率的音视频流举例,每秒钟100个包,包和包之间就是10ms的间隔。如果当第二个丢包出现的时候,第三个包对方接收到了,就可以马上知道第二个包是丢掉了,就可以立刻返回一个NACK,进行重传。在这种极限情况下,重传间隔就是25ms,相比之前TCP的200ms是一个质的提升,想满足绝大部分播放延迟在800ms以内才有可能。

另外,若使用TCP的话,无效传输没法避免。TCP是采用socket buffer进行通信,数据也是从应用层先进入socket buffer再分发。对于RTMP或FLV的分发来说,假如某一帧的数据的一部分已经进入了socket缓冲区,那么也必须将这一帧剩余的数据发送出去, 如果剩余的数据不发出去的话, 播放端会出现解析错误, 断开连接, 体验会很差。

以上就是在直播平台开发过程中,为何不使用TCP协议的原因。如果您对直播平台开发、直播系统开发感兴趣,欢迎咨询官方客服。

 本文章声明原创,转载请注明出自云豹科技www.yunbaokj.com

本文标签: 直播平台开发
相关阅读