到目前为止，我们一直在讨论使用 UDP 进行多播传输。这是通常的做法，因为使用 TCP 是不可能实现的。然而，为了开发一些新的多播传输协议，近几年一直在进行深入的研究。
其中一些协议已经被实现并正在测试中。 从中得出的一个重要教训是，似乎没有哪种多播传输协议是通用的，并且足以适用于所有类型的多播应用。
如果传输协议复杂且难以调整，想象一下当接收者不是一个，而是可能是数百或数千个稀疏主机时，处理延迟（在多媒体会议中）、数据丢失、排序、重传、流量和拥塞控制、组管理等等。 这里可扩展性是一个问题，并且实施了新技术，例如不为接收到的每个数据包发送确认，而是为未接收到的数据发送否定确认 (NACK)。 RFC 1458 给出了多播协议的拟议要求。
描述这些多播协议超出了本节的范围。 相反，我将给出其中一些协议的名称，并指出一些信息来源：实时传输协议 (RTP) 关注多方多媒体会议，可扩展可靠多播 (SRM) 由 wb（分布式白板工具，参见 多播应用 章节）使用，统一可靠组通信协议 (URGC) 基于集中控制强制执行可靠和有序的事务，Muse 被开发为特定于应用程序的协议：通过 MBone 多播新闻文章，多播文件传输协议 (MFTP) 本身就非常具有描述性，人们“加入”文件传输（先前已宣布），就像他们加入会议一样，基于日志的接收器可靠多播 (LBRM) 是一种奇特的协议，它跟踪记录服务器中发送的所有数据包，该服务器告诉发送者是否必须重新传输数据或可以安全地丢弃数据，因为所有接收者都已收到它。 一个名字有趣的协议 - 特别是对于多播协议 - 是 STORM (面向结构的弹性多播)。 可以在 Web 上找到大量多播协议，以及一些有趣的论文，这些论文提出了多播的新活动（例如，使用多播的 www 页面分发）。
一个提供可靠多播协议之间比较的优秀页面是
http://www.tascnets.com/mist/doc/mcpCompare.html.
一个非常优秀且最新的站点，包含许多有趣的链接（Internet 草案、RFC、论文、其他站点的链接）是
http://research.ivv.nasa.gov/RMP/links.html.
http://hill.lut.ac.uk/DS-Archive/MTP.html 也是关于该主题的一个很好的信息来源。
Katia Obraczka 的 “多播传输协议：调查与分类” 文章给出了每个协议的简短描述，并尝试根据不同的特征对它们进行分类。 您可以在 1998 年 1 月第 36 卷第 1 期的 IEEE Communications 杂志中阅读它。