2011年Google发起了WebTRC开源项目和标准化工作，WebRTC已经成为未来最有希望的统一互联网即时音视频服务的技术标准。WebRTC将帮助更多的人更简单的搭建实时音视频通信功能。

01-WebRTC历史

2010年5月，Google以6820万美元收购VoIP软件开发商Global IP Solutions的GIPS引擎，并改为名为“WebRTC”。

WebRTC使用GIPS引擎，著名聊天工具skype所使用的就是这款GIPS引擎。WebRTC实现了基于网页的视频会议，并支持722，PCM，ILBC，ISAC等编码，同时使用谷歌自家的VP8视频解码器；同时支持RTP/SRTP传输等。在最新的特性中，WebRTC同时还支持跨操作系统，浏览器和设备（包括台式机和手机）运行的HTML5代码。所谓手机浏览器不能调用手机摄像头的历史即将成为过去时。

02-我们需要先说一说Web应用的访问模式

Web应用的数据传输通过HTTP（超文本传输协议）在浏览器之间和Web服务器之间传输数据。有些HTTP协议运行在TCP（传输控制协议）上层，在某些新的网络是实现中，HTTP运行在WebSocket协议之上。在网络上使用的是HTML，CSS，JavaScript来承载内容和应用。采用请求——响应模式来进行选择操作。这叫做Web浏览模式。

03-我们再说一说浏览器中的实时通信功能

实时通信技术这种技术的独特性质，决定了在在浏览器当中增加该功能绝对不是一个简单的事情。实现标准化过程也是难上加难。Web浏览模式的基础上，WebRTC提供了一个信令服务器。可以理解为通信网络中的控制器。提供信令通道。但是信令在WebRTC中现在并没有标准化。

信令不同于用户信息，用户信息是直接通过通信网络由发信者传输到收信者，而信令通常需要在通信网络的不同环节(基站、移动台和移动控制交换中心等)之间传输，各环节进行分析处理并通过交互作用而形成一系列的操作和控制，其作用是保证用户信息的有效且可靠的传输，因此，信令可看作是整个通信网络的控制系统，其性能在很大程度上决定了一个通信网络为用户提供服务的能力和质量。

WebRTC还提供了一个浏览器与浏览器交互的特性，WebRTC把这种交互方式定义为“对等连接”。

若大家觉得看文章不过瘾，可以来拿音视频开发视频教程，给大家整理了一个几十小时的视频教程合集（内含：FFmpeg、RTSP、RTMP、SRS流媒体服务器、编解码、推拉流、音视频通话等项目实战教程），还有配套课件资料给大家哦。

对等连接在WebRTC中指的是在浏览器和浏览器，浏览器和其他设备通信设备之间的交互方式。这些设备之间的教诲方式可以使用非HTTP协议进行通信，例如：UDP协议等。

04-WebRTC中的媒体流

现在设备可以使用和产生很多种流。举个例子：

手机上的浏览器：

麦克风音频流

应用程序共享视频流

前置摄像头视频流

后置摄像头视频流

笔记本上的浏览器：

网络摄像头视频流

立体声音频流

WebRTC内置了对这些多媒体流和多数据来源的处理功能。都支持，你能想一想以后直播只需要一个手机和手机浏览器的场景么？

05-WebRTC中的多方会话

实时音视频有两种会话方式，一种是点对点的，就是2个设备之间进行交流。就像2个人视频聊天这种场景的。另外一种是多方会话，就像视频会议这样的场景。WebRTC针对这多方会话提供了两种实现方式。

第一种实现方式：实现多个浏览器之间的对等连接——全网状模型

多个浏览器通过Web服务器访问网站，浏览器之间的通话并不通过任何流媒体服务器，而是直接通过对等连接，通过UDP来实现浏览器之间的通信。这个叫做全网状模型。

第二种实现方式：浏览器和媒体服务器建立对等连接——集中式模型

服务端除了Web服务器之外还需要架构一个台媒体服务器，媒体服务器和各个浏览器之间实现对点连接。架设媒体服务器的目的在于接收各个浏览器的媒体流六，之后通过媒体服务器把媒体流发给各个浏览器。

两种实现方式的利弊：

全网状：不需要架设媒体服务器，媒体延迟低质量高。但是如果人数很多的话就会导致浏览器的本地宽带增加，不适合多人会议。

集中式：比较适合多人会话，节省本地宽带，但是只有少量浏览器查询的时候，这种体系的效率非常低（因为要走媒体服务器）。