WebRTC入门与提高-WebRTC原理(STUN/TURN/SDP)_ZNDS问答

lwhcs

1 WebRTC入门

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

从官网上的描述我们可以知道，WebRTC是一台免费的开放项目，它通过简单的API为浏览器和移动应用程序提供实时通信（RTC）功能。

上图的框架对于不同的开发人员关注点不同：
（1）紫色部分是Web应用开发者API层
（2）蓝色实线部分是面向浏览器厂商的API层
（3）蓝色虚线部分浏览器厂商可以自定义实现

特别是图中的 PeerConnection 为 Web 开发人员提供了一台抽象，从复杂的内部结构中抽象出来。我们只需要关注PeerConnection这个对象即可以开发音视频通话应用内。

1000道程序员常见问题解析是最近新整理的一台专栏，欢迎大家提供问题与思路。
所有问题、思路、答案将整理在公众号，大家可以扫码关注一下，相互交流学习。

关注即可免费领取一份2020技术学习提升大礼包！（含文档、电子书、视频、go激活码等等）

WebRTC架构组件介绍

Your Web App
Web开发者开发的程序，Web开发者可以基于集成WebRTC的浏览器提供的web API开发基于视频、音频的实时通信应用。

Web API
面向第三方开发者的WebRTC标准API（Javascript），使开发者能够容易地开发出类似于网络视频聊天的web应用，最新的标准化进程可以查看这里。

WebRTC Native C++ API
本地C++ API层，使浏览器厂商容易实现WebRTC标准的Web API，抽象地对数字信号过程进行处理。

Transport / Session
传输/会话层
会话层组件采用了libjingle库的部分组件实现，无须使用xmpp/jingle协议

VoiceEngine
音频引擎是包含一系列音频多媒体处理的框架。
PS：VoiceEngine是WebRTC极具价值的技术之一，是Google收购GIPS公司后开源的。在VoIP上，技术业界领先。

Opus：支持从6 kbit/s到510 kbit/s的恒定和可变比特率编码，帧大小从2.5 ms到60 ms，各种采样率从8 kHz（4 kHz带宽）到48 kHz（20 kHz带宽，可复制人类听觉系统的整个听力范围）。由IETF RFC 6176定义。

NetEQ模块是Webrtc语音引擎中的核心模块，一种动态抖动缓冲和错误隐藏算法，用于隐藏网络抖动和数据包丢失的负面影响。保持尽可能低的延迟，同时保持最高的语音质量。

VideoEngine
WebRTC视频处理引擎
VideoEngine是包含一系列视频处理的整体框架，从摄像头采集视频到视频信息网络传输再到视频显示整个完整过程的解决方案。

VP8 视频图像编解码器，是WebRTC视频引擎的默认的编解码器
VP8适合实时通信应用场景，因为它主要是针对低延时而设计的编解码器。

1.3 WebRTC发展前景
WebRTC虽然冠以“web”之名，但并不受限于传统互联网应用或浏览器的终端运行环境。实际上无论终端运行环境是浏览器、桌面应用、移动设备（Android或iOS）或是IoT设备，只要IP链接可到达且符合WebRTC规范就可以互通。这一点释放了大量智能终端（或运行在智能终端上的app）的实时通信能力，打开了许多对于实时交互性要求较高的应用场景的想象空间，譬如在线教育、视频会议、视频社交、远程协助、远程操控等等都是其合适的应用领域。

全球领先的技术研究和咨询公司Technavio最近发布了题为“全球网络实时通讯（WebRTC）市场，2017-2021”的报告。报告显示，2017-2021年期间，全球网络实时通信（WebRTC）市场将以34.37％的年均复合增长率增长，增长十分迅速。增长主要来自北美、欧洲及亚太地区。

1.4 国内方案厂商
声网、即构科技、环信、融云等公司都在基于WebRTC二次开发自个的音视频通话方案。
声网 https://www.agora.io/cn/
即构科技 https://www.zego.im/

1.5 WebRTC通话原理
首先思考的问题：两个不同网络环境的（具备摄像头/麦克风多媒体设备的）浏览器，要实现点对点的实时音视频对话，难点在哪里？

1. 媒体协商
彼此要了解对方支持的媒体格式

比如：Peer-A端可支持VP8、H264多种编码格式，而Peer-B端支持VP9、H264，要保证二端都正确的编解码，最简单的办法就是取它们的交集H264

注：有一台专门的协议，称为Session Description Protocol (SDP)，可用于描述上述这类信息，在WebRTC中，参与视频通讯的双方必须先交换SDP信息，这样双方才能知根知底，而交换SDP的过程，也称为&#34;媒体协商&#34;。

2. 网络协商
彼此要了解对方的网络情况，这样才有可能找到一条相互通讯的链路
先说结论：(1)获取外网IP地址映射；（2）通过信令服务器（signal server）交换&#34;网络信息&#34;
理想的网络情况是每个浏览器的电脑都是私有公网IP，可以直接进行点对点链接。

实际情况是：我们的电脑和电脑之前或大或小都是在某个局域网中，需要NAT（Network Address Translation，网络地址转换），显示情况如下图：

