WebRTC标准旨在使网络上的点对点通信像拿起电话一样简单。以下是开发人员需要了解的关于WebRTC的内容，包括如何设置它以及该协议目前面临的限制。
每个人都有这样的经历:尝试参加Web会议，却发现必须先下载一些插件、升级Java或Flash，或者安装另一个应用程序。如果您曾经不得不向客户解释她如何或为什么需要下载并安装插件或应用程序来与您在线见面，您可能也有过这样的经历:您知道吗?我会给你打电话的。”
网络上的实时音频和视频流以及实时会议正在改变着商业和个人通信，但对于许多终端用户来说，它们往往被认为过于复杂或不可靠。当然，创建一个实时通信(RTC)应用程序对于一般的Web开发人员来说太复杂了。
多亏了网络实时通信(WebRTC)，一种直接在Web应用程序中构建对等通信的行业标准。
如今，实时通信主要意味着“打电话给我”
在WebRTC出现之前，实时通信需要一个插件或本地应用程序。这需要用户下载、安装、升级、启动、配置或解决无数问题，才能从“我需要做这个”变成“我已经做了”。
目前，你可以使用多种应用程序进行实时通信，包括Skype、Facetime、谷歌Talk、Yahoo Messenger、iChat、GotoMeeting和join.me。这还不包括你办公桌上的VOIP电话，也不包括你智能手机和平板电脑上的所有RTC应用。毫无疑问，在你的电脑上还有一些其他的RTC应用程序，你只下载并使用过一次，或者当你访问各种商业网站并使用它们的实时聊天功能时，它们是以Flash或Java应用程序的形式下载的。
总之，实时通信是当今所有在Web上，无论是名副其实。
你可以使用一些RTC客户端与其他使用不同RTC程序的人通信;例如，iChat可以与Yahoo Messenger对话。不过，在大多数情况下，这些程序都被设计为或仅在其他运行相同软件或插件的计算机上运行得最好。
普通老式电话服务（POTS），而另一方面，是熟悉的，普遍和简单。这也难怪有这么多的人和企业仍然无法完全转储可怕的音质和模拟电话的费用和电话服务在铜线。您需要一个电话时，电话的音频部分不起作用打电话到Web会议。您还可能有几乎总是连接到Wi-Fi无线智能网络但你仍然支付除了高速互联网和电话服务的无线计划。
WebRTC提供了与浏览器无关的解决方案
对比这目前的状况有什么是可能与WebRTC技术的愿景。任何人只要有一个Web浏览器和麦克风可以与Web浏览器和麦克风别人通话。如果一方或双方有某种摄像机，通话也可以包括视频。
此外，的JavaScript API参与启用此对等网络通信是很简单的，你可以创建JavaScript和HTML的只是五六线WebRTC客户端。参与对话的浏览器基本上代为办理你的一切。
如果您对VOIP和视频连接有任何经验，您就会知道VOIP通常涉及代理和防火墙问题，以及需要所有相关方同意的编解码器和信令协议。WebRTC的想法是HTTP和Web已经解决了如何从一个点到另一个点获取数据的问题，而这些问题很少。网络可以正常工作。
如果你有一个的WebRTC的浏览器（例如，Chrome和Firefox安装）在您的计算机上，您可以使用该浏览器与任何其他WebRTC客户端进行通信。
如果别人有WebRTC技术的Web浏览器的支持，无论是台式计算机，智能手机或上未来的超级真棒手表通信设备-你可以与那个人实时交谈，就像你拿起中央电话公司提供的20世纪60年代壁挂式旋转电话的听筒一样容易和无麻烦。
如何的WebRTC作品：建立连接，创建流
在2010年,谷歌收购Global IP Solutions (GIPS)该公司开发了编解码器和实时语音视频软件。2011年，谷歌发布了Hangouts，它使用了GIPS的技术开放GIPS技术的源代码在的WebRTC的形式。（在撰写本文时，视频群聊依然采用了插件，但谣言（和逻辑），有一名的WebRTC版本的作品。）的WebRTC 1.0目前是W3C工作草案。虽然工作草案已在多个浏览器中实现已经，该规范仍然非常通量。
在建立对等体之间的语音和视频连接的第一步是获得对麦克风和相机在每个设备上。直到最近，这wasnt与Web浏览器真的有可能。W3C开发了一个名为简单的API媒体捕获API这在浏览器厂商中获得了一些支持，最近部分应用到了移动Safari中。
但是，Media Capture不提供流式视频或音频的任何方法。这就是MediaStream API出现的原因。
MediaStream API的任务是请求用户访问摄像机和麦克风的权限，然后创建同步的视频和音频流。它使用一个名为getUserMedia()的JavaScript方法来实现这一点。
创建流并使用HTML5视频标签显示它的基本代码如下。它被取走了，并稍加修改。从Mozilla.org getUserMedia文档。
<脚本>导航器。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在对等点之间传输流数据。与MediaStream一样，RTCPeerConnection使用一个非常简单的接口。它接收一个媒体流并将其发送给另一个接收方，然后将其加载到接收方的RTCPeerConnection中。这就是所有。
然而，在内部，RTCPeerConnection必须处理以下任务:
- 信号处理(包括回波消除和降噪)
- 编解码器的选择
- 对等网络通信
- 加密
- 带宽管理
不过，在对等点之间开始流传输之前，必须发生一个称为信令的进程。信号通常是事情变得棘手的地方。WebRTC没有重新发明轮子，而是将信号留给应用程序。开发人员可以自由选择任何双向通信协议，无论是SIP、XMPP、WebSocket还是JSON数据。
信令是的WebRTC系统，确实需要服务器来绕过防火墙的一部分，网络地址解读(NAT)。通常，发起点对点连接所需要的只是发送方的公共IP地址。WebRTC使用会话遍历实用工具（STUN）服务器告诉防火墙后面的WebRTC应用程序它的公共IP地址。然后，WebRTC应用程序可以继续与另一个应用程序建立对等连接。
如果由于某种原因，建立点对点连接失败，WebRTC可以通过使用调用的技术通过服务器建立连接遍历使用继电器绕行NAT（TURN）。显然，不需要任何服务器资源的连接(STUN)比通过中继服务器路由数据(TURN)更便宜、更高效。因此，只要有可能，您都希望使用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);{pc.setRemoteDescription(desc);} function gotRemoteStream(e) {attachedMediaStream(remoteVideo, e);} < /script >
在2013年谷歌I / O，谷歌漫不经心地展示了一个完整的视频聊天客户端，它只用了大约50行JavaScript。
对于数据在对等网络连接交换，的WebRTC包括RTCDataChannels API。这使用了RTCPeerConnection的功能，因此用户可以交换任何类型的数据，而不必担心防火墙、代理、大小限制、第三方应用程序和其他自计算开始就困扰着向他人传输文件这一看似简单的任务的头疼问题。
RTCDataChannel使用相同的API尚。在RTCPeerConnection上启用双向、低延迟数据连接只需要一个简单的send方法和OnMessage事件处理程序。可能的应用包括游戏，屏幕共享，甚至安全的大文件共享。
RTCDataChannel还可以以可靠或不可靠的模式交付数据。如果您只需要具有最低延迟的数据，并且偶尔丢失数据包也是可以的，那么不可靠模式就是最好的选择。如果数据必须正确(例如在文件传输中)，则使用可靠模式。ShareFest是一个开放源码的一对多共享应用程序，它使用RTCDataConnection来允许在不通过服务器的情况下共享最多1gb的文件。
WebRTC也有惊人的潜力和局限性
有了WebRTC，就有可能解决Web通信中最大的障碍:使点对点的语音和视频(以及数据共享)像今天通过Web在表单中输入消息一样简单。
除了视频会议之外，WebRTC的潜在应用包括:
- 这提高可读性网站基于读者的头走了多远。
- 客户支持将视频、音频和桌面共享无缝集成。
- 游戏
- 照片亭或音频录制应用程序，不需要第二个端点。
WebRTC在谷歌Chrome、Android Chrome和最新测试版Firefox中都是默认支持和启用的。它可以在Internet Explorer中使用浏览器内嵌框架，该插件支持Internet Explorer中的开放Web技术。虽然移动Safari还不支持WebRTC，爱立信实验室的鲍泽浏览器目前制造的WebRTC可能在iOS和Android。
当然，这是Web，并没有什么是容易死人。微软和苹果都在自己的RTC解决方案的大量投资。微软提出了异议谷歌的VP8编解码器，并没有增加，以实现WebRTC支持IE浏览器。苹果上的WebRTC不知道位置，但它的猜测，苹果认为的WebRTC为FaceTime的威胁;其结果是，苹果可能不是太大急着来实现它。
接下来的问题是如何在对等网络中实现电话会议。超过5个用户的组对WebRTC来说是真正的问题，因为从每个对等点更新和路由数据的复杂性。只是因为涉及到的数学，它很快就会变得势不可挡，因为涉及到的各方数量在增长，达到一个顺序n的阶乘。
用于使得能够在较大的群体对等网络通信的更实用的结构包括星形体系结构，其中，一个对等体作为呼叫的焦点和发送和接收的所有其它对等体，或一个被称为多点控制单元（MCU）服务器，其中每个中继对等端之间的所有数据。
安全性，同时，内置的WebRTC以严肃的方式。首先，所有的摄像头和麦克风的访问是明确的选择项。也就是说，浏览器会询问用户每个会话的应用程序是否可以访问摄像头和麦克风，用户必须点击确定。接着，对等体之间共享的所有数据使用加密AES加密。最后，因为的WebRTC不使用任何插件，它运行在浏览器沙箱中，并具有仅向用户的计算机相同的访问权限的任何Web应用程序一样。
WebRTC现在是如何使用的