WebRTC （Web Real-Time Communication),一个可以让用户用自己流量实现音视频实时通信的框架（APIs),支持浏览器（Firefox、Chrome、Opera）以及iOS、Android 原生系统（Poor WP,默哀）。对于觉得带宽贼贵又需要实现用户之间音视频通信的公司来说，这是一个大大的福利。本系列文章会从WebRTC基本概念慢慢说起。
华坪网站建设公司创新互联,华坪网站设计制作，有大型网站制作公司丰富经验。已为华坪成百上千提供企业网站建设服务。企业网站搭建\外贸网站制作要多少钱，请找那个售后服务好的华坪做网站的公司定做！
官方介绍：
按照传统的通信流程，是这样的：
如下图所示，数据发送端和接收端都需要通过公网服务器进行转发（因为发送端和接收端通常都做了NAT，彼此并不知对方实际位置）。
e.g.：犹如一个中国人和一个外国人，他们彼此不懂对方的语言，不知道对方的地址，但是中间有一个邮局知道对方的地址，因为对方都在邮局做了注册地址并且获取了同一个编号，那么如果他们之间需要互相通信的话，就需要和邮局联系，邮局会进行翻译并发往同一编号的对应地址。 但是这中间就会产生一个问题，这时候如果有多个中国人和多个外国人都要进行通信，那么邮局的工作量就会越来越大，当他们的通信超过原有邮局人手可处理规模时，邮局要么扩招（需要钱）要么延缓发送（会造成延迟，甚至丢失信件）。
时间关系，以下内容不再举例说明，需要网络基础的同学才能继续观看。
在真实世界的网络中，因为IPv4的地址个数问题，我们基本都是采用NAT连接的：
STUN服务器提供的功能十分简单，它让使用者获取自己所在的公网地址和在NAT中所映射端口号，这个服务有什么用呢？当使用者知道自己所在公网地址以及内部NAT映射端口时，它便可以讲自己的公网地址和端口号通知对方，这样对方就可以在茫茫大网中找到自己。
在以往统计中，WebRTC通过STUN建立连接的成功率为86%。
TURN [2] 是一个client-server协议。TURN的NAT穿透方法与 STUN 类似，都是通过取得应用层中的公有地址达到NAT穿透。但实现TURN client的终端必须在通讯开始前与TURN server进行交互，并要求TURN server产生"relay port"，也就是relayed-transport-address。这时TURN server会建立peer，即远端端点（remote endpoints），开始进行中继（relay）的动作，TURN client利用relay port将资料传送至peer，再由peer转传到另一方的TURN client。
必须要安装的软件如下： SVN，这个是必须的。可以安装TortoiseSVN，找个合适的版本就可以了。【点击免费试用，0成本启动】
WebRTC实现了基于网页的视频会议，标准是WHATWG 协议，目的是通过浏览器提供简单的javascript就可以达到实时通讯（Real-Time Communications (RTC)）能力。
WebRTC（Web Real-Time Communication）项目的最终目的主要是让Web开发者能够基于浏览器（Chrome\FireFox\...）轻易快捷开发出丰富的实时多媒体应用，而无需下载安装任何插件，Web开发者也无需关注多媒体的数字信号处理过程，只需编写简单的Javascript程序即可实现，W3C等组织正在制定Javascript 标准API，目前是WebRTC 1.0版本，Draft状态；另外WebRTC还希望能够建立一个多互联网浏览器间健壮的实时通信的平台，形成开发者与浏览器厂商良好的生态环境。
想要了解更多关于这方面的相关信息，推荐咨询ZEGO即构科技。ZEGO即构科技是一家全球云通讯服务商，专注自研音视频引擎，服务覆盖全球，链接 5 亿终端用户。ZEGO即构科技覆盖212个国家/地区，全球用户体验毫秒级互动，日均通话时长达30亿分钟，跻身云通讯行业头部，全方位行业解决方案，满足百余个业务场景需要，服务客户4000家，70%泛娱乐/在线教育客户的选择。
目前基于WebRTC的开发其实有两个方向，
一个是基于浏览器的WebRTC应用开发，编程语言主要是JavaScript、HTML等，
这也是WebRTC作为HTML5标准的组成部分原本的目的；
另一个是C层面的移植和开发，作为一款非常强大的开源软件，
很多领域的软件项目都可以利用到WebRTC的音视频通信和处理能力，
这些场合的应用程序可能是C语言写的，也不一定与浏览器有关。
转自：网页链接