在解决WebRTC使用过程中的上述问题的时候，我们需要用到STUN和TURN。
STUN
STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议，它允许位于NAT（或多重NAT）后的客户端找出自个的公网地址，查出自个位于哪种类型的NAT之后以及NAT为某一台本地端口所绑定的Internet端端口。这些信息被用来在两个同时处于NAT路由器之后的主机之间创建UDP通信。该协议由RFC 5389定义。
在遇到上述情况的时候，我们可以建立一台STUN服务器，这个服务器做什么用的呢？主要是给无法在公网环境下的视频通话设备分配公网IP用的。这样两台电脑就可以在公网IP中进行通话。

使用一句话说明STUN做的事情就是：告诉我你的公网IP地址+端口是指什么。搭建STUN服务器很简单，媒体流传输是按照P2P的方式。
那么问题来了，STUN并不是每次都能成功的为需要NAT的通话设备分配IP地址的，P2P在传输媒体流时，使用的本地带宽，在多人视频通话的过程中，通话质量的好坏往往需要根据使用者本地的带宽确定。那么如何办？TURN可以很好的解决这个问题。
TURN
TURN的全称为Traversal Using Relays around NAT，是STUN/RFC5389的一台拓展，主要添加了Relay功能。如果终端在NAT之后，那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公网的服务器作为一台中继，对来往的数据进行转发。这个转发的协议就被定义为TURN。
在上图的基础上，再架设几台TURN服务器：

在STUN分配公网IP失败后，可以通过TURN服务器请求公网IP地址作为中继地址。这种方式的带宽由服务器端承担，在多人视频聊天的时候，本地带宽压力较小，并且，根据Google的说明，TURN协议可以使用在所有的环境中。（单向数据200kbps 一对一通话）
以上是WebRTC中经常用到的2个协议，STUN和TURN服务器我们使用coturn开源项目来搭建。
补充：ICE跟STUN和TURN不一样，ICE不是一种协议，而是一台框架（Framework），它整合了STUN和TURN。coturn开源项目集成了STUN和TURN的功能。
在WebRTC中用来描述网络信息的术语叫candidate。
媒体协商 sdp
网络协商 candidate

3. 媒体协商+网络协商数据的交换通道
从上面1/2点我们知道了2个客户端协商媒体信息和网络信息，那如何去交换？是不是需要一台中间商去做交换？所以我们需要一台信令服务器（Signal server）转发彼此的媒体信息和网络信息。

如上图，我们在基于WebRTC API开发应用（APP）时，可以将彼此的APP链接到信令服务器（Signal Server，一般搭建在公网，或者两端都可以访问到的局域网），借助信令服务器，就可以实现上面提到的SDP媒体信息及Candidate网络信息交换。
信令服务器不只是交互媒体信息sdp和网络信息candidate，比如：
（1）房间管理
（2）人员进出房间

WebRTC APIs
MediaStream — MediaStream用来表示一台媒体数据流（通过getUserMedia接口获取），允许你访问输入设备，如麦克风和 Web摄像机,该 API 允许从其中任意一台获取媒体流。
RTCPeerConnection — RTCPeerConnection 对象允许用户在两个浏览器之间直接通讯，你可以通过网络将捕获的音频和视频流实时发送到另一台 WebRTC 端点。使用这些 Api，你可以在本地机器和远程对等点之间创建链接。它提供了链接到远程对等点、维护和监视链接以及在不再需要链接时关闭链接的方法。

4. 一对一通话

在一对一通话场景中，每个 Peer均创建有一台 PeerConnection 对象，由一方主动发 Offer SDP，另一方则应答 AnswerSDP，最后双方交换 ICE Candidate 从而完成通话链路的建立。但是在中国的网络环境中，据一些统计数据显示，至少1半的网络是无法直接穿透打通，这种情况下只能借助TURN服务器中转。

5. NAT知识补充
具体NAT打洞的知识在本课程不做进一步的讲解，这里提供些链接给大家做参考：
P2P技术详解(一)：NAT详解——详细原理、P2P简介 https://www.cnblogs.com/mlgjb/p/8243646.htm
P2P技术详解(二)：P2P中的NAT穿越(打洞)方案详解 https://www.jianshu.com/p/9bfbcbee0abb
P2P技术详解(三)：P2P技术之STUN、TURN、ICE详解 https://www.jianshu.com/p/258e7d8be2ba
详解P2P技术中的NAT穿透原理 https://www.jianshu.com/p/f71707892eb2

STUN不会为终端分配公网ip，只是帮组终端找到自己在公网网关对应的ip和端口

写的不错

从应用角度看，简单说，就是双方交换 offer 和 candidate，然后就能互通视频了。

对带宽的解释有点迷惑，因为relay并不能减少对带宽的需求。因为相同的数据量被发送到peer（STUN）或者是relay（TURN）。本地带宽是一个什么样的概念？

多人视频通话是不是不能使用这样的流程, 因为按你来说只是点对点通信?

		自动登录	找回密码
密码			立即注册

WebRTC入门与提高-WebRTC原理(STUN/TURN/SDP)

相关问题更多>

最新回答