用 RFC-8260 解决 WebRTC 数据通道的队头阻塞问题
内容提要
WebRTC数据通道基于SCTP，大消息分片会独占发送队列，造成队头阻塞，使聊天、控制等小消息延迟，丢包重传时更严重。RFC 8260的I-DATA交织将TSN职责拆分，新增MID和FSN用于分片重组，TSN仍负责可靠性与重传，使不同流的分片可交错发送。配合轮询、优先级或加权公平队列调度器，可显著缓解阻塞。Pion 4.2.13起默认启用交织并支持自定义调度器。
延伸解读
交织不解决带宽与拥塞，只改变排队顺序
文章明确指出，RFC 8260 的交织不会让丢包消失，也不会为每条流提供独立拥塞窗口或凭空增加带宽。它只是让其他流的分片能在大消息分片之间获得发送机会。因此，在丢包严重的网络中，重传仍会消耗容量，但不再必须把所有流堵在大消息的串行化之后。读者应把交织视为缓解队头阻塞的调度手段，而非网络质量问题的根治方案。
调度策略决定谁受保护，WFQ 与优先级各有适用场景
交织赋予 SCTP 从不同流中挑选 chunk 的能力，但下一条该轮到哪条流仍需策略决定。文章列出轮询、优先级和加权公平队列三种常见策略：轮询让每条非空流轮流获得机会；优先级让高优先级流先被服务；WFQ 按可配置权重分配容量，权重为 n 倍的流应获得 n 倍容量。对队头阻塞敏感的应用，可将 I-DATA 交织与 WFQ 或优先级调度组合使用。
启用前需确认对端协商，Pion 默认开启但未必生效
Pion 4.2.13 及以上版本默认启用交织，但文章强调，除非对端也支持并在握手期间完成协商，否则交织不会被真正使用。当前 Firefox 默认启用，Chrome 则位于开关之后。开发者可通过 Pion 的 GetStats() 查看 SCTPTransportStats 元数据中的 messageInterleavingEnabled 字段，确认当前流是否实际启用了交织，避免误以为默认开启就一定生效。
Q&A
WebRTC数据通道为什么会出现队头阻塞？
因为SCTP按发送顺序调度消息，大消息会被分片并独占发送队列，导致小消息（如聊天、控制）必须等待大消息的所有分片发送完毕。如果发生丢包，大分片的重传会进一步延迟其他流。
RFC 8260 的 I-DATA 交织是如何解决队头阻塞的？
I-DATA 将 TSN 的职责拆分：TSN 仍负责可靠性、SACK 和重传，但分片重组改用 MID（消息标识符）和 FSN（分片序列号）。这样不同流的分片可以交错发送，无需占用连续的 TSN 范围，从而避免大消息阻塞其他流。
启用交织后，丢包时还会发生阻塞吗？
交织不会消除丢包或增加带宽，但能让其他流的分片在大消息分片之间获得发送机会。重传仍会消耗容量，但不再必须等待所有大消息分片发送完毕，因此其他流的延迟会显著降低。
SCTP 流调度器有哪些常见策略？
常见策略包括轮询（round-robin）、优先级（priority）和加权公平队列（WFQ）。轮询让每条非空流轮流发送；优先级让高优先级流先被服务；WFQ 根据每条流的权重分配容量，权重高的流获得更多带宽。
如何在 Pion 中启用交织并自定义调度器？
Pion 4.2.13 及以上版本默认启用交织，无需额外配置。你可以通过 WithInterleavingWeightedFairqueuingWeight 自定义 WFQ 权重，或通过 WithInterleavingRoundRobinScheduler 启用轮询调度器，甚至实现 InterleavingStreamScheduler 接口来定义自己的调度器。
如何检查当前 SCTP 流是否启用了交织？
可以通过 Pion 的 GetStats() 获取 SCTPTransportStats，检查 Metadata.MessageInterleavingEnabled 字段。该字段为 true 表示交织已启用。此外，Metadata 还包含部分可靠性模式等信息。
