WebRTC基础理论和通话原理

WebRTC理论知识

1.什么是WebRTC?

        WebRTC（Web RealTime Communication）是 Google于2010以6829万美元从 Global IP Solutions 公司购买，并 于2011年将其开源，旨在建立一个互联网浏览器间的实时通信的平台，让 WebRTC技术成为 H5标准之一。它定义了一组标准化的API,用于在浏览器和移动应用程序中进行实时语音、视频和数据通信,无需安装任何插件或其他软件。

1.2 WebRTC框架

主要组件组成:

• WebRTC API:

  • 这是 WebRTC 的核心 API,提供了用于建立端到端连接、发送和接收媒体流的功能。

  • 这些 API 包括 getUserMedia、RTCPeerConnection、RTCDataChannel 等。

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

• 信令服务器:

  • WebRTC 需要一个信令服务器来协调客户端之间的连接过程。

  • 信令服务器负责交换连接信息,如 SDP (Session Description Protocol) 协商和 ICE 候选。

  • 信令服务器可以使用 WebSocket、HTTP 等协议进行通信。

• STUN 和 TURN 服务器:

  • STUN (Session Traversal Utilities for NAT) 服务器用于帮助客户端发现自己的公网 IP 地址和端口。

  • TURN (Traversal Using Relays around NAT) 服务器用于在客户端无法直接连接时提供中继服务。

• 编解码器和媒体引擎:

  • WebRTC 内置了多种音视频编解码器,如 VP8、VP9、H.264 等,以及音频编解码器 Opus。

  • 媒体引擎负责捕获、编码、传输和解码媒体流。

• 安全机制:

  • WebRTC 使用 DTLS 和 SRTP 等加密协议来确保通信的安全性和隐私性。

• WebRTC 库和框架:

  • 诸如 PeerJS、SimpleWebRTC 等开源 JavaScript 库,提供了更高级的 WebRTC 功能封装。

  • 一些 WebRTC 框架,如 Janus Gateway、Kurento Media Server,提供了更强大的服务端功能。

上图的框架对于不同的开发人员关注点不同：

（1）紫色部分是Web应用开发者API层

（2）蓝色实线部分是面向浏览器厂商的API层

（3）蓝色虚线部分浏览器厂商可以自定义实现

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

1.3WebRTC发展前景

WebRTC 作为一项实时通信技术,在未来几年内有着广阔的发展前景,主要体现在以下几个方面:

• 浏览器和移动端的原生支持:

  • 目前主流浏览器如 Chrome、Firefox、Safari、Edge 等都已经原生支持 WebRTC,无需安装任何插件。

  • 移动端 App 也可以通过 WebRTC 库进行跨平台的实时通信集成。

  • 这种广泛的原生支持为 WebRTC 的未来发展奠定了基础。

• 视频通话和会议的崛起:

  • 在疫情期间,视频会议和远程办公/教育需求激增,WebRTC 技术在这些场景中发挥了重要作用。

  • 未来随着 5G 网络的普及,视频通话和高清视频会议将越来越普及,WebRTC 将在这些应用中大显身手。

• 实时互动应用的兴起:

  • 除了视频通话,WebRTC 还可以用于构建实时协作、在线游戏、远程医疗等各种实时互动应用。

  • 这些应用领域都需要低延迟、高质量的实时通信能力,WebRTC 可以很好地满足这些需求。

• 物联网和边缘计算的结合:

  • 随着物联网和边缘计算的发展,WebRTC 有望在这些领域发挥重要作用。

  • 通过 WebRTC,物联网设备可以实现端到端的实时数据传输和远程控制。

• 实时视频分析和人工智能应用:

  • WebRTC 可以为实时视频分析和人工智能应用提供数据来源。

  • 结合 WebRTC 的实时性和机器学习技术,可以开发出智能监控、人脸识别等应用。

• 安全性和隐私性的优势:

  • WebRTC 内置了安全加密机制,如 DTLS 和 SRTP,能够确保通信的安全性和隐私性。

  • 这对于一些涉及隐私敏感数据的应用场景非常重要。

小结：WebRTC 作为一项开放、标准化的实时通信技术,在未来几年内将会在各种应用场景中得到广泛应用和发展。随着 5G 网络、物联网、人工智能等技术的进步,WebRTC 的应用前景将更加广阔。

WebRTC通话原理

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

答：

1. 媒体协商

2. 网络协商

3. 交换通道（传输媒体协商和网络协商后的数据）

媒体协商

 意思是彼此要了解对方支持的媒体格式，必须采用支持相同的编解码。

解决方案：

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

网络协商

 意思是彼此要了解对方的网络情况，这样才有可能找到一条相互通讯的链路。在WebRTC中用来描述 网络信息的术语叫candidate。

实现难点：

NAT 和防火墙穿透:

- 客户端通常位于 NAT 网络之后,无法直接访问对方的公网 IP 地址和端口。
- 解决方案：需要使用 STUN 和 TURN 服务器,帮助客户端发现自己的公网 IP 地址和端口,并尝试各种连接方式。

STUN

