从0到1打造一个 WebRTC 应用

🧑‍💻 写在开头
点赞 + 收藏 === 学会🤣🤣🤣

前言

2020 年初突如其来的新冠肺炎疫情让线下就医渠道几乎被切断，在此背景下，微医作为数字健康行业的领军者通过在线问诊等形式快速解决了大量急需就医人们的燃眉之急。而作为微医 Web 端在线问诊中重要的一环-医患之间的视频问诊正是应用了接下来讲述的 WebRTC 技术。

WebRTC 是什么

WebRTC(Web Real-Time Communication)是 Google 在 2010 年以 6820 万美元收购 VoIP 软件开发商 Global IP Solutions 的 GIPS 引擎，并改名为“WebRTC”于 2011 年将其开源的旨在建立一个互联网浏览器之间的音视频和数据实时通信的平台。
那么 WebRTC 能做些什么呢？除了上述提到的医疗领域中的在线问诊/远程门诊/远程会诊，还有时下较为流行的电商互动直播解决方案、教育行业解决方案，除此之外，伴随着 5G 的快速建设，WebRTC 也为云游戏提供了很好的技术支撑。

WebRTC 架构

下图是来自WebRTC 官网的 WebRTC 整体架构图

从图中不难看出，整个 WebRTC 架构设计大致可以分为以下 3 部分：

紫色提供给 Web 前端开发使用的 API
蓝色实线部分提供各大浏览器厂商使用的 API
蓝色虚线部分包含 3 部分：音频引擎、视频引擎、网络传输 (Transport)。都可以自定义实现

WebRTC 点对点通信原理

要实现两个不同网络环境（具有麦克风、摄像头设备）的客户端（可能是不同的 Web 浏览器或者手机 App）之间的实时音视频通信的难点在哪里、需要解决哪些问题？

怎么知道彼此的存在也就是如何发现对方？
彼此音视频编解码能力如何沟通？
音视频数据如何传输，怎么能让对方看得自己？

对于问题 1：WebRTC 虽然支持端对端通信，但是这并不意味着 WebRTC 不再需要服务器。在点对点通信的过程中，双方需要交换一些元数据比如媒体信息、网络数据等等信息。我们通常称这一过程叫做：信令(signaling)。对应的服务器即信令服务器 (signaling server)。通常也有人将之称为房间服务器，因为它不仅可以交换彼此的媒体信息和网络信息，同样也可以管理房间信息，比如通知彼此 who 加入了房间,who 离开了房间，告诉第三方房间人数是否已满是否可以加入房间。
为了避免出现冗余，并最大限度地提高与已有技术的兼容性，WebRTC 标准并没有规定信令方法和协议。在本文接下来的实践章节会利用 Koa 和 Socket.io 技术实现一个信令服务器。
对于问题 2：我们首先要知道的是，不同浏览器对于音视频的编解码能力是不同的。比如: Peer-A 端支持 H264、VP8 等多种编码格式,而 Peer-B 端支持 H264、VP9 等格式。为了保证双方都可以正确的编解码，最简单的办法即取它们所都支持格式的交集-H264。在 WebRTC 中，有一个专门的协议，称为Session Description Protocol(SDP),可以用于描述上述这类信息。因此参与音视频通讯的双方想要了解对方支持的媒体格式，必须要交换 SDP 信息。而交换 SDP 的过程，通常称之为媒体协商。
对于问题 3：其本质上就是网络协商的过程：参与音视频实时通信的双方要了解彼此的网络情况，这样才有可能找到一条相互通讯的链路。理想的网络情况是每个浏览器的电脑都有自己的私有公网 IP 地址，这样的话就可以直接进行点对点连接。但实际上出于网络安全和 IPV4 地址不够的考虑，我们的电脑与电脑之间或大或小都是在某个局域网内，需要NAT(Network Address Translation, 网络地址转换)。在 WebRTC 中我们使用 ICE 机制建立网络连接。那么何为 ICE？
ICE (Interactive Connecctivity Establishment, 交互式连接建立)，ICE 不是一种协议，而是整合了 STUN 和 TURN 两种协议的框架。其中STUN(Sesssion Traversal Utilities for NAT, NAT 会话穿越应用程序)，它允许位于 NAT（或多重 NAT）后的客户端找出自己对应的公网 IP 地址和端口，也就是俗称的“打洞”。但是，如果 NAT 类型是对称型的话，那么就无法打洞成功。这时候 TURN 就派上用场了，TURN(Traversal USing Replays around NAT)是 STUN/RFC5389 的一个拓展协议在其基