WebRTC 笔记

最近研究了一下 WebRTC，写篇笔记记录下。

0. WebRTC 简介

WebRTC 是一种 p2p 技术，它可以在两个不同的浏览器之间建立直连，让它们互相传输数据、视频和音频流。

这个技术可以充分利用用户自己的上行带宽和网络环境，降低中心服务器的负载，既提升用户体验，又能降低服务提供者的成本。用在一些低成本的场景非常合适，比如视频会议、轻型联网游戏、内容共享网络等。

由于其低成本的优势，我想用它给 mywordle.org 升级，支持用户 1v1 对战。将来的话，还可以搞一些 FC 模拟器玩玩。

1. WebRTC 基本概念

WebRTC 的概念不少，初次连接也很复杂，有些我现在还没完全搞清楚。所以这个部分以后再慢慢更新。另外这里的内容并不是按着规范走的，而是来自我的实践。

1.1 基本概念

1.1.1 信令服务器

这可能是 WebRTC 里最重要的一个概念，每个浏览器 tab 页都是网络中的一个孤岛，必须通过信令服务器才能找到对方，建立连接。

信令服务器是必须的，不能通过人工方式完成两个节点的互联（或者说很难）。但是信令服务器并不一定要自己建，有不少公共的可以蹭。

1.1.2 Ice 服务器 RTCIceServer

同一个局域网内连接很简单，但实际上并不常见。我们日常使用的网络，无论移动网络还是家里的宽带，其实都是位于 NAT 后面，相当于总机分机的概念。两个 NAT 后面的应用想连接就比较困难了，此时就需要 RTCIceServer 帮忙，协商在两个 NAT 上打洞。

具体的实现逻辑我们不用关心，只要会用就行。目前有两类 RTCIceServer：STUN 和 TURN。前者只负责给双方牵线搭桥，本身不介入连接，有很多公共服务可以蹭；TURN 不光能把两个端连接起来，还能在两端中间网络不通的时候作为 fallback 方案。功能更强，真正生产级别的产品都需要；但是相应的，TURN 需要更高的资源支撑，免费资源也很少。

1.2 发起连接

当用户 A 想要跟用户 B 建立 WebRTC 连接时：

1. A 创建一个 RTCPeerConnectioin 对象
2. 创建一个 offer，其中包含着 A 的网络信息，其它人通过这个信息可能找到 A
3. A 把 offer 发给信令服务器
4. 信令服务器把 offer 发给用户 B
5. 用户 B 记录下 offer，然后生成 answer。answer 跟 offer 其实是一样的，只是用来作为响应。这也是必须有信令服务器的原因。
6. B 把 answer 发给信令服务器
7. 信令服务器把 answer 发给 A
8. A 尝试用 answer 建立连接，如果是局域网，双方可能已经连上了
9. 如果连不上，则 A 尝试通过 ice server 连接。
10. A 创建自己的 icecandidate 信息，然后发给信令服务器
11. 信令服务器将 A 的 icecandidate 发给 B
12. B 添加后，也创建自己的 icecandidate，发给信令服务器
13. 信令服务器将 B 的 icecandidate 发给 A
14. A 添加之，并尝试创建连接
15. 如果一切正常，这个时候就连上了。

2. 实操

我建立了一个项目：meathill/webrtc-playground: learn webrtc (github.com)，目前还在升级开发中。

1. 实现一个 websocket 服务器（基于 socket.io），作为信令服务器，交换信令
2. 用各种姿势尝试建立连接
3. 同浏览器多 tab 连接成功
4. 内网连接成功
5. 手机开热点，尝试公网连接，也成功
6. 尝试跟朋友连接，失败。遇到两个问题：
   1. 他家的网络是广州联通，我家是广州电信
   2. 他的手机网络是北京联通
   3. 目前的信令服务器会无条件广播各种信息，当我跟他都多开 tab 的时候，很难保证连接的两端是匹配的
7. 于是接下来要重构。

3. 总结

这次学习过程一波三折。首先，WebRTC 的用户大部分关注音视频传输，毕竟这方面效果最明显；DataChannel 其实只算个添头，偏偏我最关注这个，所以找内容花了不少时间。

接下来，大部分范例代码都只是抄来抄去，一个 tab 内部来回连，经常会看错。另外，一些概念也不清不楚，比如 ice server，无法主动触发请求。

终于调通了内网和公网，又遇到联通电信问题……看来将来 TURN 服务器也必不可少。