多播

动机：多播

到目前为止，在我们讨论的每个主题中，我们都提到互联网的目标是在主机之间传输数据。具体来说，我们假设的是单播传输，即存在一个单一的源，向单一的目的地发送数据。

我们见过的许多协议（例如 HTTP、DNS、TCP、TLS）都依赖于客户端 - 服务器模型，而这种模型又依赖于单播传输模式。在客户端 - 服务器模型中，有一个客户端和一个服务器在交换数据，这意味着它们之间发送的是单播数据。

互联网上的大多数流量确实是单播，但也有一些例外。特别是，有些应用涉及到主机组之间的通信。例如，考虑多人游戏、实时内容分发应用（如 Zoom 会议、体育赛事直播）或协作文档（如谷歌文档）。组通信还有一些更特殊的用途，比如设备发现（例如，向所有苹果设备发送消息以找到最近的扬声器），或者 AI 训练（我们将在本笔记的后续部分学习）。

客户端 - 服务器范式并不是思考这些场景的最自然方式。在多人游戏或视频会议应用中，并没有单一的客户端或单一的服务器。网络应该如何支持这些应用，以便开发者更轻松地编写这类应用呢？

这个问题的一个可能答案是：网络根本不需要提供任何支持。组通信可以用单播来实现。例如，当你更新协作文档时，你可以向组内的其他每个人发送单独的单播数据包，这样他们都能知道你的更新。

然而，这种仅使用单播的方法可能效率很低。考虑这样一种网络拓扑：你在美国，而组内的其他所有成员都在欧洲。如果你向每个组成员发送单独的单播数据包，你就是在通过昂贵的海底光缆发送重复的数据副本。此外，这会迫使发送者发送许多重复的单播数据包，扩展性很差（例如，想象一个服务器向数百万用户流式传输体育赛事）。

直观地说，一种更自然的方法是只通过海底光缆发送一个数据包，然后让欧洲的某个设备（例如路由器或主机）将数据包的副本分发给组成员。理想情况下，我们希望避免沿着一条链路发送数据包的重复副本。换句话说，每条链路应该只传输一次该数据包（如果该链路沿线没有组成员，则可能零次）。

这种方法需要网络提供额外的支持，并且需要开发一些新的协议。

多播定义

回顾一下，到目前为止我们已经见过四种数据包传输模式：

单播：将数据包发送到恰好一个目的地。

任播：将数据包发送到一组可能的目的地中的任意一个。只需该组中的一个成员接收数据包即可。

广播：将数据包发送到所有目的地。“所有” 的定义取决于具体问题的上下文，但你可以理解为本地网络中的所有主机。

多播：将数据包发送到组内的所有成员。主机可以随时选择加入 / 离开组。请注意，即使你自己不是某个组的成员，也可以向该组发送数据包。

多播范式可以用来解决前面提到的组通信问题。例如，所有有兴趣接收体育赛事直播的主机可以加入一个多播组。然后，流媒体服务可以向整个组多播数据包。

再举一个例子，如果我们想使用多播进行设备发现，可以让大楼里的所有打印机加入一个多播组。然后，用户可以向整个组多播数据包，以找到他们可以使用的打印机。

IP 多播与覆盖多播

在多播的发展历史中，一个长期存在的争论是一个架构问题：我们应该在哪个层实现多播？

一种选择是在第三层实现多播，有时称为IP 多播。在这种方法中，我们为路由器添加专门的支持，使它们能够理解如何进行多播。这种选择能提供更好的性能，但实现起来更困难。

另一种选择是在第七层实现多播，有时称为覆盖多播。在这种方法中，由应用程序处理所有多播功能。这种选择不会改动第三层，因此路由器只需要理解单播即可。这种选择性能较差，但实现起来更简单。

这两种选择都不是绝对更好的。我们将研究这两种选择，并分析它们之间的权衡。

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