這是UDP可行性/聲音的擁塞控制方法嗎？

Question

• 發件人發送數據。
• 接收機等待幾秒鐘，然後計算吞吐速率/ s的
• 接收器發送在該其接收數據包（字節/秒），以發送者
• 發件人計算其發送的分組的速率
• 如果速率發送者的速率明顯更高，將其降低到匹配接收速率。

或者，更先進的方法：

• 發件人開始於預定的最小速率（例如1KB /秒。）
• 接收器發送所計算出的接收率回發送者發送。
• 如果接收速率與發送速率相同（考慮到延遲），則按設定的比例增加速率（例如速率* 2）
• 繼續這樣做直到發送速率高於接收速率。
• 如果需要，請繼續監控速率以考慮帶寬增加/減少率的變化。

如果你要實現自己的UDP擁塞控制算法，這個工作可以嗎？

Answer 1

當然，這是可行的。 現在，這會給你預期的結果，還是它的聲音...

我認爲你想解決的問題，已經研究和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流particpants中評[*]。

被警告：

• 這些都是複雜的協議，因爲手頭上的問題確實複雜。

• IIRC，RTCP沒有定義什麼發送方應該做這些QoS報告。它只是將這些報告的排列方式正式化。

[*]：哦，不是真正的enterily自A/V，同步是一個重要的方面（「發送/接收及時」），而你試圖做的是「去儘可能快，但不是太快「。