1.3 IP多播的缺点
IP多播网络的设计与部署（第1卷）
1.3 IP多播的缺点
尽管在网络中使用IP多播有许多很好的理由，但是需要记住，该技术也存在缺陷和不利的方面。读者需要清楚地理解IP多播的这些缺陷，尤其是在开发计划使用IP多播的新应用时，更要考虑这些缺陷。
与IP多播系统的实施相关的某些主要缺陷包括不可靠的包交付、包复制和网络拥塞。
1.3.1 不可靠的信息包交付
IP多播和IP单播一样，都是天生不可靠的。只有在第4层使用TCP（或其他更高层协议），IP单播数据流才能成为可靠的。然而，由于IP多播采取的是一对多的通信模式，因此不能使用TCP固有的端到端机制。IP多播数据包典型地使用用户数据报协议（UDP），而UDP本质上是尽力而为的协议。因此，使用IP多播的应用必须指望数据报丢失只是偶尔发生，并且做好要么接受这种丢失行为，要么在应用层或借助于UPD之上的可靠多播协议来处理该丢失行为的准备。
Deering博士在他的博士论文中提到，“在拓扑结构发生改变时，路径也立刻随之改变，在此期间，还在传输行程的多播数据包到达其目的地的概率要低于单播数据包”。Deering进一步解释，在网络变化期间，即使网络中某些路由器上存在有不正确的单播转发信息，但是网络或许最后仍然可以成功地把数据包转发到目的地。这种情况发生的原因是，在网络拓扑发生转变的同时，尽管实际的传输路径可能出现环路，但是单播转发机制仍然试图转发数据包到其目的IP地址。从另一方面来说，IP多播的转发机制是基于源IP地址的。为了预防环路，如果数据包没有到达可能会返回源的接口，将被丢弃。Deering博士的观点的意义存在有一定的争议，尤其是因为该观点的影响还没有被研究。然而，从表面来看，这一观点仍然值得注意。
如果此时读者对前面的资料不明白，不必担心；第2章将会更详细地讲解这些转发机制。现在，只要理解IP多播转发机制使用的是源IP地址，而IP单播转发使用的目的IP地址，这就足够了。
1.3.2 数据包复制
如同在UDP单播世界中一样，复制数据包已经成为一个不争的事实。然而，单播路由和多播路由之间的一个关键区别是，路由器有意地发送多播数据包的多个副本到多个接口。这增加了多播数据包的多个副本到达接收端的可能性。例如，在某个冗余网络拓扑中，有多条路径可以到达接收端，在多播路由协议聚合（converge）并消除冗余路径之前，将发生复制数据包的情况。这意味着，尽管在网络发生错误的短暂瞬间，许多数据包副本可能会到达接收端，但是只有偶发的数据包在网络内部被复制（在第4章中学习不同的多播路由协议时，将会对何时、何处发生数据包复制有一个更好的理解）。设计良好的IP多播应用应该可以检测和处理偶发复制数据包的到来。
注意
在一个特定场合，作者记得有一家美国政府机构设计了一个IP多播应用来控制政府设备的关键部件。而政府设备的关键部件一旦出现故障，则可能会导致生命丧失。不幸的是，该应用设计人员却不能解释由正常的IP多播操作所引起的复制数据包的可能性。该疏忽导致IP多播数据包中的关键控制命令被多次执行。
试想一下，如果这样的一个应用程序用来指挥和控制战场上的许多坦克：“所有坦克向右转90°”，“所有坦克向右转90°”，“所有坦克向右转90°”……
1.3.3 网络阻塞
在TCP单播情况下，标准的TCP回退（backoff）和慢启动（slow-start）窗口机制可以自动调整数据发送的速度，因此在网络内提供了一定程度的拥塞避免。因为IP多播不能使用TCP（因为IP多播是无连接的，而且还是一对多的），所以不它不存在内置的阻塞避免机制，来防止多播流耗尽链路带宽或者其他关键的路由器资源。之前已经说过，UDP单播数据流也遭受到相同的拥塞避免问题。而且，多媒体音频和视频应用近期在Internet和私有内部网上的增长也造成了UDP单播流量的增加。
随着你对IP多播工作机制的了解，就会发现，没有什么规定可以阻止你加入到一个多播组中，即使该多播组发送数据的速率已经超过了你的网络可以使用的最大带宽。
图1-6所示为两个IP多播服务器正在发送相同的视频内容。一个服务器以500kbit/s的速率发送节目，旨在供本地企业总部网络环境使用，而另外一个服务器以128kbit/s的速率发送节目，旨在供远程销售办公室使用。
如果远程销售办公室的一个用户错误地加入到了500kbit/s的多播组，将导致通往远程销售办公室的256kbit/s的电路被这500kbit/s的视频多播流完全耗尽。
在第16章，你将学习到通过对256kbit/s的电路进行配置，来限制多播流消耗带宽的方法。另一种方法是使用管理性作用域的边界（administratively scoped boundaries）来防止远程办公室的用户加入到500kbit/s的组中（管理性作用域地址和边界将在第2章讲解）。
综上所述，可以注意到，IP多播不逊于当今使用的许多普通的音频/视频流应用。这些音频/视频流应用默认使用单播UDP而不是TCP作为他们的按发送机制，这意味着它们与其他使用IP多播作为发送机制的应用一样，也不使用任何形式的拥塞控制！
注意
网络设计人员经常告诉我，由于IP多播基于UDP的发送机制天生缺乏拥塞控制，因此他们没有打算在网络中实施IP多播。事实的真相是，他们的用户很可能使用基于UDP的单播应用建立了流视频Web服务器，来提供部门培训的视频剪辑片段或其他类似的材料，而且该单播应用和IP多播一样没有拥塞控制功能。另一方面，IP多播通过发起一个多播视频流（而不是多个单播流）而降低了网络总负载。
一些应用默认不使用TCP的原因是，音频的实时特性使得TCP的重传机制没有任何价值。在重传的数据包到达时，它为时已晚，因此在音频流中也不再有用。相反，应用设计人员宁愿降低数据传输质量，以达到网络允许的最快速率（以可能出现的网络拥塞为代价），也不愿意用内置在TCP中的拥塞避免机制来对传输的数据进行人工限制。在大多数情况下，使用IP多播将会降低网络整体的拥塞，这是因为一个单一的传输数据流可以到达所有的接收点。
注意
在MBone的早期，音频会议工具VAT（它当然是基于UDP的）是其上的主要应用。在音频会议中，通常是在开始任何会话之前，首先通过麦克风清几下嗓子。这使得任何活跃的TCP流在流经网络中潜在的拥塞点时，会引起它的拥塞机制启动并发挥作用，因此这为基于UDP的音频会议流赋予了更多带宽。可能有人会说，这是资源预留原始形式的第一次尝试，它是用过初始的Ahem数据包建立的（下面将会详细介绍MBone）。