WebRTC简介（一）

WebRTC（Web Real-Time Communication）也被称为网络实时通信，是由 Google、Mozilla 和其他公司推动的一个开源项目，它通过 Javascript API 实现无插件的实时通信，以及在不需要中介的情况下在浏览器之间交换任意数据。

WebRTC的优点：

WebRTC技术的诞生，有一个很重要的原因在于，在浏览器实现实时音视频通话，需要依赖相关插件或程序，而插件安全漏洞问题则更为关键。浏览器开发人员无法控制这些插件以及更新，因此插件带来的安全风险也相对较大。

在WebRTC诞生之前，开发实时音视频应用的成本是非常高，需要考虑的技术问题很多，如音视频的编解码，数据传输延时、丢包、网络抖动、回音处理和消除等，如果要兼容浏览器端的实时音视频通信，还需要额外安装插件。当然，可以考虑使用第三方成熟技术，比如当时世界顶级的互联网音视频方案GIPS(Global IP Solutions)，支付相应的费用就行。很多知名的应用或者软件服务商也都在用GIPS，如Yahoo，AOL，IBM，SKYPE，QQ等。

WebRTC项目的愿景：实时通信web化，让WebRTC成为互联网音视频实时通信的规范，让开发者基于此规范快速开发出安全、可靠的应用。未来的音视频实时通信，必定是现代化生产活动中极其重要的板块。以下是WebRTC的部分应用场景：

两个不同网络环境的（具备摄像头/麦克风多媒体设备的）客户端（浏览器或APP），要实现点对点的实时音视频对话，难点在哪里？

要实现P2P通信，首先需要了解彼此是否都支持相同的媒体能力，WebRTC默认使用V8编解码器，如果要连接的对方不支持V8解码，如果没有媒体协商过程。那么即使连接成功，把视频数据发给对方，对方也无法播放
比如：Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264
有一个专门的协议 ，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为"媒体协商"。

交换数据会通过一个中间服务来完成，在这里，我们称之为信令服务器
在建立P2P连接时，需要交换的信息有：

最理想的场景

然而，在大多数情况下，两个对等端都是各自处于某个局域网之中，相互之间隔着NAT与防火墙

NAT(Network Address Translation)即为网路地址转换协议

局域网-->公网

公网-->局域网

可以借助STUN服务器，穿越NAT

在NAT四种主要类型中有三种是可以使用STUN穿透：完全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT。但大型公司网络中经常采用的对称型 NAT（又称为双向NAT）则不能使用STUN穿透，这类路由器会透过 NAT 布署所谓的「Symmetric NAT」限制。也就是说，路由器只会接受之前连线过的节点所建立的连线。

可以点对点连接的情况与需要中转的情况（数据来源于Google）

不过在国内大部分局域网无法穿越。

内网穿透从字面上来说就是将本地的服务器映射到外网可访问

设想下

    如果有已知的公网服务器，那内网的本地服务就可以映射到外网了。

    如果没有已知的公网服务器，那只能代理到外网的服务器访问即可。

    ps: 公网服务器与可访问外网的服务器是有区别的。区别在于用户访问某宝服务，先是到公网服务器然后再转发的淘宝服务。所以可访问外网的服务器不等于公网服务器。

换句话说直接将服务器部署在与公网服务器相通的机器上不就可以了，我也是这样想的。所以就有生产环境与测试环境，其实内网穿透还是存在安全隐患的，内网穿透大部分应用于测试环境，比如常用的微信相关开发。

最后我们来聊聊FRP与NGROK

        两者的原理都一样，通过解析过的域名做本地服务端口映射。

        Ngrok相对比较简单，只需要能访问外网的机器即可。可参考 >