我正在为大学考试做准备，去年的问题之一是"如何使UDP多播可靠"(例如tcp，重传丢失的数据包)

我想到了这样的事情：

服务器使用UDP发送多播

每个客户端发送确认接收到的数据包(使用TCP)

如果服务器意识到不是每个人都接收到数据包，它将向特定客户端重新发送多播或单播

问题是可能有一个客户端通常丢失数据包并迫使服务器重新发送。

好吗 ？

Every client send acknowledgement of receiving that packets ( using TCP )

对于每个数据包发送ACK并使用TCP进行发送，无法扩展到大量接收器。使用基于NACK的方案更为有效。

从服务器发送的每个数据包都应具有与其关联的序列号。当客户收到它们时，他们会跟踪丢失了哪些序列号。如果丢失了数据包，则可以通过UDP将NACK消息发送回服务器。此NACK可以格式化为序列号列表或已接收/未接收到的序列号的位图。

If server realize that not everyone receive packets , it resends multicast or unicast to particular client

当服务器收到NACK时，它不应立即重新发送丢失的数据包，而应等待一段时间，通常是GRTT的倍数(组往返时间-接收器组中最大的往返时间)。这使它有时间积累来自其他接收器的NACK。然后，服务器可以多播丢失的数据包，以便任何丢失它们的客户端都可以接收它们。

如果此方案用于文件传输而不是流数据，则服务器可以轮流交替发送文件数据。完整文件在第一遍发送，在此过程中，将累计接收到的所有NACK，并标记需要重新发送的数据包。然后，在随后的遍历中，仅发送重传。这样做的好处是，丢失率较低的客户端将有机会完成文件的接收，而丢失率较高的接收者可以继续接收重传。

The problem are that there might be one client who usually lost packets and force server to resend.

对于损失非常高的客户端，服务器可以为丢失的最大数据包百分比设置阈值。如果客户端发回超过该阈值的NACK一次或多次(取决于服务器的次数)，则服务器可以丢弃该客户端，并且不接受其NACK或向该客户端发送消息以通知它掉了。

有许多协议可以实现这些功能：

相关RFC：

为了使UDP可靠，您必须处理一些事情(即，自己实现)。

连接处理：发送和接收过程之间的连接可能会断开。最可靠的实现通常会发送keep-Alive消息以维护两端之间的连接。

排序：消息在发送之前需要分成多个块。

确认：收到每个消息后，需要将ACK消息发送到发送过程。这些ACK消息也可以通过UDP发送，而不必通过UDP。接收过程可能意识到丢失了一条消息。在这种情况下，它将停止从保留队列(保留接收到的消息的消息队列，就像消息的等待室)中传递消息，并请求重新发送丢失的消息。

流控制：根据接收过程传递数据的能力来限制数据的发送。

通常，有一组流程的负责人。这些小组中的每个小组通常都有领导者和整个小组的观点。这称为虚拟同步。