IP 多播的挑战

域间路由

到目前为止，我们介绍的协议（IGMP、DVMRP、CBT）可用于域内多播路由。然而，它们很难扩展到域间多播路由。

这里的一个主要问题是可扩展性。例如，如果我们在全球范围内使用 DVMRP，那么定期地，当剪枝状态被删除时，数据包将泛洪到整个互联网，这是不切实际的。

此外，回想一下，域间路由带来了自治系统（AS）自主性和隐私的额外挑战。例如，如果我们在全球范围内使用 CBT，那么核心路由器可能位于不同的网络中，这就要求你信任其他人来控制核心路由器。

域间多播路由是一个难题，人们已经做了大量工作来开发解决方案。例如，CBT 核心选择问题可以通过设置多个核心（每个网络一个）并让它们进行通信来解决。然而，在实践中，域间多播路由的采用率非常低。

计费

IP 多播服务模型与现代互联网服务提供商（ISP）采用的商业模式存在根本冲突。例如，考虑这个自治系统图，其中 AS A 和 AS B 是对等体：

作为对等体，AS A 和 AS B 应该能够交换等量的流量，但多播使得定义什么是 “等量流量” 变得困难。举个例子，假设 AS A 向 AS B 发送一个多播数据包。AS B 可能有许多属于该组的子节点，这意味着 AS B 接收了一个数据包，却需要发送出多个数据包。在这里，AS B 使用的带宽比 AS A 多得多。那么 AS A 是否需要因为这个原因向 AS B 支付额外费用呢？（这是一个悬而未决的问题，没有明确答案。）

再举一个例子，考虑这个自治系统图，其中 AS A 是提供商，AS B 是客户：

AS B 向 AS A 支付服务费用。如果 AS B 发送一个多播数据包，而 AS A 必须将该数据包的副本转发到许多其他目的地，那么 AS A 应该对这个数据包收取比单播数据包更高的费用吗？如果是的话，应该多收多少呢？（这也是一个悬而未决的问题，没有明确答案。）

IP 多播模型没有明确记录组的大小，这使得设计商业模式变得更加困难。如果你想根据目标组的大小向用户收费，那么没有明确的方法来确定任何给定目标组的大小。你的转发表会告诉你在不同的分发树上的父节点和子节点，但这些表不会告诉你总共有多少终端主机将接收这个数据包。

拥塞控制

考虑一个源向分发树下方的许多接收者发送多播数据包。源需要选择一个合适的发送速率以避免网络过载。那么源应该选择什么速率呢？

流量将沿着许多不同的路径传输，每条路径可能有不同的容量。源可以以 1 Mbps 的速率发送，以避免任何链路过载，但这会导致其他路径的容量未被充分利用。另一方面，源可以以 100 Mbps 的速率发送以最大化性能，但这会导致一些链路过载。对于源应该选择什么速率，没有明确的答案。

在实践中，一个可能的解决方案是根据性能定义不同的组。例如，我们可以定义四个不同的多播组，每个组接收相同的视频流，但视频质量不同。然后，任何感兴趣的接收者都可以尝试加入不同的组，看看哪个组能提供最佳性能。

可靠性

与 IP 单播一样，IP 多播是尽力而为的，这带来了一些额外的复杂性。例如，你可能发送了一个数据包，它可能到达了一些组成员，但没有到达所有组成员。

我们可以尝试添加确认（ACK）来解决这个问题，但这也可能存在问题。如果组有数百万成员，单个发送者将无法处理每个数据包的数百万个确认。

另一种可能的方法是使用否定确认（NACK），即组成员在收到数据包时不发送任何信息，而在未收到数据包时（例如，其计时器到期）发送否定确认。同样，如果组有数百万成员，单个发送者可能会不堪重负。

在否定确认方法中，如何从故障中恢复也不明确。如果有人没有收到数据包，我们是否要向整个组重新多播该数据包？这会浪费带宽，因为一些组成员已经收到了该数据包，将会收到重复的副本。

另一种方法是仅向发送否定确认的组成员单播该数据包。如果许多组成员没有收到该数据包，这可能会很浪费，因为我们必须单播同一个数据包的多个副本。例如，考虑第一个链路就丢失了数据包的情况，这意味着没有任何组成员收到该数据包。

哪种重传方法更好呢？这并不明显，它可能取决于有多少组成员收到了数据包。

在实践中，一些现代的 IP 多播应用根本不实现可靠性。或者，它们通过在数据流中编码一些冗余（例如，纠错码）来实现可靠性，这样就可以从数据本身纠正丢失和损坏，而无需网络的帮助。

编码冗余意味着需要更多的比特来编码相同的数据。例如，如果你想发送相当于 5 个数据包的数据，你可能会发送 10 个数据包，并以这样的方式编码比特：任何 5 个数据包都可以用来重建原始数据。

安全性

IP 多播的另一个局限性是缺乏访问控制。任何人都可以加入一个组，任何人都可以向任何组发送消息。如果你想实施访问控制（例如，只有付费用户才能观看体育比赛），你必须单独构建该功能。

缺乏访问控制会导致安全漏洞。恶意发送者可以向特定的多播组泛洪数据包，导致该组的所有成员都不堪重负。请注意，这比单播的情况更有效，在单播中，恶意发送者必须分别向每个成员泛洪数据包。

额外的安全措施（如加密）也难以实施。假设你通过向每个组成员提供一个共享密钥来加密多播消息。如果有人离开了组怎么办？如果继续使用相同的密钥，该用户仍然知道这个密钥，并且可以读取你的消息。一种方法是切换到使用新的密钥，但现在你需要一种方法将这个新密钥安全地分发给剩余的组成员。

实际应用中的 IP 多播

由于所有这些挑战，IP 多播如今主要在单个域内使用，而不是在不同域之间使用。

一些应用可能仍然需要跨多个网络的组通信（例如，多人游戏、视频会议）。许多应用没有依赖不支持跨网络通信的 IP 多播，而是为组通信实现了自己的自定义解决方案。

例如，如果组足够小，应用可以实现一个中央中继服务器。组通信被单播到中央中继服务器，然后中继服务器再将消息单播到其他组成员。

或者，如果组足够小，基于单播的简单解决方案（向每个组成员发送单独的单播数据包）可能就足够了。

如果 IP 多播不能跨域工作，而自定义解决方案需要额外的工作来实现和扩展，那么现代应用如何处理组通信呢？一种解决方案是使用覆盖多播，它是 IP 多播的替代方案，在七层而不是三层实现网络功能。接下来我们将研究覆盖多播。

（注：文档部分内容可能由 AI 生成）