您是否遇到过群组或团队通话时某些参与者的音频断断续续或视频出现缓冲的情况？出现这类情况往往是由于网络拥塞造成的。在 WebRTC 中，为解决这些问题，可采用 REMB 和 TWCC 等技术来控制拥塞。
什么是 REMB？
REMB（Receiver Estimated Maximum Bitrate）是一种接收端 WebRTC 技术，可估算带宽（增加或减少）以控制网络或传输拥塞。当传输的数据超过网络带宽时，就会出现传输拥塞，导致延迟和数据丢失。
REMB 在提升 WebRTC 应用的用户体验方面发挥着重要的作用。通过提供网络状况的实时反馈，它能够实现动态比特率自适应。这确保了在当前网络条件下尽可能保持较高的视频质量，同时又不会造成网络负载过大或延迟过高。
在典型的 WebRTC 视频通话中，发送端和接收端都会不断交换 RTCP 数据包以监控服务质量。REMB 在此基础上增加了一个额外的层，包含一个特定的 RTCP 数据包，其中包含接收端预估的最大比特率。该数据包由接收端发送到发送端，允许发送端相应地调整其比特率。
REMB 算法会综合考虑丢包、抖动和网络延迟等各种因素，计算接收端能够处理的最大比特率。计算完成后，该信息会被封装在 RTCP REMB 数据包中，并发送回发送端。
REMB 的优缺点
优点
- 动态码率调整：提示网络问题，并根据网络状况动态调整码率。
- 它通过估计所需的可用带宽来消除网络拥塞。
- 它提高了实时通话中的音频和视频质量。
缺点
- 延迟增加：REMB 的实施可能会增加延迟。
- 实施复杂：由于需要考虑多种网络条件，REMB 架构的实施较为复杂。
值得注意的是，REMB 并非 WebRTC 中唯一的码率自适应机制。TWCC 是另一种被认为更高效、更灵活的机制，尤其是在涉及多路数据流和多变条件的复杂网络场景中。
什么是 TWCC？
TWCC（Transport wide Congestion Control）是一种发送端 WebRTC 方法和带宽估算技术，用于防止网络拥塞（当网络接收的传输数据超过其承载能力时）。TWCC 发生在发送端和接收端之间。发送端的作用是分析从接收端获得的信息，并建议可用带宽。接收端会观察网络是否存在问题，如数据包丢失和传输时间，并通知发送端。
TWCC 的工作原理
在 TWCC 中，接收端会将收到的数据包告知发送端。发送端会根据收到的数据包信息计算比特率，并在数据包上附加时间戳，然后根据网络状况将其传输给接收端。在这种情况下，发送端会决定是否降低或提高比特率以确保数据传输的顺畅。
TWCC 的优缺点
优点：
- 消除音频/视频缓冲：由于 TWCC 会动态调整比特率，因此有助于防止出现缓冲和音频不流畅的情况。
- 准确性：与 REMB 相比，在 TWCC 中，发送端能获得更详细的网络信息。这些详细信息有助于确保更准确的拥塞控制。
缺点：
- 架构复杂度：该流量控制机制的架构相比 REMB 更加复杂。
- 有限的设备支持：TWCC 的解码不支持所有平台。
常见问题
TWCC 与 REMB 有何不同？
它们都是用于防止网络拥塞的技术。REMB 是一种接收端的 WebRTC 技术，而 TWCC 是一种发送端的拥塞控制机制。
TWCC 是 WebRTC 的必要条件吗？
在WebRTC中，TWCC 是可选的。
WebRTC 中 REMB 的替代方案有哪些？
WebRTC 机制传输范围拥塞控制（TWCC）可作为 REMB 的替代选项。
REMB 的动态带宽调整如何工作？
REMB利用网络状况动态计算带宽。
后记：了解更多 QOS 技术来提升音视频通话质量，如抗丢包策略(ACK、FEC)、流控(带宽估计和拥塞控制)、自适应策略、以及抗抖动等，欢迎联系我们👇 或注册即可免费体验 ZEGO 领先的实时音视频服务，为您的应用扩展提供更多可能性。
