从webrtc原理讲起，聊聊自助排障那些事

前言：

WebRTC作为实现前端互动和实时音视频的开源项目，已经被广泛应用与行业内的各个领域。本文以WebRTC实现实时通信的完整过程为线索，结合实际问题案例讲解下常见问的的排查思路，望读完本文可以了解WebRTC实现音视频通信的过程和一般腾讯云TRTC web端问题的排障思路。

什么是WebRTC：

1）名称和能力

WebRTC（Web Real-Time Communication）是“网页即时通信”的缩写，是一套支持通过浏览器进行实时视频语音对话的API。目的是通过点对点连接的形式，通过浏览器配合标准的H5标签与JS API，不借助中间媒介，通过网页就可以达到音视频的实时通讯（Real-Time Communications）能力。

传统web架构

和WebRTC的P2P架构

2）历史由来

WebRTC技术由VoIP软件开发商Global IP Solutions（以下简称GIPS）公司所研发，2010年，Google以约6820万美元收购了GIPS公司，并因此获得了该公司拥有的WebRTC技术。

Google希望Web开发人员能够直接在浏览器中创建视频或语音聊天应用，打造自己的音视频的开源生态，“浏览器 + WebRTC”就是Google给出的一个答案。遂于2011年6月1日，Google将WebRTC开源（https://webrtc.org/），希望将其打造为行业标准，在Google、Mozilla、Opera支持下被纳入万维网联盟的W3C推荐标准，被纳入了HTML5标准，主流浏览器全面支持WebRTC。这才有了今天的WebRTC，用户真正实现了基于浏览器，不需要安装插件，就可以实现音视频互动。

3）几个成功的重要理由

核心技术开源、免费，开发者不需要承担高昂的专利费用

提供了浏览器通信领域的高质量、完整的解决方案

作为音视频引擎，能力出众

下面就以WebRTC通信的过程为线索展开

STEP1:媒体采集：

媒体采集是完成一次音视频通话过程中的第一步，因此媒体采集API getUserMedia也是我们首先接触的WebRTC的API，顾名思义，该接口的作用就是“使浏览器与媒体设备（即麦克风和摄像头）进行交互”，进行媒体采集。

调用getUserMedia时，它会提示是否允许访问媒体设备。该提示仅在安全环境中可用，比如本地主机和在HTTPS下提供服务的站点。

请求资源

这里也是腾讯云TRTC中被经常问到的问题，想要体验 Demo 需要部署至服务器，通过 https://域名/xxx 访问，或者直接在本地搭建服务器，通过localhost:端口访问。

附：腾讯云TRTC一分钟跑通 Web 直播互动组件

https://cloud.tencent.com/document/product/647/47951#.E6.AD.A5.E9.AA.A44.EF.BC.9A.E8.BF.90.E8.A1.8C-demo.3Cspan-id.3D.22step4.22.3E.3C.2Fspan.3E

官方调用getUserMedia获取本地媒体流的基本语法为：

navigator.mediaDevices.getUserMedia(constraints)

在媒体采集步骤中，介绍两个概念， 第一个是MediaStream（媒体流），就是字面意思表示一个媒体数据流；介绍一个新概念： MediaStreamTrack（媒体轨道），MediaStreamTrack是媒体流轨道，表示单一类型的媒体，与某个特定输入源关联（在浏览器中表示一个媒体源），如音频轨道、视频轨道。在类似1V1视频的场景中，stream中就包含两个Track，一个音频Track和一个视频Track共同组成我们一次音视频通话的媒体流。

MediaStream通过addTrack()可以给流添加新轨道，也可以使用getVideoTrack()和getAudioTrack获取轨道。

腾讯云TRTC对外封装了createStream接口，

(static) createStream(streamConfig) → {Stream}

调用该接口会创建一个本地流Stream 对象，本地流 Stream 对象通过 publish() 方法发布本地音视频流。这部分，腾讯云TRTC也经常被问到一个问题，

一个音视频流 Stream 中最多只能包含一个音频 track 和一个视频 track。

STEP2:建立连接：

