想开发一款带有视频通话 / 共享屏幕功能的产品？那 WebRTC 是你必须要知道的！

作为一名技术爱好者，我总是对各种协议、各种功能感兴趣，两周前我想为我的开源项目ChatCraft集成视频通话功能，我就开始了对应技术的研究，然后我盯上了 WebRTC。在这个研究过程中，我恶补了大量有关 WebRTC 的知识，并在最后，成功实现了视频通话功能。我想，我这次尝试值得分享。所以就这样……如果你还感兴趣，那就继续看下去吧！

这篇文章是实战的前置文章，在这篇文章中一起来学习 WebRTC 的相关知识吧！

什么是 WebRTC

网页即时通信（Web Real-Time Communication），是一个支持浏览器（不局限于浏览器，例如在 App 中使用，只需要自己实现音频、视频的采集，传输即可）进行实时语音对话或视频对话的 API。简单来说，有了 WebRTC 我们可以通过一些简单的 API 就可以给浏览器和 App 提供实时通信（RTC）的功能。

而在 WebRTC 推出之前，开发实时音视频交互应用的成本高昂且技术挑战多·，包括音视频编解码、数据传输、延迟、丢包、抖动、回声处理...等问题。现在就简单了，例如视频通话时，音频因为环境或其他问题导致的有噪声、回声干扰，如果不做处理，用户体验会很差，而 WebRTC 提供了 3A 算法 + NetEQ，让实时环境中的声音处理及互动体验得到了大幅的提升。

WebRTC 主要用来做什么

WebRTC 是不局限于浏览器的，只要使用设备的 IP 链接可到达，且符合 WebRTC 规范的就可以互相连接。所以，能应用的领域就非常多。举几个现在常见的例子：

• 共享桌面

• 视频/语音聊天

• 视频会议

• 云端游戏

• P2P 网络加速

• ...

看到这里，相信你已经对 WebRTC 有了一个最基础的基本概念了，知道它会出现在什么应用场景下，如果你还感兴趣的话，那就让我们揭开它神秘的面纱吧！

在 WebRTC 中发生了什么？

让我来通过一个场景小故事，告诉你在 WebRTC 中发生了什么~

故事开头： 从前，在一个数字世界里，有两个神秘的实体，它们分别被命名为 A 和 B。A 是一位智慧的编码者，B 则是一位梦想的解码者。

过程： A 和 B 都拥有着珍贵的信息，但它们需要一种安全的方式来分享这些信息。于是，A 开始寻找通向 B 的神秘通道。它穿越虚拟的网络山川，寻找能够连接到 B 的公共路径。A 仔细检查自己的数字身份，确保自己可以被其他实体识别。同时，它还检查了自己的数字路由器，确保可以传递信息给 B。

与此同时，B 也在为这次神秘相遇做准备。它同样寻找通向 A 的路径，准备好自己的数字身份和路由器。A 和 B 收集了大量信息，包括加密方式、安全参数和视频编解码器，这些信息构成了他们的“SDP”。

结尾： 最终，A 和 B 通过一种数字化的方式传递了会话信息。这个方式可以是通过电子邮件、虚拟信使，甚至是通过传送门。WebRTC 并不关心具体的传递方式，只要信息能够从 A 到 B，它们就可以开始他们的数字通信之旅。一旦 A 和 B 交换了 SDP，它们就像魔法般实现了真正的点对点通信。不再需要第三方干涉，它们可以直接建立连接，分享彼此的智慧和梦想。最终，A 和 B 通过最优的数字路径找到了彼此，这就是 WebRTC 的神奇之处。

WebSocket 和 WebRTC 的区别是什么？

熟悉 WebSocket 的朋友到这里就会发现了，好像他们都是转发消息。如果你也这么想，那恭喜你，你已经熟悉了 WebRTC 的一小点部分。WebRTC 其实也使用了 WebSocket，用于搭建 WebRTC 的信令机制，但是因为 WebRTC 是端到端连接，在 WebSocket 连接建立结束后，就不再需要额外服务器。那它们之间到底有什么区别呢？我们分别从设计理念和实现区别来看。

• 设计理念

• WebSocket 主要用于 IM 聊天应用。

• WebRTC 是为高质量音视频实时通信设计的。

• 实际区别

• WebRTC 使用 UDP 协议，而 WebSocket 使用 TCP 协议。

• WebRTC 提供的浏览器端到端通信比 WebSocket 提供的服务延迟更低。

WebRTC 用到了哪些技术？

