2-4.实时互动直播的难点

那今天呢？我们来介绍一下实时互动直播的难点

那第一个难点是实施性的要求高。那我们可以看一下实时通讯的，它的延迟指标儿，这张表儿呢，就是实时通讯的延迟指标儿，在这张表格儿中呢，有几个档次？我们可以看一下啊，

首先是低于200毫秒，那整个实时通讯的这个质量呢，是非常优质的，就好像在同一个房间里，大家一起聊天一样。

那如果是300毫秒呢，大部分人都是非常满意的，400毫秒有一小部分人呢，就会感觉到有这个延迟现象了，但是呢，还不影响整个的这个互动性

那如果超过500毫秒。对于大部分人来说，都是不太满意的，会有明显的这个延迟，那这个就是实时的。这个延迟指标，那通过它，我们也可以知道啊，我们实时互动直播，对这个延迟它有多高的要求了。

相比较传统直播来说，那他们完全不在一个等量级上。传统直播它的延迟平均在三秒以上。而我们的实时互动直播是要求在500毫秒以下，那通过这个呢，我们就可以知道实时互动直播的难点。

那我们要达到这么低的一个延迟，我们在传输协议的选择上就要做仔细的斟酌，我们是应该选择TCP还是？还是应该使用UDP，那实际上啊，如果你的带宽足够宽的话，网络质量足够好，

那我无论选择TCP。还是UDP那都是可以很好的将数据传输出去的，但是如果在极端网络情况下，你的网络比较差，经常丢包。

这个抖动乱序，那在这个时候呢，我们还是应该选择UDP，那UDP它的这个传输协议保证的是我尽可能短的时间内给你送达。但它也有缺点，缺点就是不保证它的可靠性和有序性，

而TCP呢，恰恰与它相反，就是我要保证数据的可靠性和有序性，但是呢。我不保证它的实时性，这是两个协议的最大区别，所以我们要想有好的这个延时，低的延时，我们就应该选择UDP，而对于它的缺点不可靠啊，乱序啊，这一类问题呢，需要我们自己去实现。

OK，那这个时候呢，我们就有第二个难点了，那第二个难点呢，就是音视频的服务质量与实时性之间呢，是有矛盾的。对于我们的实时互动直播来说，我们既需要有非常低的延迟，又想要有非常好的服务质量。

因为对于用户来说，他不关心你底层。传输是怎么样的？它能够看到的就是我要能够听到更清晰的声音，能够看到更清楚的画面。这是它的要求，而对于我们开发者来说呢。

我们要想做好这个实时互动直播，那我们就要在低延迟。和音视频质量之间寻找一个平衡，那用户的带宽肯定是有限的，在它的带宽质量不能改变的情况下，我们要尽可能的。保证好的音视频的服务质量。

这才是我们真正要做的，那这里可能有很多同学啊，还不太理解音视频服务质量和实质性之间到底是产生了怎样的矛盾，那这里呢？我画了一张图。可能更好的帮助你理解它们之间的这个矛盾，

假如说我们在传输视频的时候，肯定在发送端要对视频呢进行编码，编码之后呢，再将它传输出去，但是对于视频来说，它的数据往往。是非常大的，即使我们编码之后，对于I帧也就是关键帧来说，可能还是有几兆的大小的这个尺寸，而我们在使用UDP进行传输数据的时候呢？

UDP包最多只能带1500字节，那除去IP头。这个utp头以及rtp头之外呢，我们真正能够带的数据可能就是1400多字节或者是1300多字节，也就是说我们需要用很多的小的utp包。将一个完整的关键帧从一端传到另一端，那如果在传输的过程中，由于TCP是不保证可靠性的。

所以有可能就会发生一些丢包儿，那传输的过程中，如果我们传输了20个包儿，其中有一个包儿丢失了，那我们在另一端。就无法将这些包儿呢再组合到一起，形成一个关键帧输送给解码儿器进行解码儿，那这样儿呢，就会造成一个丢帧的现象，

因为我不能将数据组成一个完整的帧了，那就需要把它全部丢掉，这个时候就会发生一个什么现象呢？就会发生花屏。所以我们在上层看到的用户儿，看到的可能就是说唉，为什么会出现花屏？为什么会出现卡顿？

那实际的原因呢？就是由于我们在底层的这个传输层啊。没有把这个数据啊，完完整整的输送过来，对中间儿发生了丢包儿，就无法找到了，才会有这个现象。

所以这个就是它们之间的矛盾，一旦我们出现了丢包儿，就会影响服务质量，那为了更好的实施性，我们还是要做一些取舍，对吧？不能一直等待。

说所有包都到了之后，我才进行解码，让它渲染出来，如果是那样的话，我们就失去了它的实质性，那比如说我们要等一分钟，那这个时长用户是不能等待的。所以他们之间就产生了一个矛盾，

那我们要解决这个矛盾，就要做很多很多的事情，所以这是也是一个特别大的一个难点好，除此之外呢？

还有第三个就是我们实时互动直播，是需要解决回音问题的，而传统直播呢，是不需要解决回音问题的，传统直播只是一个主讲人来讲。很多的观众在听。就OK了。

而实时互动直播是多个人都要说话，对吧？都要发送这个视频，相互之间还有这个你言我语，还要进行这个互动，那所以我们必须要将这个回音问题给它解决掉。