WebRTC的通信不经过服务器，采用P2P方式进行客户端连接，在提高通信效率也节约了服务端资源。一个典型的WebRTC建立连接的过程，包含四个步骤：相互发现，双方协商，建立连接，开始通信。

相互发现

当第一次发起视频聊天，首先你需要向自己所在的房间发出信号。这种告诉其他人你已经就位的方式称为信令。就比如如果你是第一个来到派对的人，理论上你仍会打声招呼，但没人会回应罢了。

从技术上讲，信令是ICE 框架（Interactive Connectivity Establishment）的一部分，是相互查找，然后通过交换媒体信息来协调通信的过程。信令使用会话描述协议（SDP）来收集网络信息，例如用于媒体交换的IP地址和端口号。

WebRTC 使用P2P通信，而P2P对等网络通信的第一步是互相发现。由于浏览器客户端之间所处的位置往往是相当复杂的，可能处于同一个内网段内，也可能处于公网中的两个不同的位置，所处的NAT网关也可能很复杂。因此需要一种机制找到一条传输质量最优的道路，而WebRTC正具备这种能力。

我们说WebRTC的RTCPeerConnection是可以做到浏览器间（无服务）的通信，两个浏览器不通过服务器建立点对点连接时，它们怎么知道彼此的存在呢？进一步讲，它们该怎么知道对方的网络连接位置（IP/端口等）呢？又是如何知道双方支持何种编解码器？甚至于什么时候开始媒体流传输、又该什么时候结束呢？因此在建立WebRTC的RTCPeerConnection前，必须建立️另一条通道来交这些协商信息，这条通道成为信令通道（Signaling Channel）。在正式的建立连接前还要交换信息，交换信息的过程，需要借助信令服务器（signaling server）来进行，交换过程中主要交换SDP会话描述协议和ICE candidate，那么什么是SDP？什么又是ICE candidate呢？下面来逐个讲讲这些是干什么的。

概念1：信令服务器（signaling server）

所谓信令服务器（signaling server），是一个帮助双方建立连接的「中间人」，WebRTC并没有规定信令服务器的标准，意味着开发者可以用任何技术来实现，如WebSocket或AJAX。

当运行腾讯云的demo过程中，打开浏览器的console，在打印的日志信息中可以看到建立连接的过程：

连接信令服务器

连接信令服务器

概念2：PeerConnection

发起WebRTC通信的两端被称为对等端（Peer），成功建立的连接被称为PeerConnection，一次WebRTC通信可包含多个PeerConnection。WebRTC使用RTCPeerConnection，实现peer跟peer之间的NAT穿透，继而无需服务器就能传输音视频数据流的连接通道。

用更通俗的语言阐述下RTCPeerConnection的概念，RTCPeerConnection可以理解为一个Websocket的连接通道，借助这个通道进而实现音视频数据互通的能力。RTCPeerConnection是WebRTC web层核心API，托管了复杂的数据传输延迟抖动、音视频编解码，音画同步等问题，使得开发者在开发过程中无需考虑这些复杂逻辑，可以专注于业务层的逻辑实现。直接使用PeerConnection 就能用上这些浏览器提供的底层封装好的能力，要完成一个RTCPeerConnection需要设置ICE Server（STUN服务器或TURN服务器），后面展开讲解。

概念3：SDP

SDP（Session Description Protocol）指会话描述协议，是一种通用的协议，使用范围不仅限于WebRTC。主要用来描述多媒体会话，用途包括会话声明、会话邀请、会话初始化等。

要在SDP中交换的信息包含以下内容：

1. 会话控制消息，用于打开或关闭通话；
2. 错误消息；
3. 网络数据，例如外界看到的主机IP地址和端口。
4. 媒体元数据，例如编解码器和编解码器设置，带宽和媒体类型；
5. 设备支持的媒体能力，包括编解码器等
6. ICE候选地址
7. 流媒体传输协议

这里以腾讯云TRTC在一次连接建立过程中交换的SDP为例：

sdp offer实例

v=代表协议版本号

o=代表会话发起者，包括username、sessionId等

s=代表session名称，为唯一字段

