一、DataChannel 概述：为什么我们需要它？

WebRTC 最吸引我的地方，就是它不光能传音视频，还能传数据。你想想看，视频通话的同时，还能发文件、传文本、同步状态——这不就是真正的实时协作吗？

DataChannel 说白了，就是 WebRTC 里的一条「数据高速公路」。它跑在 SRTP 或 SCTP 协议之上，和音视频流共享同一个 ICE 连接。这意味着什么？意味着你不用再单独建一条 TCP 或 WebSocket 连接，就能实现双向数据传输。

我记得第一次在项目里用 DataChannel 时，最让我惊讶的是它的灵活性。你可以选择「可靠」模式，保证数据不丢包、不乱序；也可以选「不可靠」模式，追求极致的低延迟。嗯，这就像快递——你可以选顺丰保价，也可以选普通件，看你的业务需求。

1.1 DataChannel 与 WebSocket 的对比

很多初学者会问：为什么不用 WebSocket？我在项目中两种都用过，说说我的感受。

特性	DataChannel	WebSocket
传输层	SCTP over DTLS	TCP
加密	内置 DTLS 加密	需要 WSS（TLS）
传输模式	可靠/不可靠可选	仅可靠
延迟	低（尤其不可靠模式）	中等（TCP 拥塞控制）
是否需要服务器中转	不需要（P2P 直连）	需要
适用场景	实时游戏、文件传输、信令	聊天、推送、API 通信

你看，DataChannel 最大的优势就是「去中心化」。数据直接在两个浏览器之间传输，不经过任何服务器。这在隐私敏感的场景下特别有用——比如在线文档协作，用户的编辑内容不需要经过你的服务器。

二、DataChannel 的创建与使用

创建 DataChannel 其实很简单。但要注意一个关键点：谁创建，谁就是发起方。发起方调用 createDataChannel()，接收方通过 ondatachannel 事件来获取通道。

2.1 发起方创建 DataChannel

// 创建 RTCPeerConnection
const pc = new RTCPeerConnection(config);

// 创建 DataChannel
const dataChannel = pc.createDataChannel('myChannel', {
  ordered: true,        // 是否保证顺序
  maxRetransmits: 3     // 最大重传次数（不可靠模式）
});

// 监听状态变化
dataChannel.onopen = () => {
  console.log('通道已打开');
  dataChannel.send('Hello from initiator!');
};

dataChannel.onclose = () => {
  console.log('通道已关闭');
};

dataChannel.onerror = (err) => {
  console.error('通道错误:', err);
};

dataChannel.onmessage = (event) => {
  console.log('收到消息:', event.data);
};

这里有个坑，我踩过好几次：createDataChannel() 必须在 createOffer() 之前调用。为什么？因为 SDP 里需要包含 DataChannel 的协商信息。如果你先创建了 Offer，再创建 DataChannel，那 Offer 里就没有这个通道的描述，对方就收不到。

2.2 接收方监听 DataChannel

// 接收方只需要监听 ondatachannel 事件
pc.ondatachannel = (event) => {
  const dataChannel = event.channel;
  console.log('收到 DataChannel:', dataChannel.label);

  dataChannel.onopen = () => {
    console.log('通道已打开');
  };

  dataChannel.onmessage = (event) => {
    console.log('收到消息:', event.data);
    // 回复消息
    dataChannel.send('收到，谢谢！');
  };
};

你看，接收方不需要调用 createDataChannel()，它只需要等着就行。这个设计其实很合理——发起方决定要建几条通道，接收方被动接受。

2.3 配置参数详解

创建 DataChannel 时，第二个参数是个配置对象。我习惯把它叫做「通道的脾气」——你设置什么参数，它就有什么表现。

参数	类型	说明
ordered	boolean	是否保证消息顺序。true 表示按发送顺序到达，false 表示可以乱序
maxPacketLifeTime	number	消息在通道中的最大存活时间（毫秒），超时未送达则丢弃
maxRetransmits	number	最大重传次数，超过次数则丢弃消息
protocol	string	子协议标识，可用于区分不同用途的通道
negotiated	boolean	是否由应用层自行协商通道 ID（高级用法）

2.4 发送和接收数据

DataChannel 支持多种数据类型：字符串、Blob、ArrayBuffer。我个人最常用的是 JSON.stringify 序列化后的字符串，方便解析。

// 发送字符串
dataChannel.send('Hello');

// 发送 JSON 对象
const data = { type: 'chat', content: '你好', timestamp: Date.now() };
dataChannel.send(JSON.stringify(data));

// 发送二进制数据
const buffer = new ArrayBuffer(1024);
dataChannel.send(buffer);

// 发送 Blob
const blob = new Blob(['Hello'], { type: 'text/plain' });
dataChannel.send(blob);

接收消息时，event.data 的类型取决于发送方传的是什么。如果是字符串，它就是字符串；如果是 ArrayBuffer，它就是 ArrayBuffer。我建议在消息里加一个 type 字段，方便接收方判断数据类型。

三、DataChannel 的应用场景

DataChannel 能做的事情，比很多人想象的多。我把它分成三类：实时通信、文件传输、信令复用。

3.1 实时通信场景

这是 DataChannel 最直接的应用。比如在线游戏中的玩家位置同步、动作指令传输。用不可靠模式，延迟可以做到 10ms 以内。

• 在线游戏：玩家位置、状态、操作的实时同步
• 协作编辑：类似 Google Docs，多人同时编辑文档
• 白板共享：笔迹、图形的实时传输
• 远程桌面：鼠标事件、键盘事件的传输

我记得做过一个在线白板项目，用 DataChannel 传输笔迹数据。一开始用的可靠模式，结果画出来的线条有卡顿感。后来换成不可靠模式，延迟降到 5ms 以内，画起来就流畅多了。你想想看，画一笔丢几个点其实没关系，但延迟高了体验就很差。

3.2 文件传输场景

DataChannel 天然支持 P2P 文件传输，不需要经过服务器中转。这对大文件传输特别友好。

• 点对点文件分享：直接在两台设备间传文件
• 屏幕截图/录屏传输：实时分享屏幕内容
• 离线消息同步：用户上线后同步未读消息

这里要注意：DataChannel 的 SCTP 缓冲区默认只有 256KB。如果你一次性发送大量数据，可能会触发背压（backpressure）。我建议用流式传输，边读边发，不要一次性把整个文件加载到内存里。

3.3 信令复用场景

这个用法比较高级，但很实用。既然 DataChannel 已经建立了 P2P 连接，为什么不把信令也走这个通道呢？

• ICE 候选地址交换：通过已有的 DataChannel 交换新的 ICE 候选
• 房间管理：在 P2P 通道内同步房间状态
• 功能协商：动态协商新的媒体流或数据通道

我曾经在一个项目中，用 DataChannel 来传输 ICE 重启的信令。当网络切换时（比如从 WiFi 切到 4G），通过 DataChannel 通知对方重新进行 ICE 连接。这样做的好处是：信令不依赖外部服务器，整个系统更健壮。

这张图展示了 DataChannel 的完整建立流程。从信令交换开始，经过 ICE 连接、DTLS 加密，最后在 SCTP 层建立数据通道。每一步都是环环相扣的，缺一不可。