WebRTC标准旨在使Web上的点对点通信像拿起电话一样简单。以下是开发人员需要了解的关于WebRTC的内容，包括如何设置它以及该协议目前面临的限制。
每个人都有尝试参加Web会议的经历，结果发现必须首先下载一些插件、升级Java或Flash或安装另一个应用程序。如果你曾经不得不向客户解释她如何或为什么需要下载和安装插件或应用程序以便在线与你见面，你可能也有过这样的经历:“你知道吗?我会给你打电话的。”
[也:复古浏览器之战:IE vs网景］
网络上的实时音频、视频流和实时会议正在改变着商业和个人通信，但它们往往被认为对许多终端用户来说太复杂或不可靠。当然，对于一般的Web开发人员来说，创建实时通信(RTC)应用程序肯定过于复杂。
多亏了网络实时通讯(Web Real-Time Communications)，这一切都在改变。WebRTC)，这是将对等通信直接构建到Web应用程序中的行业标准。
如今，实时通讯大多意味着“打电话给我”
在WebRTC出现之前，实时通信需要插件或原生应用。这就要求用户下载、安装、升级、启动、配置或解决各种问题，让自己从“我需要做这个”变成“我已经做了”。
您目前可以使用几个应用程序进行实时通信，包括Skype, Facetime，谷歌Talk, Yahoo Messenger, iChat, GotoMeeting和join.me。这还不包括你办公桌上的VOIP电话或智能手机和平板电脑上的RTC应用程序。毫无疑问，在你的电脑上还有其他一些RTC应用程序，你只下载过一次，或者是在你访问各种商业网站并使用它们的实时聊天功能时以Flash或Java应用程序的形式下载的。
简而言之，实时通信在今天的网络上无处不在，无论是字面上的还是比喻上的。
你可以使用一些RTC客户端与使用不同RTC程序的其他人进行通信;例如，iChat与雅虎信使对话。不过，在大多数情况下，这些程序的设计都是为了最好地运行，或者只与运行相同软件或插件的其他电脑一起运行。
另一方面，普通的老式电话服务(POTS)是熟悉的、通用的和简单的。难怪如此多的人和企业仍然无法完全摆脱模拟电话和铜线电话服务可怕的音质和费用。当通话的音频部分不能工作时，你需要用这款手机进行网络会议。你也可能拥有一台几乎总是连上Wi-Fi网络的智能手机，但你仍然要为高速互联网和电话服务之外的无线计划付费。
WebRTC提供与浏览器无关的解决方案
将目前的事态与WebRTC可能实现的愿景进行对比。任何一个有网络浏览器和麦克风的人都可以打电话给任何一个有网络浏览器和麦克风的人。如果一方或双方都有某种摄像机，通话也可能涉及视频。
此外，支持这种点对点通信的JavaScript api非常简单，只需5到6行JavaScript和HTML就可以创建一个WebRTC客户机。对话中涉及的浏览器基本上代表您处理所有事情。
如果您有VOIP和视频连接的经验，那么您应该知道，VOIP通常涉及代理和防火墙问题，以及编解码器和信令协议，这些都需要相关各方的同意。WebRTC的想法是，HTTP和Web已经解决了如何从一个点到另一个点的数据问题，而这些问题很少。网络只是工作而已。
如果你有一个支持webrtc的浏览器(例如，Chrome和Firefox)，您可以使用该浏览器与任何其他WebRTC客户端通信。
如果别人有一个支持WebRTC的Web浏览器，不管是在台式电脑上，智能手机上还是超级棒的手表通信设备的未来你可以轻松自如地与那个人实时交谈，就像拿起中央电话公司提供的20世纪60年代壁挂式旋转式电话的听筒一样。
WebRTC如何工作:建立连接，创建流
在2010年,谷歌收购全球IP解决方案(GIPS)该公司开发了编解码器以及实时语音和视频软件。2011年，谷歌发布了《Hangouts》，它使用了GIPS的技术开源的GIPS技术以WebRTC的形式。(在撰写本文时，Hangouts仍然使用插件，但传言(和逻辑)说WebRTC版本正在开发中。)WebRTC 1.0目前是W3C的工作草案。虽然工作草案已经在一些浏览器中实现了，但规范仍在不断变化。
在对等点之间建立语音和视频连接的第一步是访问每个设备上的麦克风和摄像头。直到最近，这对于Web浏览器来说都是不可能的。W3C开发了一个简单的API媒体捕捉API它已经获得了浏览器制造商的一些支持，最近被部分嵌入Mobile Safari中。
指南:HTML5的8大优势
然而，Media Capture不提供流媒体视频或音频的任何方法。这就是MediaStream API出现的原因。
MediaStream API的工作是请求用户允许访问摄像机和麦克风，然后创建同步的视频和音频流。它通过一个名为getUserMedia()的JavaScript方法来实现这一点。
创建流并使用HTML5视频标记显示它的基本代码如下。它被拿走了，并稍微修改了一下。从Mozilla.org getUserMedia文档．
< script >导航器。getMedia = (navigator. getMedia)getUserMedia | |导航器。webkitGetUserMedia | |导航器。mozGetUserMedia | | navigator.msGetUserMedia);导航器。getMedia (// constraints {video: true, audio: true}， // successCallback function(localMediaStream) {var video = document.getElementsByTagName('video')[0];视频。src = window.URL.createObjectURL (localMediaStream);视频。onloadedmetadata = function(e) { // Do something with the video here. }; }, // errorCallback function(err) { console.log("The following error occurred: " + err); } ); < /script > < video autoplay >< /video >
建立联系的方法不止一种
媒体流创建后，WebRTC使用RTCPeerConnection API在对等点之间通信流数据。RTCPeerConnection，像MediaStream一样，使用一个非常简单的接口。它接收一个媒体流并将其发送到另一个接收者，在那里它被加载到RTCPeerConnection在他们的一端。就是这样。
然而，在幕后，RTCPeerConnection必须处理以下任务:
- 信号处理(包括回声消除和降噪)
- 编解码器的选择
- 点对点通信
- 加密
- 带宽管理
但是，在对等点之间开始流媒体之前，必须进行一个称为信令的过程。信号通常是事情变得棘手的地方。WebRTC没有重新发明轮子，而是将信号发送留给应用程序。开发者可以自由选择任何双向通信协议，无论是SIP、XMPP、WebSocket还是JSON数据。
信令是WebRTC系统的一部分，它需要服务器绕过防火墙网络地址转换(NAT)。通常，发起点对点连接所需要的只是发送方的公共IP地址。WebRTC使用用于NAT的会话遍历工具(STUN)服务器告诉防火墙后面的WebRTC应用程序它的公共IP地址。然后，WebRTC应用程序可以继续与另一个应用程序建立对等连接。
如果由于某种原因，建立点对点连接失败，WebRTC可以通过服务器使用一种称为在NAT (TURN)周围使用中继遍历．显然，与通过中继服务器(TURN)路由数据相比，不需要任何服务器资源(STUN)的连接成本更低，效率更高。因此，只要可能，您都希望使用STUN建立连接。
确保你的电话总是尽可能低成本的工作落在了一种协议上互联互通建立(ICE)．在大多数情况下——根据谷歌的数据，86%的情况下——你只用STUN就可以进行视频通话。这样就大大节省了服务器资源，而实时视频系统总是需要服务器。
下面是一个简单的RTCPeerConnection的例子:
< script > pc = new RTCPeerConnection(null);电脑。onaddstream = gotRemoteStream;pc.addStream (localStream);pc.createOffer (gotOffer);函数gotOffer(desc) {pc.setLocalDescription(desc);sendOffer (desc);}函数gotAnswer(desc) {pc.setRemoteDescription(desc);}函数gotRemoteStream(e) {attachhedmediastream (remoteVideo, e.stream);} < /script
在2013年谷歌I / O，谷歌若无其事地展示了一个完整的视频聊天客户端，它只用了大约50行JavaScript编写。
对于点对点连接上的数据交换，WebRTC包括一个RTCDataChannels API．这使用了RTCPeerConnection的功能，因此用户可以交换任何类型的数据，而不必担心防火墙，代理，大小限制，第三方应用程序和其他头痛的问题，这似乎困扰着一个简单的任务传输文件给另一个人，从计算开始。
rtcdatacchannel使用相同的API尚．一个简单的send方法和OnMessage事件处理程序是通过RTCPeerConnection启用双向、低延迟数据连接所需的全部内容。可能的应用包括游戏、屏幕共享，甚至安全的大文件共享。
rtcdatachchannel还可以以可靠或不可靠的模式传递数据。如果您只需要具有最低可能延迟的数据，并且偶尔漏掉一个数据包是可以接受的，那么不可靠模式就是正确的选择。如果数据必须是正确的(例如，在文件传输中)，则使用可靠模式。ShareFestRTCDataConnection是一个开源的一对多共享应用程序，它使用RTCDataConnection来允许在不经过服务器的情况下共享大约1gb的文件。
WebRTC也有惊人的潜力和局限性
有了WebRTC，就有可能解决Web通信中的最大障碍:使点对点语音和视频(就此而言，还有数据共享)像今天通过Web将消息输入表单一样简单。
WebRTC在视频会议之外的潜在应用包括:
- 网站提高可读性的基础上，读者的头是多远。
- 无缝集成视频、音频和桌面共享的客户支持电话。
- 游戏
- 不需要第二个终端的照相亭或音频录制应用程序。
在谷歌Chrome、Chrome for Android和Firefox的最新测试版中，默认支持并启用WebRTC。它可以在Internet Explorer中使用铬框架，一个插件，可以在Internet Explorer中打开Web技术。虽然移动Safari还不支持WebRTC，爱立信实验室的加油车目前，iOS和Android上的浏览器可以实现WebRTC。
当然，这是在网络上，没有什么是绝对容易的。微软和苹果都在他们自己的RTC解决方案上投入了大量资金。微软已经对谷歌的VP8编解码器提出了反对意见，并没有在ie浏览器中增加对WebRTC的支持。苹果在WebRTC上的立场尚不清楚，但据推测，苹果将WebRTC视为FaceTime的威胁;因此，苹果可能不会急于实现它。
然后是如何在点对点网络中实现电话会议的问题。由于从每个对等点更新和路由数据的复杂性，超过5个用户的组给WebRTC带来了真正的问题。仅仅因为其中涉及到的数学，它很快就会随着参与者数量的增长而变得势如强敌，达到一个顺序n的阶乘．
更实际的架构支持点对点通信在较大的群体包括明星架构,在一个对等充当的焦点打电话发送和接收所有其他同行,或服务器称为多点控制单元(MCU),继电器所有数据之间的同行。
与此同时，WebRTC以一种严肃的方式内置了安全性。首先，所有的摄像头和麦克风接入都是明确选择的。也就是说，浏览器将在每个会话中询问用户应用程序是否可以访问摄像头和麦克风，用户必须单击OK。接下来，对等点之间共享的所有数据都使用AES加密．最后，因为WebRTC不使用任何插件，所以它运行在浏览器沙箱中，对用户计算机的访问权限与任何Web应用程序相同。
WebRTC目前是如何使用的