WebRTC直播课堂实践：实时互动是核心

首先，我们一起来看上面这张图，这张图是由国际电信联盟电信标准化部门统计所得，图中的横轴坐标是毫秒，代表着时延，纵轴坐标是用户的体验度。由上图，我们不难发现，时延达到150毫秒的时候，用户的体验度开始下降，当达到400毫秒的时候，用户的感受是无法容忍。由此，ITU-T G.114国际标准规定，延时超过150毫秒表示已经开始影响用户体验，并且用户可以容忍的最高延时是400毫秒。

举个例子，当发生台风天气时，电视台的主持人通常会连线现场的记者，当连线返回现场报道时，基本是过了两秒左右的时间，现场记者才收到主持人的话，听众的体验感相当不好。类似于上面的情况基本上是无法实现实时互动的，想要进行实时互动的关键点就在于低延时。我以前也曾经做过八年直播相关的研发，从最初的底层协议到RTMP协议再到现在的WebRTC，用户需求为何会逐渐从点播域向直播域靠拢，直播流媒体实时音视频为何会越来越关注互动，也正是因为有了低延时，互动才得以慢慢发展出来。

不知道大家是否清楚，为什么流媒体在之前都没有发展起来这种很好的互动性呢？有很多人认为RTMP协议很不错，并且现在外面大部分采用的都是RTMP协议。

既然如此，为什么大家都去研究WebRTC呢？首先，RTMP是基于TCP协议的，TCP是一个安全可靠的协议，它包含了很多机制，如数据的安全保障、三次握手、重传机制等，但是这恰恰会影响到它的传输时间。

举个例子，我现在手上有一份数据要发送给另外一个人，发送过去之后由于网络抖动导致丢包。他没有收到包则会返回一个消息来告诉我他没收到我的包，这样就会产生很大的延迟。那么，能不能直接用UDP呢？三年前的广电系统，比如北京卫视等采用的是TS流，TS流就是基于UDP的，它的传输非常有效。TS传输具有高可靠度，流媒体安全且质量好，但是基于UDP都是基于内网的，对网络的要求非常高。北京卫视也只有内部的网络全部用的是TS流，采用UDP的协议来传送，一旦离开公司，就不可行了。因为UDP是不安全的，它没有重传机制，没有各种保障的能力。从上图中可以看出，UDP相对来说延时是最低的，但整体质量很低，对网络的依赖程度也非常高，所以我认为这是一个成本的问题。在这里推出一个概念，叫做RUDP（Reliable UDP）。RUDP指的是将TCP和UDP各种优势结合在一起，包含的功能有：

1）冗余编码和前向纠错；
2）场景化的重传策略；
3）带宽自适应调整；
4）更优的拥塞控制算法；
5）多点 relay…

简单解释一下什么叫做场景化的重传&#x