如何在使用UDP时避免拥塞？

Question

我理解TCP是如何做到这一点的--通过各种方法，比如拥塞窗口(CWND)、滑动窗口、慢启动和快速恢复--它基本上是内置在协议中的。据我所知，当沿着路径进行成形或MSS夹紧时，TCP可以相应地调整其段大小和传输速率。

我还理解QUIC (它运行在UDP上)实现了自己版本的丢失检测和拥塞控制。QUIC有点像一个为HTTP3构建的高调优、低延迟、更可扩展的TCP版本，但它也可以传输任何其他应用程序数据。

然而，我不清楚不使用QUIC的应用程序如何确定：

• 一次可以发送多少个UDP数据报？
• 每个UDP数据报可以有多大(如果PMTUD由于ICMP答复被中间框禁用/阻塞而无法工作)

我还不清楚UDP作为一种最有效的协议，如何不只是淹没发送方和接收方之间的链接/路径，从而导致严重的数据包丢失。

或者换一种方式:需要发送大量数据的应用程序如何静态或动态地确定发送方和接收方之间路径上的可用带宽，并相应地调整其数据报大小和传输速率？

据我所知，RTP有一些类似于RTCP的功能，允许它限制/增加流量或更改编解码器以减少/增加数据包大小，以进行质量控制。使用UDP运行Iperf测试时，可以使用"-b“属性设置可用带宽。使用UDP的DNS和DHCP具有相对较小的数据报大小，并且只会重试直到收到响应或超时为止。

*根据我目前的理解，答案将是:如果应用程序需要发送/接收大量数据(例如备份或高清晰度流)，那么应用程序将只被设计为使用TCP，而只是不使用UDP，除非它还具有支持RTCP之类的带外协议，或者可以确定可用带宽(例如，由用户设置的带宽，如Iperf)。

Answer 1

除了Steffen清晰的回答之外，也许更直接的回答是：

应用程序如何确定：

• 一次可以发送多少个UDP数据报？

他们不能。IP和UDP都没有提供任何机制来确定这一点。主机可以在其接口(S)允许的任何情况下发送UDP数据报。只要OS的堆栈能够缓冲发送请求，应用程序就可以超过该速率。

一般情况下，利用UDP网络带宽的应用程序需要在应用层实现某种拥塞控制。

• 每个UDP数据报可以有多大(如果PMTUD由于ICMP答复被中间框禁用/阻塞而无法工作)

使用碎片，应用程序可以将UDP数据报发送到封装IP数据包的最大大小(64 KiB)。

如果没有碎片，也没有来自网络或目标的反馈，应用程序只能猜测。对于IPv4，最小保证的IP片段大小只有68个字节(详细的这里)。对于IPv6，是1280字节。

Answer 2

UDP不提供任何拥塞控制，控制数据包丢失，复制，重新排序.。所有这些都必须在应用程序级别上实现，并且每个协议可能根据应用程序的特定需求以不同的方式处理这一问题。

例如，对于RTP (实时音频或视频)，重新发送数据包根本没有任何帮助，因为对于用户体验来说，分组以低延迟到达是至关重要的。因此，应用程序的设计使得数据包之间不太依赖，这样就可以在数据包丢失时简单地继续。如果检测到太多的数据包丢失(通过RTCP)，可能只需切换到不同的编解码器或视频大小，从而减少带宽。

其他基于UDP的协议有不同的需求，比如SIP或DNS，如果它们在一段时间后没有得到预期的响应，只需重新传输请求。VPN与UDP上的IPSec、Wireguard或OpenVPN一样，只是忽略了任何丢包，因为它们提供的隧道并不是用户所期望的可靠的。

如果您需要可靠的数据传输，并以最佳的方式使用可用带宽，那么使用TCP或具有内置拥塞控制(如QUIC )的通用协议。