SCTP 部分可靠 · 可靠性可调的杀手锏

有些数据“过期作废”——实时游戏的玩家位置、视频会议的某些控制信令，旧的丢了不该重传（重传回来时它已经被更新的取代了，浪费带宽还添延迟）。部分可靠让你说“这条数据，重传几次 / 多久内还有效，过了就放弃”。 想象传玩家坐标，每 50ms 一次：如果第 1 帧的坐标丢了，你根本不想重传它——因为第 2、3 帧的新坐标早就来了，重传旧坐标毫无意义。TCP 却会死磕着重传那个旧坐标、还队头阻塞后面的新坐标——对实时数据是灾难。

部分可靠给了精确的中间档：

• maxRetransmits —— 最多重传 N 次，还没成功就放弃（N=0 就是“尽力而为”，像 UDP）。
• maxPacketLifeTime —— 数据在 T 毫秒内才值得重传，超时就放弃。

这两个旋钮（映射自数据通道的配置），让你按数据的时效性精确选择可靠程度——传文件用完全可靠、传实时位置用不可靠、传偶尔重要的用“重传几次”。一条 association 里，不同流可以有不同的可靠性设置，各取所需。

发送方放弃某些 TSN 后，发一个 FORWARD-TSN 告诉接收方“这些 TSN 我不发了，你别等了，把累积确认点往前移”——接收方于是跳过这些放弃的块，继续处理后面的。 这就解开了死锁：没有 FORWARD-TSN，接收方会永远等那个被放弃的 TSN，后面的数据全卡住；有了它，接收方知道“这几个号作废了”，累积点前移，数据流继续。

FORWARD-TSN 是部分可靠的关键机制——它让“放弃某些数据”这件事，能被双方一致地处理，不至于一方放弃、另一方傻等。dcSCTP 的 net/dcsctp/tx/ 在放弃块时生成 FORWARD-TSN，rx/ 处理它并前移接收窗口。这个“显式告知放弃、让对方跳过”的设计，是“优雅地丢弃”在传输层的体现：不是悄悄不发（那会卡死对方），而是明确协商放弃。

SCTP 部分可靠的价值，是一个协议覆盖整个谱系**——你不必在“TCP 太死板”和“UDP 太原始”之间二选一，而能为每种数据精确调档。** 一次通话里：传文件的数据通道用完全可靠有序（像 TCP）、传实时光标的用不可靠无序（像 UDP）、传偶尔重要状态的用“重传 2 次”（中间档）——它们复用同一个 association、同一条加密通路，各按自己的时效性选可靠度。这种灵活，是 TCP/UDP 都给不了的，也是 WebRTC 数据通道能力的根基。