SCTP 流控与拥塞控制 · 数据通道的发多快
SCTP 也要管「发多快」——流控（rwnd）防止压垮接收方，拥塞控制（cwnd）防止压垮网络。这一章讲清 SCTP 这套类 TCP 的机制、它和媒体侧 GoogCC 拥塞控制的关系，以及数据通道为什么需要独立的一套。
SCTP 流控与拥塞控制 · 数据通道的发多快
媒体侧有 GoogCC 管发多快，数据通道也得管——它走 SCTP，而 SCTP 自带一套流控 + 拥塞控制（类似 TCP）。这一章看它，以及它和媒体拥塞控制的关系。
两个“别发太多”：流控 vs 拥塞控制
和 TCP 一样，SCTP 要防两种“压垮”：
流控（flow control）防止压垮接收方**，拥塞控制（congestion control）防止压垮网络——两个正交的约束。**
- 流控（rwnd） —— 接收方在 SACK 里通告自己还能收多少（接收窗口 a_rwnd）。发送方不能发超过这个量——别把接收方的缓冲塞爆（接收方处理不过来就丢）。这是“照顾对端”。
- 拥塞控制（cwnd） —— 发送方维护一个拥塞窗口 cwnd，估计“网络当前能承受多少”，别超过——别把网络的缓冲塞爆（bufferbloat）。这是“照顾网络”。
发送方实际能发的 = min（rwnd， cwnd）——两个约束里更紧的那个说了算（和媒体拥塞控制取小、拥塞窗口一个道理）。这个“流控 + 拥塞控制”的双约束，是可靠传输协议（TCP、SCTP）的标配。
SCTP 拥塞控制：类 TCP
SCTP 的拥塞控制，基本照搬了 TCP 的经典机制：
- 慢启动（slow start） —— 连接初期 cwnd 从小开始，每收到 SACK 就指数增长，快速探到大致带宽（比媒体的 AIMD 加性增快）。
- 拥塞避免（congestion avoidance） —— 到一定阈值后转为线性增长（加性增），谨慎试探。
- 丢包即减 —— 检测到丢包（缺 TSN）就大幅降 cwnd（乘性减），快速让出拥塞。
这就是经典的 AIMD + 慢启动——和 TCP、以及媒体侧 GoogCC 的 AIMD 同源。dcSCTP 的 net/dcsctp/tx/（如 retransmission_queue 里的拥塞控制逻辑）实现它。SCTP 拥塞控制主要看丢包（不像媒体 GoogCC 主要看延迟）——因为数据通道多是可靠传输，丢包信号明确。
和媒体拥塞控制的关系
一个微妙的问题：一次通话里，媒体走 GoogCC、数据通道走 SCTP 自己的拥塞控制，它们共用一条底层传输——会不会打架？
媒体（GoogCC）和数据通道（SCTP CC）是两套独立的拥塞控制**，跑在同一条传输上——这确实需要协调，否则两者会抢带宽。** WebRTC 的做法：数据通道的 SCTP 流量也要经过媒体侧的 pacer / 拥塞控制统一调度（数据通道的发送最终也受总带宽预算约束），让两者不至于各发各的、加起来压垮网络。理想情况下，音视频优先（实时性强），数据通道用剩余带宽（它多能容忍延迟）。
这是一个“多套控制器共享一条链路”的协调问题——不完美，但通过统一的发送调度让它们大体和谐。数据通道的存在，让 WebRTC 的拥塞控制比纯媒体的更复杂一层——因为多了一个“性格不同”（可靠、能忍延迟）的流量要照顾。
小结与下一章
SCTP 也管“发多快”：流控（rwnd） 防压垮接收方（接收方 SACK 通告窗口）、拥塞控制（cwnd） 防压垮网络（bufferbloat），发送量取 min（rwnd， cwnd）。拥塞控制类 TCP：慢启动（指数）→ 拥塞避免（线性）→ 丢包乘性减（AIMD，主要看丢包）。它和媒体 GoogCC 是两套独立控制器共享一条传输，靠统一发送调度协调（媒体优先、数据用余量）。
最后两块：SCTP 的多流、以及数据通道怎么建立（DCEP）。下一章先讲多流。👉 SCTP 流。
参考资料
- [1] libwebrtc 源码.
net/dcsctp/tx/（cwnd、慢启动）、net/dcsctp/rx/（rwnd 通告）。 - [2] IETF RFC 9260「SCTP」§ 6-7（流控与拥塞控制）。
- [3] 关联媒体拥塞控制 GoogCC、pacing。