#1 楼
因为多播是许多接收者的一种来源，所以双向通信（以及任何使用TCP连接的通信）将不起作用。这使得它不适合用于电话会议，在线协作和更多应用程序。流媒体可以工作，但是许多人希望能够暂停流，例如，多播是不可能的。 br />此外，组播的实现非常复杂，尤其是在网络之间。但是，它仅在网络内部使用。我知道，如果激活了诸如时移之类的功能，许多消费者网络都会使用多播为IPTV提供常规单播的后备功能。
评论
谢谢，Teun，这很有帮助。
–Jackaroo Dave
20-09-3在7:14
补充一下：多播没有安全机制。在受控网络之外，它可以轻松地用于DoS攻击-将低带宽数据流放大到极高的总带宽，从而使链路乃至整个网络过载。
– Zac67
20 Sep 3 '20 at 10:18
归根结底，建立和维护组播并非易事。许多工程师几乎没有经验。除了IPv6，我在企业中只见过一次组播路由-几十年前，它是用于视频会议的，是的，它很容易被破坏。 （今天，我读到的最常见的场景是保持音乐和ntp。）
–瑞奇
20年9月3日，14：33
如果在客户端使用较大的缓冲区（可能是磁盘或仅是RAM），则暂停流仍然可以。或者，如果您只是向观看直播的人（或在后面有一个小缓冲区）多播，那么如果其他用户落后于他们愿意缓冲的距离，他们就会退回到个人单播。如果大多数用户正在现场观看，那仍可以在其初次广播期间为一些受到广泛关注的流节省大量核心网络带宽。 （尽管最大的流可能会映射到分布式CDN端点，但无论如何都会减少骨干网流量。）如果支持多播，所有这些都将...
– Peter Cordes
20 Sep 4'10:10
我不知道它是否不可靠，或者我只是不称职，但是我曾经使用多播进行服务发现，并且Windows经常遇到问题，Windows仅在错误的网络设备上侦听和/或其他原因以某种方式杀死了多播订阅。
– AndreKR
20/09/04在10:42
#2 楼
组播在原理上听起来不错，但并不能真正扩展到像互联网这样的网络，这些想法之一。它要求路由器跟踪大量额外状态，具有拒绝服务攻击的巨大潜力，并且从计费角度来看也存在重大问题。结果是ISP通常拒绝多播。多播在您控制的网络中可能是有用的工具。它用于在企业/学术场景中对PC进行重新映像，并用于通过基于IP的“三重播放”提供商分发电视服务，但是如果您想使服务在开放式Internet上运行，则没有用，因为提供商不支持它。
评论
它是在很久以前就设计的，当时没有人需要关心安全性，因为互联网由很少的人组成，而且他们都表现得很好。今天绝对不正确！
–瑞奇
20 Sep 3'19:33
#3 楼
多播曾经是具有以下特征的应用程序的流行选择：具有相似结构但值不同的事件序列，每个新值都替换所有先前的值。没有资源可以缓冲，甚至在事件丢失时也可以通知发布者，您只需要等待下一个事件即可。用于物理事件和股票行情自动收录器的数据记录器将遵循此原则。在金融市场中，大多数多播系统现在都包括一个并行请求-响应系统，用于恢复丢失的事件。
评论
可能是因为它在Internet上不起作用？我总是将流量发送到0.0.0.0/0
@JasonGoemaat不是多播的工作方式
@RonMaupin我可以肯定地说JasonGoemaat在开玩笑。
@JBentley：是的，但是当设置意味着出纳员的意图时，笑话会更有趣。进行某些绝对不是多播的操作（也不是有效的广播目标地址）会使对IPv4足够了解的人感到不那么有趣。在最坏的情况下，错误信息会传播给那些可能在将来某个时候记不清并认为0.0.0.0与多播有关的人。我很高兴罗恩已经指出了它的实际用途。