WebRTC 其实就是一组其他技术的集合体，这里面包含了许许多多的协议、技术点，想在文章中分析完所有的技术点不太现实，我们来讲点关键的！

NAT（Network Address Translation）

网络地址转换，这个技术相信大部分看文章的朋友都有在大学期间学习过，用来解决IPv4地址短缺的问题。所谓的网络地址转换，就是把内网地址转换成可以访问外网的地址。那和 WebRTC 有什么关系呢？关系大了！WebRTC 是 P2P 方式，我们需要找到对方的 ip，点对点的连接。如果对方有一个公开的 IP 地址，那么连接过程将不会有什么问题。因为会像连接一个网页服务一样，把端口和 IP 都提供给对方后，我们和它就可以直接进行连接了。但在大多数情况下，它都是隐藏在公共网络之后的，我们无法直接连接。

对 NAT 网络地址转换的运行原理感兴趣的朋友可以自行学习，就不在本文展开了。

NAT 的转换方式主要有四种，而 WebRTC 默认支持三种网络扩展的方式，对其他的方式并不友好，且大部分的网络地址转换都是通过以下三种方式：

• 一对一 NAT（完全圆锥型 NAT）

• IP 受限型 NAT

• 端口受限型 NAT

STUN 和 TURN

而网络地址转换过程主要依赖于两种协议，即会话穿越工具（STUN）和中继 NAT 穿越工具（TURN）。

STUN 服务器的作用是帮助设备发现自己的公网 IP 地址和端口。它是非常轻量级的，通常位于公共网络上，并且有一个简单的任务：就是检查终端传入请求的 IP 地址（躲在 NAT 后面的程序），并将该地址作为响应发送回去。这个过程使得 WebRTC A 端为自己获得一个可公开访问的地址，然后通过信令机制将其传递给 B 端（或其他端）以建立直接链接。

然而，STUN 不能在所有情况下都工作，特别是当 NAT 防火墙的策略比较严格时，例如在刚才讲 NAT 的时候没有提到的第四种方式——对称 NAT（Symmetric NAT），在这种环境下必须使用 TURN！TURN 服务器实际上扮演了媒体流的中继角色，将数据从发送端传到接收端。这代表着：所有的通信内容都要经过 TURN 服务器的转发，导致 TURN 服务器的维护成本比较高，所以我们可以发现，基本上没有免费给用户使用的 TURN 服务器。

想创建 TURN 服务器可以参考： https://github.com/coturn/coturn

ICE 框架

当客户端和服务端媒体协商完成后，需要开始建立网络连接，它会 STUN 和 TRUN 协议完成工作。之后，我们就会从 A 端到 B 端之间的路径有了非常多的选择，ICE 框架就是为了更好的处理这些路径而提出的。ICE 会获取所有可用的通信路径，并将其作为"候选者"。这些路径可能包括本地 IP 地址以及 STUN 和 TURN 服务器提供的地址等。然后，ICE 将收集到的所有地址放入 SDP（会话描述协议） 中，并将其发送到对方。对方通过解析 SDP 来了解我们提供的重要信息。

SDP

在前面我们说到了 SDP（会话描述协议），那它的作用主要是什么呢？SDP 只是一种数据格式，而且它是 WebRTC 中最重要的几个概念之一。它的设计目的是将用户产生的 SDP 送至其他端，怎么发送的它不管，当 A 端想要开始一个通话时，它就会创建一个包含了自己可接受的媒体格式、网络信息、安全选项和其他信息的 offer，然后发送给 B 端。收到 offer 的 B 端会回复一个 answer，包含了它决定使用的媒体和网络参数。我们开发者也可以自定义 SDP 的内容。

信令交换

如果看了 SDP 交换的过程图，那大家一定看到了中间的信令，信令其实就是一个转发服务，将一个设备端产生的 SDP 通过某种方式传递给想要通信的那方，大部分使用 websocket 或 socket 服务。其实啥方式都不重要，能将 SDP 信息传递给另外一方就可以了。

一个典型的 WebRTC 通信流程

知道了 WebRTC 大部分的技术，那一个典型的 WebRTC 通信流程就出现了！

看到这里，我相信你对 WebRTC 已经有了初步了解了，那么在下一篇 WebRTC 的系列文章中，我们来实现一个可以多端视频/语音电话的功能吧！

关于我

Hello，我是 Taxze，如果您觉得文章对您有价值，希望您能给我的文章点个❤️，有问题需要联系我的话：我在这里 。如果您觉得文章还差了那么点东西，也请通过关注督促我写出更好的文章~万一哪天我进步了呢？😝