c=代表连接信息，包括网络类型、地址类型、地址等

t=代表会话时间，包括开始/结束时间，均为0表示持久会话

m=代表媒体描述，包括媒体类型、端口、传输协议、媒体格式等

a=代表附加属性，此处用于对媒体协议进行扩展

两端之间的协商过程就是SDP交换的过程，如下图。

WebRTC信令交换过程的架构

ICE连接大致的原理及步骤如下：

发起收集ICE Canidate任务。

本机能收集host类型（内网IP端口）的candidate。

通过STUN服务器收集srflx类型（NAT映射到外网的IP端口）的candiate。

通过TUN服务器收集relay类型的（中继服务器的 IP 和端口）的candidate。

开始尝试NAT穿越，按照host类型、srflx类型、relay类型的优先级去连接。

概念4：STUN和TURN：

STUN

该服务器用于检索远程端的公共IP地址。简单来说，就是我们每个人都有一个公共IP地址，并使用STUN服务器获取此信息。然后这些信息会成为你刚进入房间时需要发送给另一端的SDP信息的一部分。

TURN

如果你需要与你的远程端联系，但无法直接与其联系的话，TURN服务器可以作为媒介来为你传递消息。

现代互联网环境非常复杂，我们的设备通常隐藏在层层网关后面，因此，要建立直接的连接，还需要知道双方可用的连接地址，这个过程被称为NAT穿越，主要由ICE服务器完成，所以也称为ICE打洞。

首先简单了解以下三个概念。

ICE Canidate（ICE 候选者）：包含远端通信时使用的协议、IP 地址和端口、候选者类型等信息。

至此，整个过程就完成了。

=======================分割线======================

上面主要围绕WebRTC技术本身，讲讲实现通话的整个过程。其实腾讯云TRTCweb端，整体流程也是一致的，作为视频云服务，封装了大量的东西比原生极大降低了接入门槛。下面结合腾讯云TRTCweb端，再聊聊以上过程：

1）流程中的关键事件

上图为腾讯云实时音视频控制台，某次通话的详情，用户均可以进入自己的控制台查看。

在其中的事件详情中，可以看到一次通话过程中最重要的事件，信令通道和媒体通道的连接断开过程都有：

在实际问题案例中，经常会有客户反馈web端通话失败，那究竟为什么失败了？很多情况下，看看控制台关键事件，基本问题都可以定位到。遇到问题，看看是不是信令通道就连接失败了？媒体通道有没有连接成功？

2）流程中的日志

有条件结合浏览器日志，可以进一步定位更多的信息。

浏览器日志中，详细记录了从进房、信令通道建立、获取本地音视频、交换sdk、建立媒体通道、接受渲染对端音视频的整个过程。限于篇幅，过长了各位看官看着疲累，后面专开一文，结合案例分析分析日志。

说些其他经常被问到的问题：

1）很多人会问了，webrtc技术那么好，会替代直播么

先说下我的答案，短期内不会。

为什么这么说呢，这要从webrtc的出现说起，立项的初衷是为了让开发者能够基于浏览器，在不借助插件的情况下，轻松开发出实时多媒体应用，实现两人/多人的实时音视频通话。从诞生初衷上讲，webrtc一直围绕解决的是不依赖后台服务器情况下的强实时交互的问题。

说回直播，直播服务目前解决的是什么场景呢？直播目前绝大多数情况都是用在对实时性要求低，但是对观看并发量要求很高的场景，简而言之就是数以万计的观众跟主播之间不会连麦交流，只是单方面收看的情况。这种需要大规模分发的场景下，对后台服务端的要求是很高的，需要有强大的CDN做支撑。

Webetc是通过p2p的形式来实现通话，大规模分发的场景并不适合。但是，现阶段webrtc技术的开源帮助直播解决了很多问题，有很大的应用空间。

2）WebRTC选择了UDP作为底层传输协议。为什么不选择可靠性更强的TCP？

原因主要有三个：

lUDP协议无连接，资源消耗小，速度快

l传输过程中少量的数据损失影响不大

lTCP协议的超时重连机制会造成非常明显的延迟