在软件的上下文中，背压是指系统为“推回”下行力量而采取的行动。因此，就是系统在受到胁迫，或在总调用模式表现出过多峰值，或过于突发时，单方面采取的一种防御性行动。
这种方法通常用于微服务基础设施，但我们不会在实时通信平台的上下文中过多讨论它，即使它们对于处理负载峰值同样重要，同时将服务质量保持在合理的范围内。在峰值或突发时，质量可能会略有下降，但它应该仍然可用并且服务器永远不会停机。
处理背压，以免受那些不可持续流量模式影响的方法有这几种：缓冲、丢弃和控制发件人。
- 缓冲：消息可以在需要时以较低的速率排队和处理，以限制峰值或高负载的影响。
- 丢弃：当无法足够快地处理消息甚至连接时，它们可能会被丢弃。如果客户端重试，这可能会产生问题，因为它可能会产生乘法效应，使问题变得更糟，因此必须谨慎应用。
- 控制发送方：接收方可以向发送方提供一些反馈，以限制其发送的流量，从而暂时降低对服务质量的影响。
信令平面和媒体平面通常用于构成RTC平台，下面来介绍上述方法应用于这两种平面的思路和影响。
信令平面
通常我们使用websocket连接来发送和接收与会话建立有关的信息，以及一些状态类型和消息传递。鉴于它是一种持久的TCP连接，所以我们其实已经免费获得了一些缓冲。作为操作系统实现的一部分，它可以解决一些流量高峰带来的问题。但除此之外，在连接和房间/会话级别上有一个更严格的缓冲会方便不少。这样可以避免在一个房间流量意外激增的情况下，单个房间让整个服务器的负担过重的情况。
丢弃信息在信令平面中并不常见。考虑到我们不希望丢失关键信息，万不得已不会选择丢弃操作。但在某些特定情况下，比如遥测信息或屏幕共享时发送光标位置，这不失为一种合理选择。
控制发送者可以明确进行（向客户端发送反馈信息，建议客户端通过增加一些批处理，或减少视频数量来发送更少量信息），也可以从缓冲区以较慢速度读取隐秘进行，这样客户端的相应缓冲区也会被填满。
媒体平面
当你运行媒体服务器时，会有一些默认的缓冲区存在，它们属于操作系统套接字实现的一部分。这些缓冲区的大小供你随意调整，帮你灵活处理峰值，用延迟换取丢包。传统用例中，你可能不会扩大缓冲区；但那些高比特率用例中，关键帧可能真的很大（例如类似Stadia的那些用例），可能会需要扩大缓冲区。这些缓冲区是处理小型峰值的第一道防线。但也不能滥用它们，因为缓冲区会增加媒体数据包的延迟和抖动。
丢弃信息也不失为一种选择。但一旦已经读取了这些信息，可节省的资源就变少了，因为会触发重传（至少在视频方面是这样）。所以与其丢弃数据包，不如禁用特定视频层的转发以减少数据包数量；或者在音频里启用动态dtx（即不连续传输）或增加ptime。
控制发送者应该是媒体计划中最常见的技术。有两种方法：一是在需要时配置较低的发送比特率（例如使用RTCP REMB消息）来明确控制发送者，二是隐秘地进行控制。在第二种情况中，如果媒体服务器开始过载，数据包的处理时间就不好预测了，这就会引入一些抖动。抖动是一种拥堵的信号，所以带宽估计也会降低。这在大多数现有RTC解决方案中是自动发生的。解决方案包括基于数据包延迟变化的带宽估计算法，例如WebRTC用例。
原文：https://www.rtcbits.com/2022/01/back-pressure-in-rtc-services.html
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/26579.html
