最近研究了一下 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 连接时：
- A 创建一个
RTCPeerConnectioin对象 - 创建一个
offer，其中包含着 A 的网络信息，其它人通过这个信息可能找到 A - A 把
offer发给信令服务器 - 信令服务器把
offer发给用户 B - 用户 B 记录下
offer，然后生成answer。answer跟offer其实是一样的，只是用来作为响应。这也是必须有信令服务器的原因。 - B 把
answer发给信令服务器 - 信令服务器把
answer发给 A - A 尝试用
answer建立连接，如果是局域网，双方可能已经连上了 - 如果连不上，则 A 尝试通过 ice server 连接。
- A 创建自己的
icecandidate信息，然后发给信令服务器 - 信令服务器将 A 的
icecandidate发给 B - B 添加后，也创建自己的
icecandidate，发给信令服务器 - 信令服务器将 B 的
icecandidate发给 A - A 添加之，并尝试创建连接
- 如果一切正常，这个时候就连上了。
2. 实操
我建立了一个项目：meathill/webrtc-playground: learn webrtc (github.com)，目前还在升级开发中。
- 实现一个 websocket 服务器（基于 socket.io），作为信令服务器，交换信令
- 用各种姿势尝试建立连接
- 同浏览器多 tab 连接成功
- 内网连接成功
- 手机开热点，尝试公网连接，也成功
- 尝试跟朋友连接，失败。遇到两个问题：
- 他家的网络是广州联通，我家是广州电信
- 他的手机网络是北京联通
- 目前的信令服务器会无条件广播各种信息，当我跟他都多开 tab 的时候，很难保证连接的两端是匹配的
- 于是接下来要重构。
3. 总结
这次学习过程一波三折。首先，WebRTC 的用户大部分关注音视频传输，毕竟这方面效果最明显；DataChannel 其实只算个添头，偏偏我最关注这个，所以找内容花了不少时间。
接下来，大部分范例代码都只是抄来抄去，一个 tab 内部来回连，经常会看错。另外，一些概念也不清不楚，比如 ice server，无法主动触发请求。
终于调通了内网和公网，又遇到联通电信问题……看来将来 TURN 服务器也必不可少。