当发送者需要通过以太网以可靠的方式将相对大量的数据（例如每秒几兆字节）多播到同一子网上的适度数量的接收者（例如少于十二个）时，最有效的协议是什么？可靠是指如果一个数据包丢失，协议会确保它被重新发送，这样任何接收器都不会丢失数据。高效这个词很难定义，但是假设我们想要最大化吞吐量并最小化网络带宽，同时两端的 CPU 使用率适中。这仍然不是一个明确的定义，但这是我能想到的最好的定义。面向流或面向消息的协议都是可以接受的。
我很欣赏现实世界的例子，我很乐意接受主观答案，即你最喜欢的多播协议是什么，如果你能解释它的优缺点的话。
实际示例：TIBCO Rendezvous。
数据通过带有序列号的多播发送出去。检测到丢失序列号的客户端在多播组上发送消息“嘿，我错过了数据包 12345”。服务器重新多播该数据。服务器有一个可配置的数据量来缓冲，以防客户端请求它。
问题：
想象一下，有一个客户端丢弃了一半的数据包，还有 100 个健康的客户端。此客户端为每个其他数据包发送重传请求。服务器开始在其中一个健康的客户端上造成足够的负载，以致它开始丢弃数据包并请求重新传输。额外的负载会导致另一个健康的客户端开始请求重传。等等。拥塞崩溃的结果。
Tibco 提供了一种解决方法，即切断发送过多重传请求的订阅者。这使得单个用户更难导致拥塞崩溃。
限制拥塞崩溃风险的另一种解决方法是限制服务器愿意重新传输的数据量。
Tibco 还应该在客户端和服务器中提供关于是多播还是单播重传请求以及重传本身的启发式方法。他们没有。（对于服务器，如果在某个时间窗口内只有一个客户端请求它，您可以单播重传，对于客户端，如果服务器告诉您 - 在重传的数据包中 - 您是唯一一个请求的客户端，您可以单播重传请求重传并请在将来单播请求）
从根本上说，您必须在您希望保证客户端接收数据的强度与拥塞崩溃的风险之间做出决定。您将不得不猜测数据包被丢弃的位置以及重传是最有效地发送单播还是多播。如果服务器理解数据并且可以决定在无论如何要发送更新的数据时不发送重传（这使得重传无关紧要），那么您比 Tibco RV 等框架处于更好的位置。
有时理解数据会导致错误的假设。例如，市场数据——当有更新的报价时，最初似乎可以不重新传输报价。但稍后，您可能会发现订阅者保留了报价历史记录，而不仅仅是试图跟踪当前报价。也许您可能有不同的要求，具体取决于订阅者，有些客户端会更喜欢单播 TCP 和多播。
在某些时候，您需要在服务器上任意决定要缓冲多少数据，以防重传或客户端缓慢。
继 TIBCO 之后，PGM 协议是一种开放标准的可靠多播，具有许多优化功能，可通过网络元素加速在超大规模上高效工作。PGM 由 TIBCO 和 CISCO 开发，是 TIBCO Rendezvous 下的可选协议，默认协议是 TRDP，在设计上非常相似。
您可以计算理论效率，例如此处列出的 PGM，
http://code.google.com/p/openpgm/wiki/PgmPerformance
不幸的是，现实世界的网络元素、NIC 和通用计算机体系结构的性能远低于理论最大值。
比特流！
不，认真的。您可能想阅读它。
UDP 对多播很有用，但它不能提供您正在寻找的保证 - BitTorrent 将要求您从原始源传输多个完整副本，但它仍然相当有效并提供有用的保证，特别是考虑到多少校验和在传递的每个“块”数据上完成。
我可以建议UFTP 吗？它使用基于 NAK 的机制来确定要重新传输哪些数据包，并且可以选择使用TFMCC进行固定传输速率或拥塞控制。
每个文件都是通过传递发送的，其中第一次传递传输整个文件，而随后的传递只发送重传。每个客户端都会跟踪它收到的数据包和丢失的数据包。在特定的检查点（以及传递结束时），如果接收器自上一个检查点以来错过了任何数据包，它将发送一个 NAK 列出丢失的数据包。这样做的好处是低损耗接收器将在高损耗接收器之前完成。UFTP 也可以配置为丢弃 NAK 百分比超过特定阈值的接收器。
通过将 NAK 限制为仅显示丢失的接收器，它降低了拥塞崩溃的风险，即发送者被接收器反馈淹没。
披露：UFTP 的作者。
如果你真的想要可靠地同时传输到多个客户端，我认为你应该看看流控制传输协议作为 UDP / 多播的替代方案。
这是一个开放的研究问题；有可用的商业解决方案，但价格昂贵。祝你好运。