STUN（Session Traversal Utilities for NAT，NAT会话穿越应用程序）是一种网络协议，是一个用于帮助 WebRTC 客户端发现自己的公网 IP 地址和端口的协议。

STUN 协议的一个重要特点是采用了 UDP 协议,这是因为 UDP 比 TCP 更适合于客户端探测自己的网络信息。UDP 的请求-响应模式也更适合于 STUN 服务器的工作方式。

STUN 的工作原理如下:

客户端询问 STUN 服务器:

• WebRTC 客户端向预先配置的 STUN 服务器发送一个 STUN 请求。

• STUN 请求中包含客户端的本地 IP 地址和端口信息。

STUN 服务器响应客户端:

• STUN 服务器收到请求后,会检查客户端的 IP 地址和端口,并感知它们是否被 NAT 转换了。

• STUN 服务器会将客户端的公网 IP 地址和端口信息包含在响应消息中返回给客户端。

客户端获取自身网络信息:

• 客户端收到 STUN 服务器的响应后,就可以获取自身的公网 IP 地址和端口信息。

• 这些信息对于后续的 WebRTC 连接建立非常重要。

使用一句话说明STUN做的事情就是：告诉我你的公网IP地址+端口是什么。搭建STUN服务器很简单，媒体流传输是 按照P2P的方式。

TURN

        TURN (Traversal Using Relays around NAT) 协议,它提供了更强大的穿透功能,可以在 STUN 无法直接穿透 NAT 时提供中继服务。是STUN/RFC5389的一个拓展，主要添加了Relay功能。如果 终端在NAT之后， 那么在特定的情景下，有可能使得终端无法和其对等端（peer）进行直接的通信，这时就需要公 网的服务器作为一个中继， 对来往的数据进行转发。这个转发的协议就被定义为TURN。

         在STUN分配公网IP失败后，可以通过TURN服务器请求公网IP地址作为中继地址。这种方式的带宽由服务器端承 担，在多人视频聊天的时候，本地带宽压力较小，并且，根据Google的说明，TURN协议可以使用在所有的环境中。 （单向数据200kbps 一对一通话，假设c-a 传输200kbps c-b同理，服务器则需承受200kbps * 2）        

小结：先进行stun nat转化是否成功拿到公网ip+port的映射ip，失败则进行turn的中继服务器传输数据。 

交换通道

已得到媒体信息和网络信息，那怎么去交换？是不是需要一个中间商去做交换？

答：我们需要一个信令服务器（Signal server）转发彼此的媒体信息和网络信息。

我们在基于WebRTC API开发应用（APP）时，可以将彼此的APP连接到信令服务器（Signal Server，一般 搭建在公网，或者两端都可以访问到的局域网），借助信令服务器，就可以实现上面提到的SDP媒体信息及 Candidate网络信息交换。

信令服务器不只是交互 媒体信息sdp和网络信息candidate，比如： 房间管理

 ICE

ICE（交互式连接建立）

ICE（Interactive Connectivity Establishment）并不是一种协议，而是一个框架，用于帮助在NAT（网络地址转换）环境中建立UDP多媒体会话，它负责找出两个对等方最佳的通信方式,无论是直接的点对点连接还是通过中继服务器 。

ICE的主要功能包括：

• 收集候选地址：ICE会收集三种类型的地址，包括本地网络接口地址、STUN服务器地址和TURN服务器地址。

• 排序候选地址：根据优先级对候选地址进行排序，以便选择最佳连接路径。

• 连接检查：通过STUN请求和响应进行连接可用性检测。

• 冻结候选地址：在连接建立后，ICE会冻结某些候选地址以优化连接过程。

• 安全检查：通过消息授权码（MAC）验证消息的真实性和来源。

ICE的目标是发现哪些地址对可以成功建立连接，并选择最佳的连接方式 [1][3]。

总结起来:

• ICE 是 WebRTC 用于建立两个对等方连接的整体框架。

• STUN 用于确定每个对等方的公网 IP 地址和 NAT 类型,这有助于 ICE 找到最佳的连接方式。

• TURN 在直接的点对点连接不可能的情况下被用作最后的手段,提供了一个中继服务器来转发两个对等方之间的媒体流量。

 "打洞"

"打洞"就是指使用 STUN 和 TURN 协议来帮助这两个对等方找到一种方式建立连接的过程。具体来说:

1. STUN 协议可以帮助对等方发现自己的公网 IP 地址和端口信息,这些信息被称为 ICE 候选者(ICE Candidate)。

2. 然后,对等方会通过信令服务器交换这些 ICE 候选者信息。

3. 接下来,ICE 框架会尝试使用这些 ICE 候选者,通过各种方式(如 UDP 穿透 NAT、TCP 连接等)来建立 P2P 连接。这个过程就叫做"打洞"。

如果 STUN 协议无法成功穿透 NAT,那么就需要使用 TURN 协议,由 TURN 服务器充当中转站来转发两个对等方的媒体数据。

总之,"打洞"指的就是 WebRTC 在建立 P2P 连接时使用的一系列技术手段,包括 STUN 和 TURN 协议,目的是要穿透各种网络环境的限制,实现对等方之间的直接通信。

学习资料分享

0voice · GitHub