一夜之间，“小程序+直播”成为多媒体开发者热议的话题。从底层技术实现到接口开放程度，是否绑定腾讯云？价格体系？低延迟性能如何？......一连串的问题背后是开发者乃至整个生态对“小程序+直播”的关注。
最看好的应用场景是直播、在线教育和视频会议，最关心的性能是延迟。
关于小程序的RTC能力，是通过WebRTC实现的，还是基于RTMP呢？
小程序的RTC能力是基于RTMP技术实现的，没有使用WebRTC是出于两方面的考虑：一是安装包的体积必须控制在可接受的范围内。另一个考虑就是RTMP协议的适用场景更多，除了实时视频通话场景之外，还可以做标准直播解决方案。比如培训、教育等。
小程序里面用的是UDP + RTMP方式来实现RTC的，而且还对协议内容加密了？那是不是意味着小程序RTC必须走腾讯云？
首先，对于直播场景下音视频通道的加密是很刚需的一个要求，所以小程序在RTC模式下如果走腾讯云，会默认开启加密能力以避免窃听。
当然，小程序如果实现RTC不需要绑定腾讯云，关于这一点大家可以做个试验：简单用 nginx-rtmp 搭建一个后台服务器，然后创建两对RTMP url，按照文档 的指引放在小程序里测试，可以体验一下效果，只要网络不是特别差，延迟和效果应该是很不错的。
腾讯云真正做的出色的是，让全国不同地方的两路RTMP，都能达到很好的效果，这是腾讯云多年来一直积累CDN节点，优化内部链路调度（GBN网络）的结果。
如果是RTMP + UDP，无法实现ARQ、FEC传输算法，是这样吧？
RTMP本身是可靠的传输层协议，所以不需要实现ARQ和FEC算法，ARQ和FEC都是为了解决传输层协议不可靠（比如私有UDP协议）而不得不采用的办法。
早期实时音视频通话面对的网络条件要比现在恶劣的多，也就是常说的窄带时代。在那个时代的网络条件下，由于带宽成本极高，所以实时音视频通话都需要采用 UDP 协议来打洞实现 peer to peer 直连，这就意味着我们只能选择 UDP 协议，因为 TCP 打洞做NAT穿越不是那么容易。而 UDP 协议如果做成可靠的协议（也就是不丢包），就丧失了它的灵活性，因为音视频通话本身对于部分数据的丢失是可以容忍的，所以适当的允许一些丢包是更加符合窄带传输的需求。当然，我们不希望频繁的丢数据，不然通话质量就上不来了，所以 ARQ 和 FEC 这种丢包恢复技术就应用而生了。