什么是 WebRTC ？

WebRTC（Web Real-Time Communication）是 Google于2010以6829万美元从 Global IP Solutions 公司购买，并于2011年将其开源，旨在建设一个互联网浏览器间的实时通信的平台，让 WebRTC技术成为 H5规范之一。咱们看官网（https://webrtc.org）的介绍

其中：

  • Web Real-Time Communications (WEBRTC) W3C 组织：定义浏览器 API。
  • Real-Time Communication in Web-browsers (RTCWEB) IETF 规范组织：定义其所需的协定，数据，安全性等伎俩。

简略来说，WebRTC 是一个能够在 Web 应用程序中实现音频，视频和数据的实时通信的开源我的项目。在实时通信中，音视频的采集和解决是一个很简单的过程。比方音视频流的编解码、降噪和回声打消等，然而在 WebRTC 中，这所有都交由浏览器的底层封装来实现。咱们能够间接拿到优化后的媒体流，而后将其输入到本地屏幕和扬声器，或者转发给其对等端。

点对点音视频的难点

抛开低提早、流畅性、回声打消和海量并发这些难点不讲，单纯从性能来看，买通通信单方的两端，让彼此能失常视频及通话，次要存在两个问题：

（1）网络买通问题--无公网IP无奈间接通信

当今互联网到处存在着一些中间件(MIddleBoxes)，如NAT和防火墙，导致两个(不在同一内网)中的客户端无奈间接通信。这些问题即使是到了IPV6时代也会存在，因为即便不须要NAT，但还有其余中间件如防火墙阻挡了链接的建设。

当今部署的中间件大多都是在C/S架构上设计的，其中绝对隐匿的客户机被动向周知的服务端(领有动态IP地址和DNS名称)发动链接申请。大多数中间件实现了一种非对称的通信模型，即内网中的主机能够初始化对外的链接，而外网的主机却不能初始化对内网的链接，除非通过中间件管理员非凡配置。在中间件为常见的NAPT的状况下，内网中的客户端没有独自的公网IP地址，而是通过NAPT转换，和其余同一内网用户共享一个公网IP。这种内网主机暗藏在中间件后的不可拜访性对于一些客户端软件如浏览器来说并不是一个问题，因为其只须要初始化对外的链接，从某方面来看反而还对隐衷爱护有益处。然而在P2P利用中，内网主机（客户端）须要对另外的终端（Peer）间接建设链接，然而发起者和响应者可能在不同的中间件前面，两者都没有公网IP地址。而内部对NAT公网IP和端口被动的链接或数据都会因内网未申请被抛弃掉。对于WebRTC来说，首先要解决的是如果逾越NAT实现内网主机间接通信的问题。

（2）媒体格式编码问题--媒体格式编码多样不对立

对于须要音视频通信的单方，彼此要理解对方反对的媒体格式能力失常地对流媒体编解码。比方，Peer­A端可反对VP8、H264多种编码格局，而Peer­B端反对VP9、H264，要保障二端都正确的编解码，最简略的方法就是取它们的交加H264。有一个专门的协定称为SDP（Session Description Protoco），可用于形容上述这类信息，在WebRTC中，参加视频通信的单方必须先替换SDP信息，这样单方能力知根知底，而替换SDP的过程，也称为“媒体协商”

SDP(Session Description Protocol) 是一种会话形容协定，基于文本，其自身并不属于传输协定，须要依赖其它的传输协定（比方 SIP 和 HTTP）来替换必要的媒体信息，用于两个会话实体之间的媒体协商。SDP(会话形容协定)定义了一个规范，用于定义两个（通常）端与端之间媒体（通常是流媒体）替换的参数。IETF已将其公布为RFC 4566。SDP通常嵌入或封装在另一个协定中，最宽泛应用的应用程序位于大多数IP电话应用程序的SIP协定外部。简略地说，SDP协定是媒体端到端对其接管标准和能力的申明；典型的申明会通知咱们：

（1）哪个IP地址筹备好接管传入的媒体流

（2）哪个端口号正在侦听传入的媒体流

（3）端点心愿接管的媒体类型（通常是音频）

（4）端点心愿在哪个协定中替换信息（通常为RTP）

（5）端点可能解码的压缩编码（编解码器）

在一个典型的会话设置过程中，咱们会看到两个端点参加一个会话，其中每个端点发送一个SDP以告诉另一个端点其标准和性能。SDP自身不提供任何媒体，但仅限于协商一组兼容的媒体替换参数；媒体流自身由不同的通道和协定解决。

一个 SDP 的握手由一个 offer 和一个 answer 组成

WebRTC通话原理

点对点的单方为了实现实时音视频通信， WebRTC须要解决媒体协商和网络协商问题，这里要引入信令服务器(Signaling Server)和STUN server

Signaling Server

须要通信的单方之间建设WebRTC连贯须要一个信令服务器来实现单方通过网络进行连贯。信令服务器的作用是作为一个中间人帮忙单方在尽可能少的裸露隐衷的状况下建设连贯。WebRTC并没有提供信令传递机制，信令的传递和替换须要服务器参加，这个角色就是信令服务器。WebRTC信令指建设、管制和终止通信会话的过程以及业务自身的需要来看，须要替换几个信息：媒体信息，网络信息，具体业务。

  • 一、媒体信息

