RTCDataChannel bufferedAmount 怎样控制发送背压

RTCDataChannel 做持续发送时，真正要控制的不是“调用了多少次 send()”，而是发送端还积压了多少字节。send() 返回并不代表远端已经收到；它通常只是把消息交给浏览器的发送缓冲。让 bufferedAmount 无限增长，最终会把内存、延迟和消息失败一起推向危险边界。

实用做法是设置一个高水位：达到高水位就暂停生产；再用 bufferedAmountLowThreshold 设置低水位，等 bufferedamountlow 事件到来后继续发送。下面只讨论这个背压闭环，不展开信令服务器和 ICE 建连。

官方文档地址：https://developer.mozilla.org/en-US/docs/Web/API/RTCDataChannel/bufferedAmountLowThreshold

先区分发送成功与进入缓冲区

bufferedAmount 表示当前已经交给数据通道、但仍在发送端排队的字节量。它会随着浏览器实际发送而下降；这个数值不是远端应用的确认计数，也不等价于“网络上已经到达”。因此，上传文件或批量推送时，不能只看循环是否结束。

我会把发送端的主要风险看成三个层次：待发送数据本身、RTCDataChannel 的缓冲，以及网络链路之后的远端处理。前两层可以由发送端直接控制，远端是否及时消费则要通过协议确认或业务应答处理，不能用 bufferedAmount 冒充业务 ACK。

建立高水位与低水位边界

一个稳定的发送器通常同时使用两个阈值。高水位决定何时停止继续塞数据；低水位决定何时允许恢复。bufferedAmountLowThreshold 的默认值是 0，如果不主动设置，缓冲量下降到零才可能触发低水位事件，恢复会偏慢。

阈值不是越大越好。高水位太大，会换取吞吐却增加内存和排队延迟；低水位太小，恢复频繁且不容易形成连续发送。可以先使用“高水位约 1 MiB、低水位约 256 KiB”的示例值，再根据消息大小、链路和业务延迟目标调整。这个数字是工程起点，不是浏览器规定的固定上限。

把背压接入分片发送器

关键是不要在一个 for 循环里无条件调用 send()。每个分片发送前先看高水位；超过高水位就等待低水位事件。事件可能在等待期间已经发生，所以等待函数必须先检查一次当前值，避免错过事件后永久挂起。

function createBackpressuredSender(channel) {
  const HIGH_WATER = 1024 * 1024;
  const LOW_WATER = 256 * 1024;
  // 低水位事件只负责通知恢复，真正的上限仍由发送前检查保证
  channel.bufferedAmountLowThreshold = LOW_WATER;

  function waitForLowWater() {
    return new Promise((resolve, reject) => {
      if (channel.readyState !== "open") {
        reject(new Error("数据通道未处于 open 状态"));
        return;
      }
      // 已经降到低水位时直接继续，避免等待一个已经发生的事件
      if (channel.bufferedAmount  {
        channel.removeEventListener("bufferedamountlow", onLow);
        resolve();
      };
      channel.addEventListener("bufferedamountlow", onLow, { once: true });
      channel.addEventListener("close", () => {
        channel.removeEventListener("bufferedamountlow", onLow);
        reject(new Error("等待低水位时数据通道已关闭"));
      }, { once: true });
    });
  }

  async function sendChunk(chunk) {
    if (channel.readyState !== "open") {
      throw new Error("发送前数据通道已经关闭");
    }
    // 高水位暂停生产，避免把整份文件一次性压进发送缓冲
    if (channel.bufferedAmount >= HIGH_WATER) {
      await waitForLowWater();
    }
    try {
      // chunk 可以是字符串、ArrayBuffer 或 Blob，具体类型由协议约定
      channel.send(chunk);
    } catch (error) {
      // send 可能因状态变化或消息过大失败，交给上层决定重试或终止
      throw new Error(`数据通道发送失败：${error.message}`);
    }
  }

  return { sendChunk };
}

这个封装有两个容易被忽略的点。第一，低水位事件只说明缓冲量已经下降到阈值附近，不能代替远端确认；第二，监听器要在恢复后移除，否则每次发送都会增加一个旧监听器。常驻连接还应在外层统一处理 error、closing 和 close，把等待中的任务置为失败或取消。

处理关闭、错误和消息大小

背压解决的是发送端排队问题，不会自动解决协议可靠性。发送大文件时，应先切成适度大小的分片，并在消息中携带序号、总量或结束标记；远端需要确认时，再设计应用层 ACK。不要把一个超大字符串交给 send()，因为对端和浏览器对单条消息可接受大小都有边界，未协商的消息大小也存在默认限制。

连接进入 closing 或 closed 后，新的发送应立即停止。若发送器只等待 bufferedamountlow，而通道已经关闭，就可能一直等不到恢复事件，所以前面的等待逻辑还要监听关闭并拒绝 Promise。若业务允许恢复，重连后应新建通道和新队列，不要复用旧通道的缓冲量。

最后把背压当成资源保护措施，而不是性能保证。它能限制发送端的瞬时积压，却不能替代网络拥塞控制、远端消费速度和应用层完整性协议。先让队列有上限，再根据真实业务指标调整水位，通常比盲目把阈值调大更稳妥。

bufferedAmount 变小就代表对方收到了吗？

不代表。它只反映本地发送缓冲的排队状态；要确认业务数据到达，需要远端回传序号或 ACK。

为什么设置了 bufferedAmountLowThreshold 仍不恢复？

可能是等待开始前事件已经发生，也可能通道已经关闭。等待函数应先检查当前 bufferedAmount，并在关闭或错误时结束等待。

高水位应该设置成多少？

没有适用于所有链路的固定值。可以从 1 MiB 高水位和 256 KiB 低水位开始，结合分片大小、内存压力、延迟和失败率调整。

参考：MDN bufferedAmountLowThreshold、MDN Using WebRTC data channels、MDN RTCDataChannel.send()。