问题是服务器正在为一个multicast组服务UDP. 假设它是一个文件服务器，它将提供大文件（~10GB）。现在我们有一个包含多个客户端的多播组。其中一些客户端具有非常好的带宽，例如 1Gbps，而其他客户端只有 100Mbps。我们可以假设该比率为 1:1（各占 50%）。现在我们希望通过多播将文件传递给每个用户，但我们也不希望将最高速度限制为等于多播组中最慢的接收者。我们希望每个用户都能以尽可能快的速度获取文件。例如，100Mbps 的用户将以 100Mbps 的速度获得它，而 1Gbps 的用户将以 1Gbps 的速度获得它。如果我们以 1Gbps 的速度从服务端发送流量，那么 100Mbps 的客户端将超载并且他们将丢弃他们的数据包，因为他们无法处理这个速度。如果我们以 100Mbps 传输，那么我们将 1Gbps 的客户端限制为仅 100Mbps。
这里的想法是不要从多播组中删除用户，同时还要为每个客户端实现最大可能的速度。
首先一个警告：
组播（相对于所有基于 UDP 的传输）本身没有流量控制，没有拥塞避免机制，没有重新传输丢失数据包的方法，也没有固有的接收缓冲区缩放，正如 TCP 提供的那样。交付大文件（约 10GB）可能需要其中一些机制，以确保最终文件在远程端是完整且未损坏的。
使用多播，应用程序必须补偿许多他们不必关心的事情，如果传输是使用 TCP 完成的。
现在来看看实际答案：
覆盖不同接收器的不同带宽：对于每个带宽级别，使用单独的组播组并相应地调整发送速率。
另外：请务必检查接收器是否能够摄取、检查、重新排序（和写入磁盘）如此大的 UDP 流量流。请记住：UDP 没有 TCP 所具有的“本机”接收缓冲区缩放。不止一次（我承认：过去）我已经看到 IP 堆栈以大约 130Mbit/s 的 UDP 流量摆脱困境，但能够泵送 >800Mbit/s 的 TCP。
最后：
使用多播以比特完整、无损和可靠的方式传递数据是昂贵的（在编程/应用程序设计和网络基础设施方面）。如果这些是要求，您应该确保使用基于单播和 TCP 的精心设计的解决方案（可能在客户端附近使用一些预加载的缓存服务器）无法实现相同的目标。多播适用于金融市场数据、视频流、音频流，其中偶尔丢失的数据包“同样好”，可能由接收器上的视频/音频编解码器补偿。
[1] 例如：通过一个网络路径发送具有一个 mcast 组地址“A”的相同流，以及通过不同的网络路径发送具有 mcast 组地址“B”的相同流（可能需要非常高级的多播路由设置）。在应用程序级别，数据包或数据块按顺序编号并校验和。接收者订阅这两个组，摄取两个流，并在将一个好块写入磁盘之前对接收到的所有数据块进行逻辑比较。
[2] 其他可能性：使用单个组（每个带宽类），每个块被多播 3 次。Receiver 有足够的临时存储空间来接收每个块 3 次，并在逻辑上组合一个好的块写入磁盘。
[3] 第三种可能性：由于无论如何都应该对块进行编号/校验和，因此客户端可以检测到丢失/不完整/损坏的块并通过单播重新请求它们；当然，这需要服务器上的服务和接收器上的单播客户端，并且需要正确准备要发送的数据（分段成适当大小的块、序列编号、校验和）。