# SCTP 流控与拥塞控制 · 数据通道的发多快

> SCTP 也要管「发多快」——流控（rwnd）防止压垮接收方，拥塞控制（cwnd）防止压垮网络。这一章讲清 SCTP 这套类 TCP 的机制、它和媒体侧 GoogCC 拥塞控制的关系，以及数据通道为什么需要独立的一套。

- 作者：David（道雾轩）
- 专栏：音视频与 WebRTC 详解（https://daiw.org/manual/webrtc.md）
- 最后更新：2026-09-13
- 原文：https://daiw.org/manual/webrtc/sctp-flow-congestion
- 转载与引用：请注明出处并附原文链接（https://daiw.org/about/copyright）

# SCTP 流控与拥塞控制 · 数据通道的发多快

[媒体侧有 GoogCC 管发多快](https://daiw.org/manual/webrtc/congestion-control-overview)，数据通道也得管——它走 [SCTP](https://daiw.org/manual/webrtc/data-channel-overview)，而 SCTP 自带一套**流控 + 拥塞控制**（类似 TCP）。这一章看它，以及它和媒体拥塞控制的关系。

## 两个“别发太多”：流控 vs 拥塞控制

和 TCP 一样，SCTP 要防两种“压垮”：

<Callout type="info">
  **流控（flow control）防止压垮**接收方**，拥塞控制（congestion control）防止压垮**网络**——两个正交的约束。**

  - **流控（rwnd）** —— 接收方在 [SACK](https://daiw.org/manual/webrtc/sctp-reliability) 里**通告**自己还能收多少（接收窗口 a_rwnd）。发送方不能发超过这个量——**别把接收方的缓冲塞爆**（[接收方处理不过来就丢](https://daiw.org/manual/webrtc/neteq-overview)）。这是“照顾对端”。
  - **拥塞控制（cwnd）** —— 发送方维护一个拥塞窗口 cwnd，估计“网络当前能承受多少”，别超过——**别把网络的缓冲塞爆**（[bufferbloat](https://daiw.org/manual/webrtc/congestion-window)）。这是“照顾网络”。

  发送方实际能发的 = **min（rwnd， cwnd）**——两个约束里更紧的那个说了算（和[媒体拥塞控制取小](https://daiw.org/manual/webrtc/loss-based-bwe)、[拥塞窗口](https://daiw.org/manual/webrtc/congestion-window)一个道理）。这个“流控 + 拥塞控制”的双约束，是可靠传输协议（TCP、SCTP）的标配。
</Callout>

## SCTP 拥塞控制：类 TCP

SCTP 的拥塞控制，基本照搬了 [TCP 的经典机制](https://daiw.org/manual/webrtc/delay-based-bwe)：

- **慢启动（slow start）** —— 连接初期 cwnd 从小开始，每收到 [SACK](https://daiw.org/manual/webrtc/sctp-reliability) 就**指数增长**，快速探到大致带宽（比[媒体的 AIMD 加性增](https://daiw.org/manual/webrtc/delay-based-bwe)快）。
- **拥塞避免（congestion avoidance）** —— 到一定阈值后转为**线性增长**（[加性增](https://daiw.org/manual/webrtc/delay-based-bwe)），谨慎试探。
- **丢包即减** —— 检测到[丢包（缺 TSN）](https://daiw.org/manual/webrtc/sctp-reliability)就**大幅降 cwnd**（[乘性减](https://daiw.org/manual/webrtc/delay-based-bwe)），快速让出拥塞。

这就是经典的 **AIMD + 慢启动**——和 [TCP、以及媒体侧 GoogCC 的 AIMD](https://daiw.org/manual/webrtc/delay-based-bwe) 同源。dcSCTP 的 `net/dcsctp/tx/`（如 `retransmission_queue` 里的拥塞控制逻辑）实现它。SCTP 拥塞控制主要**看丢包**（[不像媒体 GoogCC 主要看延迟](https://daiw.org/manual/webrtc/delay-based-bwe)）——因为数据通道多是[可靠传输](https://daiw.org/manual/webrtc/sctp-reliability)，丢包信号明确。

## 和媒体拥塞控制的关系

一个微妙的问题：一次通话里，[媒体走 GoogCC](https://daiw.org/manual/webrtc/congestion-control-overview)、[数据通道走 SCTP 自己的拥塞控制](https://daiw.org/manual/webrtc/sctp-flow-congestion)，它们[共用一条底层传输](https://daiw.org/manual/webrtc/jsep-transport-controller)——会不会打架？

<Callout type="info">
  **媒体（[GoogCC](https://daiw.org/manual/webrtc/congestion-control-overview)）和数据通道（[SCTP CC](https://daiw.org/manual/webrtc/sctp-flow-congestion)）是**两套独立的拥塞控制**，跑在[同一条传输](https://daiw.org/manual/webrtc/jsep-transport-controller)上——这确实需要协调，否则两者会抢带宽。** WebRTC 的做法：数据通道的 [SCTP 流量](https://daiw.org/manual/webrtc/data-channel-overview)也要经过[媒体侧的 pacer / 拥塞控制](https://daiw.org/manual/webrtc/pacing)统一调度（数据通道的发送最终也受[总带宽预算](https://daiw.org/manual/webrtc/rate-control)约束），让两者不至于各发各的、加起来压垮网络。理想情况下，音视频优先（[实时性强](https://daiw.org/manual/webrtc/video-bitrate-allocation)），数据通道用剩余带宽（它多能[容忍延迟](https://daiw.org/manual/webrtc/sctp-partial-reliability)）。

  这是一个“[多套控制器共享一条链路](https://daiw.org/manual/webrtc/congestion-window)”的协调问题——不完美，但通过统一的[发送调度](https://daiw.org/manual/webrtc/pacing)让它们大体和谐。**数据通道的存在，让 WebRTC 的拥塞控制比纯媒体的更复杂一层**——因为多了一个“性格不同”（可靠、能忍延迟）的流量要照顾。
</Callout>

## 小结与下一章

SCTP 也管“发多快”：**流控（rwnd）** 防压垮[接收方](https://daiw.org/manual/webrtc/neteq-overview)（接收方 [SACK](https://daiw.org/manual/webrtc/sctp-reliability) 通告窗口）、**拥塞控制（cwnd）** 防压垮网络（[bufferbloat](https://daiw.org/manual/webrtc/congestion-window)），发送量取 **min（rwnd， cwnd）**。拥塞控制类 TCP：**慢启动（指数）→ 拥塞避免（线性）→ 丢包乘性减**（[AIMD](https://daiw.org/manual/webrtc/delay-based-bwe)，主要看丢包）。它和[媒体 GoogCC](https://daiw.org/manual/webrtc/congestion-control-overview) 是**两套独立控制器共享[一条传输](https://daiw.org/manual/webrtc/jsep-transport-controller)**，靠统一[发送调度](https://daiw.org/manual/webrtc/pacing)协调（媒体优先、数据用余量）。

最后两块：SCTP 的**多流**、以及数据通道**怎么建立（DCEP）**。下一章先讲多流。👉 [SCTP 流](https://daiw.org/manual/webrtc/sctp-streams)。

## 参考资料

- [1] libwebrtc 源码.`net/dcsctp/tx/`（cwnd、慢启动）、`net/dcsctp/rx/`（rwnd 通告）。
- [2] IETF RFC 9260「SCTP」§ 6-7（流控与拥塞控制）。
- [3] 关联[媒体拥塞控制 GoogCC](https://daiw.org/manual/webrtc/congestion-control-overview)、[pacing](https://daiw.org/manual/webrtc/pacing)。