6.3 数据通道 DataChannel

6.3 数据通道 DataChannel

加密管道建好之后，除了音视频，应用常常还想直接互传结构化数据：状态同步、控制指令、白笔轨迹、文件分片。数据通道就是为这类需求准备的：它复用已建立的连接与加密设施，按需提供从"必达且有序"到"尽力而为"的多种投递语义。本节讲它的建通流程、语义选择与背压控制。

建通流程与可靠性语义

数据通道架在流式传输控制协议之上，而这层协议又复用媒体的安全管道——建连、加密、密钥，一切沿用，数据通道只多一步应用级的开门握手：一端发送"开一条通道、参数如下"的控制消息，对端收到后回敬确认，双方的应用层同时得到"通道可用了"的事件。协商阶段看到的数据通道媒体段落，就是为这层协议预留的位置。

可靠性语义在开门时就要定好，三选一。可靠有序：像 TCP 一样不丢不乱，代价是队头阻塞——前面丢的包没补上，后面全等着，实时性场景要慎用。不可靠但限次数或限时：每条消息允许重传若干次，或在若干秒后放弃，适合"过期作废"的状态类消息——位置同步、实时计数，旧消息丢了就丢了，新的马上就来。完全尽力：发出去就不管，适合高频低价值的遥测。语义按通道粒度设定，一条连接可以并存多条不同语义的通道，按业务拆分即可。

// 不可靠、限时五百毫秒的通道：适合实时状态同步
DataChannelInit init;
init.ordered = false;
init.maxPacketLifeTime = 500;
auto ch = pc->CreateDataChannel("state", &init);
​

状态推进上，通道从连接中经开门到开放，应用可写；任一侧关闭后进入关闭中，最终到已关闭。引擎对半开状态有明确处理：对端关闭后本端再发送，会得到明确的失败而非静默丢弃——应用层应当把这个失败当作"对端已离开"的信号处理。

背压：发大文件必过的一关

数据通道的发送是异步的：应用把字节递给引擎，引擎先放进发送缓冲排队，再按线路情况逐包送出。线路慢于发送速度时，缓冲持续堆积——内存膨胀、消息延迟飙升、时间敏感的消息全部失真。所以引擎提供发送缓冲量的查询与阈值回调：缓冲超过高水位时暂停投递，低于低水位时恢复。正确的大流量发送循环一定是"投递、查水位、挂起、等回调、续投"的节奏，而不是无脑灌。

错误处理与生命周期同步

通道的另一端是网络与对端应用，失败是常态而非例外，把错误处理收拢成几条纪律。发送失败的语义：缓冲满时的失败是"暂时"的，退避重试即可；通道关闭后的失败是"永久"的，应当清理会话状态。两者混为一谈是数据通道 bug 的第一大来源——把暂时失败当永久，会话提前散场；把永久失败当暂时，应用在幽灵通道上空转。关闭的双向性：本端发起关闭后，应等待对端的关闭确认再释放资源，立刻释放会让对端最后的在途消息落在已释放的接收地上。对端离开的感知：连接层的状态回调与通道的关闭事件要综合判断——连接层报断开时，所有通道随之失效，不应再逐条等待各自的关闭流程。

把语义选择与错误纪律组合起来，可以得到一个实用的设计模板：控制类消息走可靠有序通道、配最大重试与超时兜底；状态类消息走限时限次通道、过期即弃；两端各自实现"通道健康度"的汇总视图——通道失败率、缓冲水位、在途消息年龄三个指标汇总，任何一项越界就把业务层置于降级模式。这个模板让数据通道的使用从"能用"升级到"可运维"，也是互动类产品稳定性的分水岭。

多条通道共用一条连接，会互相拖慢吗

会，且这正是设计约束的来源。所有通道共享同一条加密管道与发送缓冲，一条通道灌满缓冲，其余通道的延迟同步上升。所以"按业务拆通道"不等于"互相隔离"，水位治理必须面向连接总量，高流量通道要单独限速。

通道的建立顺序有保证吗

开门握手按发送顺序处理，先创建的通道先开放。但应用层不应依赖这个顺序表达业务语义——"先开控制通道再开数据通道"的隐式约定在重连与并发场景下会破，显式的就绪事件才是可靠的同步点。

能否在通话中动态改可靠性语义

不能。语义在开门时定死，改语义等于开新通道。需要"从可靠切不可靠"的业务（比如从指令阶段切到高频状态阶段）应在设计期就拆成两条通道，按阶段启用。

案例：一次文件传输卡死的背压复盘

背景。接入方用数据通道做会议资料分发，反馈大文件传到中途必然卡死，小文件无恙；换更快网络反而更容易复现，团队百思不解。

操作。复现时监控发送缓冲水位与通道吞吐。日志显示：投递速率远高于线路消化速率，缓冲一路上涨到上百兆；同时应用层在缓冲堆积后仍按固定速率投递，直到某次投递报"缓冲已满"错误，应用未处理该错误，循环空转，表现为卡死。换快网络更易复现的原因也清楚了：快网络上文件"显得能传"，业务把更大的文件放进来，堆积更快。

结果。改造发送循环：投递分片改为按窗口推进，缓冲超过高水位即挂起，收到低水位回调再续传；满缓冲错误改为退避重试。改造后百兆文件稳定传完，速率自动贴合线路能力。

解读。这个案例是背压纪律的教科书形态：数据通道的发送接口从来不是"无限快的队列"，投递速率必须由反馈驱动。缓冲突灾是应用层缺陷，引擎只是如实报告。顺带一提，文件类需求应同时启用分片校验与断点续传设计——通道只保证字节送达，文件完整性是应用层的责任。

变式。互动白板类场景的正确姿势则相反：用限次限时的不可靠通道发笔迹增量，丢一笔只是少一段轨迹，绝不因补传造成迟滞；而投票、答题结果走可靠有序。同一产品里按消息价值拆通道，是数据通道设计的核心功夫。

要点回顾

本节要点：数据通道复用媒体的安全管道，开门握手后可用；可靠性语义三选一，按消息价值拆分通道；队头阻塞是可靠有序模式的隐性代价；发送必须有水位控制，灌队列是卡死与延迟的总根源；对端离开要靠发送失败与关闭事件感知。下一章进入服务质量：带宽从哪来、丢了怎么办、分配给谁。