那回音问题呢，也是我们这个实时互动中的一个，非常难以解决的一个问题，那整个儿的过程呢，就如这张图所展示的，那这里呢，我就不做详细介绍了。

那总之我们要知道做实时互动直播，要远比传统直播难的多好，那下面呢，我们做一下对比。通过传统直播和实时互动直播，这个对比呢，

我们就知道实时互动直播它难在哪儿了。那首先呢，是时续性。对于传统直播呢，平均延迟三秒以上。而实时互动直播呢，是要求在500毫秒以内，那回音对于传统直播来说呢，是不需要处理回音的，不存在这个问题。

而互动直播呢，是需要解决回音消除的。带宽问题对于TCP来说，它本身底层就有这个带宽评估方法，那在评估带宽的时候呢？由于它对实时性要求不高，所以呢？它的实时性和准确率呢，都不是特别的理想，对相比较而言，不是特别理想。

而实时互动直播呢，尤其是webrtc。它采用了很多的方法，那么在带宽的准确性上以及它的实时性上做的是非常的好，虽然。不是完美，但是已经非常优秀了。

那最后一项呢？是丢包那对于TCP来说呢？我们也不用考虑丢包的问题。因为底层已经实现了，那当出现丢包儿的时候，它通过哪些机制将包儿找回来，从而达到一个这个可靠性。

而对于UDP来说呢，本身是没有。丢包儿处理的，那我们需要自己做自己做的方法呢，就是通过重传或者是fec，那这些呢，我们在后边儿都会向你做详细介绍。那通过这个表格儿啊，我们就可以知道这个实时互动直播，相较于传统直播来说。它的难度就不在一个等级上了。

对吧？要难很多，这是它们之间的一个对比，最后呢，我们再来看看TCP与UDP之争，那如果我们的带宽啊，是非常优质的。网络质量也非常好，就不存在这个TCP与UDP之争，因为我们无论使用TCP还是UDP，它的传输都是非常OK的。

只有在极端网络情况下，我们有丢包，有乱序的情况下，才会有TCP和UDP之争。在极端网络情况下，我们必须要选择UDP，而不能选择TCP。关键的原因就在于我们有实时性要求，我们的延时不能超过500毫秒，这个指标一确定之后，我们就可以将TCP剔除之外了。

那在我以前一家公司啊，实际对TCP和UDP啊就做过激烈的争论，当时主要的一个观点是，如果在UDP这上做数据的可靠性和有效性。那是不是做到极致之后就变成了TCP呢？实际完全不同的概念，这是第一点，

那第二点呢？我们来看看TCP它的丢包机制为什么使用TCP在极端网络环境下会出现延迟比较大的情况。那这里呢，我们就要看一下它的机制图了，那首先呢，我们看最左侧这个图，它是一个正常的客户端到服务器的TCP的传输机制。首先呢，客户端向服务端发送一个数据，服务端收到之后呢，给回一个ACK客户端，收到ACK之后呢，继续发下面的数据。

就这样，一个包儿，一个包儿的发送给服务端。当然，为了这个更高效呢，它会有一个滑动窗口儿，那这里呢？我就不做详细介绍了。那它的几个基本原理就是每一个包都要经过确认。那当出现丢包的时候，会出现两种情况，

第一种情况呢，是客户端发送给服务端的时候这个包。就丢失了这个时候呢，在客户端会启动一个定时器，如果在一定时间内没有收到服务端的ACK消息。那它会将这个包儿呢再重新发送一次，

同理，如果客户端发送给服务端的数据，包儿收到了，但是呢，在回ACK的时候，客户端没有收到这个ACK包儿。那也认为是一个丢包儿，所以也会走这个定时器的，这个逻辑当超时之后呢，再重新发一个包儿。进行重传啊，这是丢包重传的一个机制。

在发生丢包的时候呢，如果第一次丢包，它的这个超时时间是多少呢？在Linux系统下是200毫秒，也就是说在200毫秒之内我没有收到这个数据的话，我就会重传，但是它还有一个退币机制，也就是说为了防止由于重传包儿的大量产生，引起网络的拥塞或抖动。

所以呢，每次重传之后，它的一个定时器啊，就会加长那第一次呢是200毫秒，第二次呢是400毫秒，第三次呢是800毫秒，如果我们在极端网络情况下。经常发生丢包儿，而且每次发生的丢包儿呢，都是同一个包儿，其实这个包儿发送之后呢，丢了然后再重新发的时候呢，又丢了，对，这样就会造成什么呢？

就造成我们后边儿的所有的包儿。都会产生延迟，如果有几个包儿都出现这种情况，那这个延迟呢？就会非常大，那这就是TCP为什么会在极端网络的情况下？产生这个大量延时的这个根本原因，

那通过上面的讲解呢，我想你已经对我们在实时传输过程中使用UDP还是TCP？已经非常清楚了，也知道了为什么使用TCP会产生很大的延时，那下面呢？我们就来对我们本节呢做一下小结。

那通过前面的讲解呢，我想你已经知道了，实时互动直播需要自己实现传输的可靠性。因为我们选择UDP之后UDP本身是不能够支持可靠性和有序性的，所以必须我们自己来实现。

第二点实时互动直播需要实现回音消除。对于传统直播来说呢，它是不需要的。

第三点实时互动直播对实时性的要求是极其苛刻的。那它是不能超过500毫秒的。

最后是由于tcpp的重传，超时退避机制导致了不适合在极端网络情况下进行实时传输。

如有侵权，请联系我删除