-1
  • 发送者发送数据。
  • Receiver 等待几秒钟，然后计算吞吐率 / s
  • 接收方将其接收数据包的速率（字节/秒）发送给发送方
  • 发送方计算其发送数据包的速率
  • 如果发送方的速率明显更高，则降低它以匹配接收速率。

或者，更高级的方法：

  • 发件人以预定义的最小速率（例如 1kb / s）开始发送
  • 接收方将计算的接收率发送回发送方。
  • 如果接收速率与发送速率相同（考虑延迟），则将速率增加一个设定的 pct（例如 rate * 2）
  • 继续这样做，直到发送速率高于接收速率。
  • 如果需要，请继续监控速率以考虑带宽增加/降低速率的变化。

如果您要实现自己的 UDP 拥塞控制算法，这是否可行？

4

1 回答 1

0

当然，这是可行的。现在，这会给你预期的结果，还是听起来……

我认为您正在尝试解决一个由 IETF 非常聪明的人研究和标准化的问题。我建议您看一下位于 UDP 之上的 RTP/RTCP，是否只是为了了解为什么这是一个棘手的问题并抓住一些想法。

https://en.wikipedia.org/wiki/RTP_Control_Protocol

“RTCP 的主要功能是通过定期向流式多媒体会话中的参与者发送统计信息来提供有关媒体分发中服务质量 (QoS) 的反馈。”

https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

我认为它的主要用例是音频/视频流这一事实并不那么重要：RTCP 的重点是在参与者之间提供有关 UDP 数据流的反馈[*]。

请注意：

  • 这些是复杂的协议，因为手头的问题确实很复杂。

  • IIRC，RTCP 没有定义发送方应该如何处理这些 QoS 报告。它只是形式化了这些报告从一边到另一边交换的方式。

[*]：嗯，不是完全正确，因为在 A/V 中，同步是一个重要方面（“及时发送/接收”），而您要做的是“尽可能快，但不太快”。

于 2015-08-31T09:21:33.483 回答