8、数据传输：DataChannel配置、可靠与不可靠模式、文件传输实战

聊到WebRTC的数据传输，很多人第一反应是音视频。其实DataChannel才是真正的“瑞士军刀”。它让你在P2P连接上跑任意数据，文本、二进制、文件流，统统不在话下。我个人习惯把DataChannel看作是一条“隐形的高速公路”——不占用媒体带宽，却能做到低延迟、高吞吐。

这一节，我们就把DataChannel的配置、可靠/不可靠模式，以及文件传输实战，一次性讲透。

8.1 DataChannel 的核心概念

DataChannel基于SCTP协议（流控制传输协议）运行在DTLS之上。说白了，它是在加密的P2P通道上再开一条数据隧道。你想想看，音视频走的是RTP，数据走的是SCTP，两者互不干扰。

创建DataChannel有两种方式：

  • 带内创建：通过信令通道协商，在offer/answer中声明DataChannel。
  • 带外创建：直接在PeerConnection上调用createDataChannel()，然后通过ICE连接自动建立。

我在项目中遇到过一种情况：带内创建时信令延迟较高，导致DataChannel迟迟无法打开。后来改用带外创建，配合重试机制，问题就解决了。嗯，这里要注意：带外创建虽然灵活，但需要确保两端都调用了createDataChannel()，否则通道不会建立。

8.2 DataChannel 配置详解

创建DataChannel时，可以传入一个配置对象。这个对象决定了通道的行为。我建议你仔细看下面这张表，它几乎涵盖了所有关键参数。

参数 类型 说明 默认值
ordered boolean 是否保证消息顺序到达 true
maxPacketLifeTime number 消息在通道中存活的最大毫秒数（不可靠模式） null
maxRetransmits number 消息最大重传次数（不可靠模式） null
protocol string 子协议标识，可用于自定义协议 ""
negotiated boolean 是否由应用层协商ID false
id number 通道ID，当negotiated为true时必须指定 自动分配

核心要点：ordered、maxPacketLifeTime、maxRetransmits 这三个参数决定了通道的可靠性模式。其他参数一般用默认值就够了。

8.3 可靠模式 vs 不可靠模式

这是DataChannel最让人纠结的地方。选错了模式，要么数据丢得乱七八糟，要么延迟高得离谱。我刚开始做的时候也踩过坑，后来总结了一套选择逻辑。

可靠模式（Reliable）

配置方式：ordered: true，不设置maxPacketLifeTime和maxRetransmits。

特点：消息100%到达，顺序严格保证。底层SCTP会重传丢失的数据包，直到对方确认收到。

适用场景：文件传输、聊天消息、游戏状态同步（对顺序敏感）。

我的经验：可靠模式在弱网环境下会明显增加延迟。我曾经在3G网络下测试，一个1MB的文件传输耗时超过30秒。如果你对实时性要求高，慎用。

不可靠模式（Unreliable）

配置方式：设置maxPacketLifeTime或maxRetransmits，或两者都设置。

特点：消息可能丢失，顺序可能乱。但延迟极低，适合实时性要求高的场景。

有两种子模式：

  • 部分可靠（时间限制）：设置maxPacketLifeTime，比如3000毫秒。消息如果在3秒内没送达，直接丢弃。
  • 部分可靠（次数限制）：设置maxRetransmits，比如3次。重传3次还没成功，放弃。

你想想看，游戏中的玩家位置更新，每秒发30次。丢一两次根本无所谓，但延迟必须低。这时候用不可靠模式就对了。

注意：maxPacketLifeTime和maxRetransmits不能同时设置为非null值。SCTP协议规定两者互斥，否则会抛出异常。我曾经踩过这个坑，调试了半天才发现是配置冲突。

8.4 知识体系图：DataChannel 模式选择

下面这张图帮你理清思路。从应用场景出发，一步步选择正确的配置。

DataChannel 模式选择决策树 应用场景 需要可靠性？ 需要低延迟？ 可靠模式 ordered: true maxPacketLifeTime: null, maxRetransmits: null 不可靠模式 时间限制 maxPacketLifeTime: 3000 次数限制 maxRetransmits: 3 提示：两种不可靠子模式不能同时设置，SCTP协议规定互斥 起点 决策 模式 配置

8.5 文件传输实战

理论讲完了，咱们直接上代码。文件传输是DataChannel最典型的应用之一。我会用JavaScript演示，但核心逻辑在移动端（Android/iOS）上完全通用。

8.5.1 创建DataChannel

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

// 创建DataChannel - 可靠模式，用于文件传输
const fileChannel = pc.createDataChannel('file-transfer', {
  ordered: true,
  // 不设置maxPacketLifeTime和maxRetransmits，即为可靠模式
});

