IGMP协议详解（转载）
摘要：文章来自《TCP/IP详解》卷第13章。 本文详细介绍IGMP协议的原理和实现实例。
1、引言
本文介绍了支持主机和路由器多播的互联网组管理协议(IGMP )。 使物理网络上的所有系统知道主机当前所属的多播组。 多播路由器需要这些信息才能知道传输多播数据报的接口。 IGMP在RFC 1112中定义[删除输入1989 ]。
像ICMP一样，IGMP也被视为IP层的一部分。 IGMP消息通过IP数据报传输。 与我们已经看到的其他协议不同，IGMP有固定的消息长度，没有可选数据。 图13-1显示了IGMP消息如何封装在IP数据报中。
互联网组管理协议(igmp )消息和协议(图1 ) )。
IGMP消息指示IP报头中的协议字段的值为2。
2、 IGMP报文
图1 3 - 2显示了长8字节的IGMP消息格式。
互联网组管理协议(igmp )消息和协议(图2 ) )。
这在版本1的IGMP.IGMP类型为1时是来自多播路由器的询问消息，在版本2时是来自主机的报告消息。 和检查的计算与ICMP协议相同。
组地址是d类的IP地址。 在查询消息中将组地址设定为0，在报告消息中将组地址设为参加的组地址。 在下一节中，我们将详细介绍IGMP如何工作。
3、 IGMP 协议
3.1 加入一个多播组
多播的基础是将多播组添加到主机的特定接口的过程的概念。 “进程”是指操作系统运行的程序。 特定接口上的多播组的成员是动态的，并且随着进程加入或退出多播组而随时发生变化。
此处的过程需要以某种方式将多播组加入到特定接口中。 进程也可以离开以前加入的多播组。 这些是支持多播主机中的API所需的部分。 之所以使用限定词“接口”，是因为多播组的成员与接口相关联。 一个进程可以在多个接口上加入同一多播组。
来自Stanford大学伯克利版Unix的IP多播详细介绍了套接字API的更改。 Solaris 2.x和IP(7)文档中也介绍了这些更改。
这意味着主机通过组地址和接口标识多播组。 主机必须包含一个表，其中包含至少一个进程的所有多播组和多播组中的进程数。
3.2 IGMP 报告和查询
多播路由器使用IGMP消息记录与该路由器所连接的网络中的组成员的变化。 使用规则如下。
1 )当第一个进程加入组时，主机将发送IGMP报告。 如果主机上的多个进程加入同一组，则只会发送一个IGMP报告。 此报告将发送到进程加入组的同一接口。
2 )当进程离开组时，主机在组中最后一个进程离开时不发送IGMP报告。 在主机知道确定的组中不再有组成员后，主机将不再在随后收到的IGMP查询中发送报告消息。
3 )多播路由器周期性发送IGMP查询以知道是否有包括属于多播组的进程的主机。 多播路由器必须向每个接口发送IGMP查询。 IGMP查询消息的组地址设置为0，因为路由器希望为主机参与的每个多播组返回报告。
4 )主机通过发送IGMP报告来响应IGMP查询，并向至少包含一个进程的每个组返回IGMP报告。
使用这些查询和报告消息，多播路由器为每个接口维护一个表，并记录接口至少包含一个主机的多播组。 路由器收到要转发的多播数据报时，只将该数据报转发到属于该组主机的接口(使用相应多播链路层的地址)。
图1 3 - 3显示了两个IGMP消息。 一个是从主机发送的报告，另一个是从路由器发送的查询。 路由器要求您描述参与该接口上每个主机的每个多播组。
3.3 实现细节
为了改善这次协商的效率，必须考虑很多实现的细节。 首先，当主机第一次发送IGMP报告时，第一个进程加入多播组时，由于正在使用IP分发服务，因此无法确保报告被接收。 下一份报告将隔一段时间发送。 该时间间隔是主体在0 ~ 1 0秒的范围内随机选择的。
第二，主机收到路由器的呼叫后，不会立即响应，而是间隔一定的时间间隔后再响应。 之所以采用“响应”复数形式，是因为必须为每个主机参与的组发送响应。 加入同一多播组的多个主机可以发送一个报告，从而允许将发送间隔设置为随机延迟。 一个物理网络中的所有主机都将从同一组中的其他主机接收所有报告，原因如下
图1 3 - 3所示的报告中的目的地址是那个组地址。这意味着如果一个主机在等待发送报告的过程中，却收到了发自其他主机的相同报告，则该主机的响应就可以不必发送了。因为多播路由器并不关心有多少主机属于该组，而只关心该组是否还至少拥有一个主机。的确，一个多播路由器甚至不关心哪个主机属于一个多播组。它仅仅想知道在给定的接口上的多播组中是否还至少有一个主机。在没有任何多播路由器的单个物理网络中，仅有的IGMP通信量就是在主机加入一个新的多播组时，支持IP多播的主机所发出的报告。
3.4 生存时间字段
在图1 3 - 3中，我们注意到IGMP报告和查询的生存时间（TTL）均设置为1，这涉及到IP首部中的TTL字段。一个初始TTL为0的多播数据报将被限制在同一主机。在默认情况下，待传多播数据报的TTL被设置为1，这将使多播数据报仅局限在同一子网内传送。更大的TTL值能被多播路由器转发。
回顾6 . 2节，对发往一个多播地址的数据报从不会产生ICMP差错。当TTL值为0时，多播路由器也不产生ICMP“超时”差错。
在正常情况下，用户进程不关心传出数据报的TTL.然而，一个例外是Traceroute程序（第8章），它主要依据设置TTL值来完成。既然多播应用必须能够设置要传送数据报的TTL值，这意味着程序设计接口必须为用户进程提供这种能力。
通过增加TTL值的方法，一个应用程序可实现对一个特定服务器的扩展环搜索（eXPandingring search）。第一个多播数据报以TTL等于1发送。如果没有响应，就尝试将TTL设置为2，然后3，等等。在这种方式下，该应用能找到以跳数来度量的最近的服务器。
从224.0.0.0到224.0.0.255的特殊地址空间是打算用于多播范围不超过1跳的应用。不管TTL值是多少，多播路由器均不转发目的地址为这些地址中的任何一个地址的数据报。
3.5 所有主机组
在图1 3 - 3中，我们看到了路由器的IGMP查询被送到目的IP地址224.0.0.1.该地址被称为所有主机组地址。它涉及在一个物理网络中的所有具备多播能力的主机和路由器。当接口初始化后，所有具备多播能力接口上的主机均自动加入这个多播组。这个组的成员无需发送IGMP报告。
4 、一个例子
现在我们已经了解了一些IP多播的细节，再来看看所包含的信息。我们使sun主机能够支持多播，并将采用一些多播软件所提供的测试程序来观察具体的过程。
首先，采用一个经过修改的netstat命令来报告每个接口上的多播组成员情况（在3.9节显示了netstat-ni命令的输出结果）。在下面的输出中，用黑体表示有关的多播组。
IGMP（Internet组管理协议）报文及协议（图四）
其中， - n参数将以数字形式显示IP地址（而不是按名字来显示它们），- i参数将显示接口的统计结果，- a参数将显示所有配置的接口。
输出结果中的第2行le0（以太网）显示了这个接口属于主机组224.0.0.1（“所有主机”），和两行地址，后一行显示相应的以太网地址为：01： 00：5e：00：00：01.这正是我们期望看到的以太网地址，和12 . 4节介绍的地址映射一致。我们还看到其他两个支持多播的接口：SLIP接口sl0和回送接口l o 0，它们也属于所有主机组。
我们也必须显示IP路由表，用于多播的路由表同正常的路由表一样。黑体表项显示了所有传往224.0.0.0的数据报均被送往以太网：
IGMP（Internet组管理协议）报文及协议（图五）
如果将这个路由表与9 . 2节中s u n路由器的路由表作比较，会发现只是多了有关多播的条目。
现在使用一个测试程序来让我们能在一个接口上加入一个多播组（不再显示使用这个测试程序的过程）。在以太网接口（ 1 4 0 . 2 5 2 . 1 3 . 3 3）上加入多播组2 2 4 . 1 . 2 . 3.执行n e t s t a t程序看到内核已加入这个组，并得到期望的以太网地址。用黑体字来突出显示和前面n e t s t a t输出的不同。
IGMP（Internet组管理协议）报文及协议（图六）
我们在输出中再次显示了其他两个接口： s l 0和l o 0，目的是为了重申加入多播组只发生在一个接口上。
图1 3 - 4显示了t c p d u m p对进程加入这个多播组的跟踪过程。
IGMP（Internet组管理协议）报文及协议（图七）
当主机加入多播组时产生第1行的输出显示。第2行是经过时延后的IGMP报告，我们介绍过报告重发的时延是1 0秒内的随机时延。
在两行中显示硬件地址证实了以太网目的地址就是正确的多播地址。我们也看到了源IP地址为相应的s u n主机地址，而目的IP地址是多播组地址。同时，报告的地址和期望的多播组地址是一致的。
最后，我们注意到，正像指明的那样， TTL是1.当TTL的值为0或1时，tcpdump在打印时用方括号将它们括起来，这是因为TTL在正常情况下均高于这些值。然而，使用多播我们期望看到许多TTL为1的IP数据报。
在这个输出中暗示了一个多播路由器必须接收在它所有接口上的所有多播数据报。路由器无法确定主机可能加入哪个多播组。
5、多播路由器的例子
继续前面的例子，但我们将在s u n主机中启动一个多播选路的守护程序。这里我们感兴趣的并不是多播选路协议，而是要研究所交换的IGMP查询和报告。即使多播选路守护程序只运行在支持多播的主机（sun）上，所有的查询和报告都将在那个以太网上进行多播，所以我们在该以太网中的其他系统中也能观察到它们。
在启动选路守护程序之前，加入另外一个多播组224.9.9.9，图13-5显示了输出的结果。
IGMP（Internet组管理协议）报文及协议（图八）
在这个输出中没有包括以太网地址，因为已经证实了它们是正确的。也删去了TTL等于1的说明，同样因为它们也是我们期望的那样。
当选路守护程序启动时，输出第1行。它发出一个已经加入了组224.0.0.4的报告。多播地址224.0.0.4是一个知名的地址，它被当前用于多播选路的距离向量多播选路协议DVMRP（Distance Vector Multicast Routing Protocol）所使用（DVMRP在RFC 1075中定义[Waitzman ，Partridge， and Deering]）。
在该守护程序启动时，它也发送一个IGMP查询（第2行）。该查询的目的IP地址为224.0.0.1（所有主机组），如图13-3所示。
第一个报告（第3行）大约在5秒后收到，报告给组224.9.9.9.这是在下一个查询发出之前（第4行）收到的唯一报告。当守护程序启动后，两次查询（第2行和第4行）发出的间隔很短，这是因为守护程序要将其多播路由表尽快建立起来。
第5、6和7行正是我们期望看到的：sun主机针对它所属的每个组发出一个报告。注意组224.0.0.4是被报告的，而其他两个组则是明确加入的，因为只要选路守护程序还在运行，它始终要属于组224.0.0.4.
下一个查询位于第8行，大约在前一个查询的2分钟后发出。它再次引发三个我们所期望的报告（第9、10和11行）。这些报告的时间顺序与前面不同，因为接收查询和发送报告的时间是随机的。
最后的查询在前一个查询的大约2分钟后发出，我们再次得到了期望的响应。
多播是一种将报文发往多个接收者的通信方式。在许多应用中，它比广播更好，因为多播降低了不参与通信的主机的负担。简单的主机成员报告协议（ IGMP ）是多播的基本模块。
在一个局域网中或跨越邻近局域网的多播需要使用本章介绍的技术。广播通常局限在单个局域网中，对目前许多使用广播的应用来说，可采用多播来替代广播。
然而，多播还未解决的一个问题是在广域网内的多播。[Deering and Cheriton 1990] 提出扩展目前的路由协议来支持多播。9.13节中的[Perlman 1992]讨论了广域网多播的一些问题。
[Casner and Deering 1992] 介绍了使用多播和一个称为MBONE（多播主干）的虚拟网络在整个Internet上传送IETF会议的情况。