WebRTC 初探
前言
项目中有局域网投屏与文件传输的需求，所以研究了一下 webRTC，这里记录一下学习过程。
WebRTC 基本流程以及概念
下面以 1 对 1 音视频实时通话案例介绍 WebRTC 的基本流程以及概念
WebRTC 中的角色
-
WebRTC 终端,负责音视频采集、编解码、NAT 穿越、音视频数据传输
-
Signal 服务器,负责信令处理,如加入房间、离开房间、媒体协商消息的传递等。
-
STUN/TURN 服务器,负责获取 WebRTC 终端在公网的 IP 地址,以及 NAT 穿越失败后的数据中转。
媒体协商
SDP(Session Description Protocal): 用文本描述的各端(PC 端、Mac 端、Android 端、iOS 端等)的能力。
这里的能力指的是各端所支持的音频编解码器是什么,这些编解码器设定的参数是什么,使用的传输协议是什么,以及包括的音视频媒体是什么
媒体协商流程图
-
呼叫方创建 Offer 类型的 SDP 消息。创建完成后,调用 setLocalDescriptoin 方法将该 Offer 保存到本地 Local 域,然后通过信令将 Offer 发送给被呼叫方。
-
被呼叫方收到 Offer 类型的 SDP 消息后,调用 setRemoteDescription 方法将 Offer 保存到它的 Remote 域。作为应答,被呼叫方要创建 Answer 类型的 SDP 消息,
-
Answer 消息创建成功后,再调用 setLocalDescription 方法将 Answer 类型的 SDP 消息保存到本地的 Local 域。最后,被呼叫方将 Answer 消息通过信令发送给呼叫方。
-
呼叫方收到 Answer 类型的消息后,调用 RTCPeerConnecton 对象的 setRemoteDescription 方法,将 Answer 保存到它的 Remote 域
具体的媒体协商的过程是 WebRTC 内部自己去实现的, 作为开发者只需要记住本地的 SDP 和远端的 SDP 都设置好后,协商就算成功了.
紧接着在 WebRTC 底层会收集 Candidate,并进行连通性检测,最终在通话双方之间建立起一条链路来。
WebRTC 的连接 与 ICE Candidate(重点)
WebRTC 之间建立连接的过程是非常复杂的, 主要的原因在于它内部的实现既要考虑传输的高效性,又要保证端与端之间的连通率。
当同时存在多个有效连接时,它首先选择传输质量最好的线路,如能用内网连通就不用公网。另外,如果尝试了很多线路都连通不了,那么它还会使用服务端中继的方式让双方连通
WebRTC 是如何做到的? 答案是采用多个 Candicate 排序并执行连通性测试的方式
ICE Candidate
它表示 WebRTC 与远端通信时使用的协议、IP 地址和端口, 一般有以下字段
其中:
-
host 表示 本机候选者
-
srflx 表示内网主机映射的外网的地址和端口(通过 TURN 服务器, 需要在 PeerConnectionConfig 里面去配)
-
relay 表示中继候选者 (通过 TURN 服务器, 需要在 PeerConnectionConfig 里面去配),
假设 A 和 B 都有多个 candidate, 那么 WebRTC 会按照host->srflx→relay的方式进行联通性测试, 选择最合适的方案
作为开发者, 只需要做两件事情:
1.部署相应的 TURN 服务器和 STUN 服务器(有现成的), 初始化 peerConnection 对象的时候配置 iceServers
- 监听 oniceccandidate 方法, 每接收到一个 candidate, 就通过信令服务器发送给另外一方即可
当我们没有设置 TURN 服务器或者 STUN 服务器的时候, 两个端建立起了连接, 就可以判断两个端位于同一个局域网内
STUN 服务器与 NAT 穿透
如果两台主机不在同一个内网, WebRTC 将尝试 NAT 打洞,即 P2P 穿越。WebRTC 将 NAT 分类为 4 种类型
-
完全锥型
-
NAT IP 限制型
-
NAT 端口限制型
-
NAT 对称型 NAT
具体的穿透逻辑也是对开发者屏蔽的, 但基本的思路是: 在公网上架设一台服务器,并向这台服务器发个请求, 该服务器往响应中塞入公网 IP , 这样客户端就可以知道自己的公网 IP
WebRTC 兼容性
从 can-i-use 中可以看到浏览器的支持情况还是相对乐观的
但是直接使用 webrtc 原生的 API 还是比较麻烦的, 虽然浏览器支持了 WebRTC, 但是各大浏览器内部的实现方式还是有差异, 需要对应的 pollyfill 方案
目前只有 adaptor.js 可以选择, 可以官方推荐的方案
基于原生 webrtc 的调用流程图
从上面的描述可以看到, 基于原生 WebRTC 去实现投屏功能的话还是比较麻烦的,
特别是 SDP 交换（createOffer 及 createAnswer）、网络候选信息收集(ICE candidate)
Peerjs
peerjs 简化了 webrtc 的开发过程，把 SDP 交换、ICE candidate 这些偏底层的细节都做了封装，开发人员只需要关注应用本身就行了。
peerjs 的核心对象 Peer，它有几个常用方法：
- peer.connect 创建点对点的连接
- peer.call 向另 1 个 peer 端发起音视频实时通信
- peer.on 对各种事件的监控回调
- peer.disconnect 断开连接
- peer.reconnect 重新连接
- peer.destroy 销毁对象
另外还有二个重要对象 DataConnection、MediaConnection，其中：
- DataConnection 用于收发数据(对应于 webrtc 中的 DataChannel)，它的所有方法中有一个重要的 send 方法，用于向另一个 peer 端发送数据；
- MediaConnection 用于处理媒体流，它有一个重要的 stream 属性，表示关联的媒体流。
peerjs 内置了一套信令服务器, peer-server, 开发者可以自己部署, 不指定的情况下会使用 peerjs 官方托管的信令服务器
总结：
- 相比原生的方案, api 简化, 开发者关注底层的细节少了
- 提供了 peer-server 可供部署, 官方也提供免费托管的 peerServer
- 封装程度比较高, 后续改造会比较麻烦
Simple-peer
与 peerjs 类似, 把 SDP 交换、ICE candidate 这些偏底层的细节都做了封装, 但是封装程度没有 peerjs 那么高, 提供了一定的灵活性:
peer.signal(data): 发送信令
peer.send(data): 发送 data
peer.addStream(stream): 添加音视频流
peer.removeStream(stream): 移除音视频流
peer.addTrack(track, stream)
peer.removeTrack(track, stream)
peer.destroy([err]): 销毁实例
peer.on(): 监听各种事件
相比 peerjs, simple-peerjs 自己并不提供 peerServer 作为信令服务器, 而是提供了一个 signal 事件
peer.on("signal", (data) => {// when peer1 has signaling data, give it to peer2 somehow// 在这里使用IM发送信令
});
总结：
- 一定程度的封装, 相比原生不需要写很多冗余的样板代码，但也意味着一个高级功能的实现需要自己来实现(peerjs 有文件传输相关的实现)
- 相比 peerjs, 不依赖 peerServer, 可以接入我们的 IM
- 总代码不到一千行, 且不依赖 server 代码, 改造起来比较容易
一些注意事项
https 限制
由于浏览器的安全限制, 本地开发的时候需要使用 localhost 访问, 或者配置 https 证书, 不然无法拿到 navigator.mediaDevices 对象
参考
-
webrtc-samples
-
google webrtc
-
Peerjs
-
Simple-peer
-
从 0 打造音视频直播系统
本文首发于个人博客前端开发笔记，由于笔者能力有限，文章难免有疏漏之处，欢迎指正