// 监听通道状态
fileChannel.onopen = () => {
  console.log('DataChannel 已打开');
  // 可以开始传输文件了
};

fileChannel.onclose = () => {
  console.log('DataChannel 已关闭');
};

fileChannel.onerror = (err) => {
  console.error('DataChannel 错误:', err);
};

小技巧：通道名称file-transfer可以自定义，但两端必须一致。如果你用negotiated: true，还需要手动指定相同的id。

8.5.2 发送文件

文件传输的关键在于分片。WebRTC的DataChannel单条消息大小有限制（通常16KB-64KB，取决于浏览器和平台）。所以大文件必须切成小块发送。

async function sendFile(file, channel) {
  const chunkSize = 16 * 1024; // 16KB 分片
  let offset = 0;

  // 先发送文件元信息
  const meta = {
    name: file.name,
    size: file.size,
    type: file.type,
    totalChunks: Math.ceil(file.size / chunkSize)
  };
  channel.send(JSON.stringify(meta));

  // 等待接收端确认
  await new Promise(resolve => {
    channel.onmessage = (e) => {
      if (e.data === 'ready') resolve();
    };
  });

  // 逐片发送
  while (offset < file.size) {
    const chunk = file.slice(offset, offset + chunkSize);
    channel.send(chunk);
    offset += chunkSize;

    // 可选：报告进度
    const progress = Math.min(100, (offset / file.size) * 100);
    console.log(`发送进度: ${progress.toFixed(1)}%`);
  }

  console.log('文件发送完成');
}

注意：channel.send()在数据量过大时可能抛出BufferFullException。我建议在发送每个分片前检查channel.bufferedAmount，如果超过阈值（比如1MB），就等待bufferedamountlow事件触发再继续。否则移动端很容易OOM。

8.5.3 接收文件

let receivedChunks = [];
let fileMeta = null;

channel.onmessage = (e) => {
  // 第一个消息是元信息
  if (!fileMeta) {
    fileMeta = JSON.parse(e.data);
    console.log(`接收文件: ${fileMeta.name}, 大小: ${fileMeta.size} bytes`);
    channel.send('ready'); // 通知发送端可以开始了
    return;
  }

  // 后续消息是文件分片
  receivedChunks.push(e.data);

  // 检查是否接收完毕
  if (receivedChunks.length === fileMeta.totalChunks) {
    // 合并分片
    const blob = new Blob(receivedChunks, { type: fileMeta.type });
    
    // 在移动端，这里可以保存到本地文件系统
    // 或者通过URL.createObjectURL()生成下载链接
    const url = URL.createObjectURL(blob);
    console.log(`文件接收完成: ${url}`);

    // 清理
    receivedChunks = [];
    fileMeta = null;
  }
};

8.5.4 移动端适配要点

在移动端（Android/iOS）做文件传输，有几个坑需要避开：

  • 内存管理：移动端内存有限，大文件分片不要全部保存在内存中。建议边接收边写入临时文件。
  • 后台传输：App进入后台后，DataChannel可能被系统挂起。iOS上需要开启后台模式，Android上可以使用Foreground Service。
  • 网络切换：WiFi切4G时，ICE连接会重建。DataChannel需要重新打开。我建议在oniceconnectionstatechange中监听，状态变为disconnected时暂停传输，恢复后继续。

实战建议：文件传输最好加上断点续传功能。每次发送分片时，记录已发送的偏移量。接收端也记录已接收的分片索引。连接断开后，从断点处继续，而不是重新传整个文件。这个功能我在一个医疗影像传输项目中实现过，效果非常好。

8.6 性能调优

DataChannel的性能受多个因素影响。我总结了几条调优经验：

  • 分片大小：16KB-64KB是黄金区间。太小了协议头开销大，太大了容易触发流控。
  • 并发发送：不要一次性把所有分片都塞进发送队列。控制bufferedAmount在2MB以内，超过就等待。
  • SCTP缓冲区：部分平台允许调整SCTP接收缓冲区大小。Android上可以通过PeerConnectionParameters设置，iOS上使用RTCDataChannelConfiguration。
  • 压缩：文本数据可以先用gzip压缩再发送。我在项目中测试过，JSON数据压缩后体积减少60%以上。

嗯，最后说一句。DataChannel的潜力远不止文件传输。游戏帧同步、实时白板、IoT设备控制……只要你敢想，它就能做。关键是理解可靠与不可靠模式的取舍，以及做好分片和流控。

这一节的内容就到这里。记住，动手实践是最好的学习方式。打开你的IDE，写一个文件传输的Demo，你会对DataChannel有更深的理解。

公众号:蓝海资料掘金营，微信deep3321

← 上一章 📖 返回目录 下一章 →