须要媒体数据来确定呼叫者和被呼叫者共有的编解码器和媒体类型。如果尝试启动通信会话的端具备不同的分辨率和编解码器配置，则会话不太可能胜利。通过应用会话形容协定（SDP）格局的提供和应答在对等方之间替换媒体配置信息的信令，这些信息是通过SDP协定形容进去，通过信令服务器直达的。

  • 二、网络信息

两个WebRTC客户端如何发现对方的？通过信令服务器交互单方在Internet上的地位（IP地址和端口），以便呼叫者能够找到被呼叫者。

  • 三、具体业务

会话管制信息确定何时初始化、敞开和批改通信会话，比方退出房间，来到房间，禁言，媒体流订阅公布等性能，须要信令服务器来管制。

STUN server

STUN（Session Traversal Utilities for NAT，NAT会话穿梭应用程序）是一种网络协议，它容许位于NAT（或多重NAT）后的客户端找出本人的公网地址，查出本人位于哪种类型的NAT之后以及NAT为某一个本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间建设UDP通信。该协定由RFC 5389定义。STUN 是 C/S 模式的协定，能够简略了解为：由客户端发送 STUN 申请；STUN 服务响应，告知由 NAT 调配给主机的 IP 地址和端口号。一旦领有了ip和端口，点对点通信的单方就能直连通信了。（注：以上的响应同时还使得STUN客户端可能确定正在应用的NAT类型——因为不同的NAT类型解决传入的UDP分组的形式是不同的。四种次要类型中有三种是能够应用的：齐全圆锥型NAT、受限圆锥型NAT和端口受限圆锥型NAT——但大型公司网络中常常采纳的对称型NAT（又称为双向NAT）则不能应用，这时TURN就要退场了，本文暂且不讲）

专有名词介绍

Signaling Server ：信令服务器，负责解决通信单方的信息交互，包含媒体信息，网络信息，业务信息。

STUN server：STUN的全称是Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs)， 即穿梭NAT的简略UDP传输，是一个轻量级的协定。能够简略了解为：由客户端发送 STUN 申请；STUN 服务响应，告知由 NAT 调配给主机的 IP 地址和端口号。

SDP：Session Description Protocol 为了连贯到对端用户，咱们必须要对其余用户的设施状况有所理解，比方音频视频的编码解码器、应用何种编码格局、应用何种网络、设施的数据处理能力，，而 SDP 为咱们提供了这些性能

ICE：Interactive Connectivity Establishment 通信的两侧可能会处于不同的网络环境中，有时会存在好几层的访问控制、防火墙、路由跳转，所以咱们须要一种办法在简单的网络环境中找到对方，并且连贯到相应的指标。WebRTC 应用了集成了 STUN、TURN 的 ICE 来进行单方的数据通信。

offer、answer：一个 SDP 的握手由一个 offer 和一个 answer 组成，一方发送offer，另一方接管到offer后，发送answer。

WebRTC音视频通信流程

在同一房间的单方通过WebRTC建设音视频通信，次要分为四个阶段：

（一）退出房间、呼叫对方，对方应答

（1）ClientA登录后连贯信令服务器，抉择进入某个房间；

（1）ClientB登录后连贯信令服务器，抉择进入某个房间；（1）（2）不分先后

（3）ClientA 在此房间中看到ClientB在线，抉择呼叫ClientB；

（4）ClientB抉择批准接听； （3）（4）中的ClientA和ClientB能够调换；

（二）替换SDP，发送/接管offer，发送/接管answer

（1）ClientA 执行getUserMedia() ->new RTCPeerConnection->Peer.addStream->createOffer

（2）ClientB 执行getUserMedia() ->new RTCPeerConnection->Peer.addStream；（1）（2）并行执行；

（3）ClientA通过信令服务器直达offer给ClientB；

（4）ClientB收到offer后，setRemoteDescription->createAnswer；并通过信令服务器直达answer给ClientA；

（5）ClientA收到answer后，setRemoteDescription；

（三）替换ICE candidate

（1）ClientA 向STUN Server申请ICE（申请可能在之前某个时候曾经收回），STUN Server返回ICE candidate

（2）ClientB 向STUN Server申请ICE（申请可能在之前某个时候曾经收回），STUN Server返回ICE candidate

（3）ClientA通过信令服务器直达ICE candidate达到ClientB；ClientB通过信令服务器直达ICE candidate达到ClientA；

（4）ClientA收到B的ICE canditate，addIceCandidate

（5）ClientB收到A的ICE canditate，addIceCandidate

（四）开始音视频通信

（1）ClientA addStream 展现对方近程音视频流；

（2）ClientA addStream 展现对方近程音视频流；

对于IM即时通讯，更多原创技术文章：

开源OpenIM：轻量、高效、实时、牢靠、低成本的音讯模型

开源OpenIM：高性能、可伸缩、易扩大的即时通讯架构

基于Tablestore Timeline的IM（即时通讯）音讯零碎架构 - 架构篇