为什么直播系统不用 RTP 协议

本文转自“雨夜随笔”公众号，欢迎关注



在 直播技术的背后--RTMP协议 文章中，我们讨论了目前主流的直播系统，大部分都会采用RTMP作为推流甚至于拉流的技术。但是当我们去了解目前的音视频通话时，会发现他们背后的技术是一种叫做RTP（Real-time Transport Protocol）的技术。而我们日常使用微信或者钉钉等进行音视频通话时，会发现延迟很低，基本在1s内。而RTMP协议，就是优化到极限，才能保证延迟在1s内，而且还是权衡之后舍弃了其他的功能。



那么我们可能会想：为什么我们不能直接使用RTP协议来实现我们的直播系统呢？就像知乎上这位同学的提问：





可靠性

首先我们看一下目前主流的音视频传输协议在网络结构中的位置：



协议图



我们可以看到目前主流的RTMP和HLS都是采用TCP作为传输协议的基础，TCP的优点就是可靠，缺点当然也很明显，就是需要三次握手。而UDP的优点是简单，不需要建立连接，缺点就是不可靠。



所以基于UDP之上的拓展协议RTP同样不保证可靠性，不保证服务的QoS（服务质量）。这个在官方定义中就声明过。那么如果想要保证RTP的可靠性，就需要RTP的伴生协议--RTCP（Real-time Transport Control Protocol），即实时传输控制协议，负责控制RTP协议的内容。RTCP定期在参加者之间传输控制数据，RTCP的主要功能是为保证RTP的QoS。



image.png



所以如果我们想要单单依靠RTP协议来实现直播系统，并不能保证直播系统的可靠性。



注：这里我们将RTP定义为传输层（L4）协议，在网上很多地方会将RTP作为L5,L6甚至L7的网络协议。但是单单就RTP本身，更像是UDP的一个拓展协议，所以我们依旧把它当作传输层协议。



兼容性



当然了解直播内容的同学会问：目前WebRTC为RTP协议提供了很好的应用层支持，使得基于WebRTC的音视频通话系统的可靠性和实时性都得到了保证。为什么我们不能使用WebRTC作为直播技术的选型？



一方面基于RTMP和HLS的直播技术的支持更为成熟，大部分推流工具或者客户端都支持RTMP协议，而拉流可以通过HTTP-FLV的方式进行拉流，浏览器老的可以采用flash的方式来播放直播流，新的可以通过flv.js等新型工具进行拉流。而移动端或者苹果等其他第三方系统都有成熟的RTMP或者HTTP方式的拉流SDK。可以说基于RTMP等技术的生态已经非常成熟了。



而WebRTC的兼容性如下：





所以WebRTC并不能保证所有终端和浏览器都能正常使用，这点也是很多平台没有采用RTP以及基于它的WebRTC技术作为直播技术的选型。



未来

但是WebRTC的延迟性低对于直播领域是一个很大的吸引力，虽然兼容性现在还有待完善，但是各个平台正在逐步完善，并且越来越多的人开始关注WebRTC，并提供了各种各样的解决方案。虽然这些方案都不尽完善，但是我很相信在未来WebRTC肯定能得到更为长足的发展。



WebRTC具有很大的兼容性问题，直接使用会出现下面几个问题：

1. WebRTC 使用的是点对点传输，虽然节约了服务器资源的开销，但实际使用时也带来了传输质量的问题，比如跨国以及跨运营商网络之间的传输质量往往很难保证，在错综复杂的网络条件下，表现也很难让人满意。并且如何处理多人拉流和混流也是一个极具挑战的问题，目前还没有很好的开源解决方案。

2. WebRTC 在移动端的表现也很差。由于早期缺少对于 H.264 编解码器的支持，导致移动端的解码效率很低，在中低端手机根本无法正常支持。

3. 浏览器的兼容性导致直接用WebRTC进行商用变得不可能。



但是目前很多基于WebRTC的二次研发让我们看到了WebRTC用于直播的未来，比如淘宝直播就采用WebRTC作为直播的技术选项，如下：





可以看出淘宝在WebRTC的技术上做了深层定制开发，但是这些对于中小型公司或者非专业领域的公司来说，想基于WebRTC来做直播系统是一件挑战性非常大的工作。



总结

目前RTP或者基于上面的WebRTC直接使用作为直播技术的挑战性非常高，还缺乏成熟的开源工具和生态。但是RTP的低延迟特性使得很多大厂正在进行二次开发。所以RTP不是不可以作为直播平台的技术选项，只是目前缺乏很好的支持，需要自己进行定制开发的部分较多。并且还需要考虑WebRTC目前的兼容性问题。所以对于想要实现直播系统的同学，目前不推荐直接使用RTP或者WebRTC作为技术选型。



欢迎关注