在直播平台开发过程中，为何不使用TCP协议？

在直播平台开发过程中，常用的流媒体协议有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