视频通话和直播技术webRTC和RTMP探究

因为公司的app中有关于音视频通话的业务，跟作这一块的朋友探讨了关于webRTC和RTMP这两种技术的应用

首先，webRTC是由一家叫GIPS 的瑞典公司开发，2011年被google收购并开源，它刚开始设计的初衷是用于web端音视频通话，降低音视频通话的门槛，现在已经广泛应用于很多app中，它本质上是p2p，RTMP是Adobe公司出品的，目前国内的直播类型的app大部分用的RTMP来实现的。

webRTC相对于RTMP它的优势在于延迟低，用户体验好，它的延迟在100-200ms，而RTMP的延迟在3s左右，所以音视频通话中选用webRTC这种方式比较合适，因为你不能说两个人通话每次都要等对方说完3s再听到，这样太不方便了，在视频直播中，因为是只有一个人在说话，其余的都是观众，用RTMP的话，相当于观众每次听到的话都是主播3s之前说的，但是因为信号是连续的，所以在观众观看直播的过程中对3s的延迟是无感的，那写到这里大家可能会有疑问了，既然webRTC延迟这么低，为什么做直播的时候不用webRTC来实现呢？

好问题，为了解答这一问题我们就不得不来说一下webRTC和RTMP的实现原理，这两者的实现方式是不同的，我们先来看webRTC,我们以微信的视频通话场景为例进行说明，在微信视频通话中，我们点击视频通话按钮，向对方发送视频通话请求时，我们手机中的webRTC框架会向微信的服务器发送消息，腾讯接收到消息后会为发送者手机IP分配一个通话链路a，同时给接受者推送一条消息通知，接受者看到 通话请求后点击同意按钮之后，微信的服务器会给接收者的IP分配通话链路b，a链路和b链路会有一个交汇点，这样a和b就接通了，就实现了ptop的消息机制。

RTMP的实现原理是这样，主播在视频直播时，直播的音频和视频信息会以FLV这种视频格式存储，flv文件会分割成若干个片段，RTMP会把这些flv格式的文件上传到服务器，观众从服务器上请求这些flv文件，这样实现了音视频消息的传输，因为只有主播上传音视频消息，观众不上传，主播端的音视频文件上传到服务器之后，不管有多少观众，只要网速没有问题，他们都可以从服务器拉取音视频文件，所以RTMP这种方式，可以容纳的观众数就非常多，几百万，几千万都可以，但是webRTC是ptop的方式，每一对ptop，都需要服务器分配链路，占用的资源就非常多，所以webRTC支持同时视频通话的用户数就是受限制的，所以直播不建议选用webRTC的方式。