什么是 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（即时通讯）音讯零碎架构 – 架构篇