组播（二）---IGMP
组播里面非常重要的两个协议 IGMP和PIM，我们先学一个简单的那就IGMP，IGMP运行于终端与最后一跳路由器中间（注意是终端与最后一跳路由器，而不是第一跳路由器）。IGMP有三个版本，V1/V2/V3，V1最为简陋，我们要从V1开始学起，V2弥补了V1的一些坑，使用的频率比较广，V3最大特点是支持SSM，SSM还记得吗？SSM是特定组播源的意思，换句话说V1和V2是不支持SSM的。
IGMP的全称是internet group management protocol，名字叫的点大，互联网组管理协议 ，我们先从第一个版本聊起。
IGMP是构建在IP报文的基础上
IGMP和ICMP协议看着有点像，是否还记得一张OSI七层参考模型的图，在网络层这个地方，有IP，然后有ICMP和IGMP，IGMP和ICMP们于IP之上，但又位于传输层之下，当时不理解这是什么意思，工作多年后才发现 ，ICMP和IGMP都是在IP基本上，也就说数据的结构这样的：帧头--IP头---IGMP报文，我们也可以再进一步，IP头是晚于IGMP或ICMP封装的，也就是我们可以通过IP的头部的字段来判断出上层协议是什么？
如上图所示，在IP层的protocol字段当中显示为1，意味着他的上层协议是ICMP，如果这个字段是2呢？2其实就是代表上层协议是IGMP，那arp报文是什么样？arp是建立IP报文之上吗？其实arp并不是建立在IP之上的，而应该在IP之下，所以arp到底是二层协议还是三层协议，从这个角度来看，arp协议应该是二层协议 。
IGMPV1
IGMPV1的报文比较简单，就两种类型的报文 ，请求和通告，请求报文是周期性发送的，默认是60秒。
请求报文是路由器发送的，发送给谁呢？发送给终端 ，其实就是路由器问一下当前接口下有没有组员，如果有组员的话，组员通过特定的MAC地址就会收到路由器请求的报文 ，然后组员会通过通告报文，告诉路由器（其实也就是网关）自己所属的组，然后路由器会记录下来，知道自己所连接的某一个接口下有一个组播组，收到这个组的流量要转发到此接口；如果没有组员呢？其实没有组员，路由器就收不到通告，路由器悻悻而归，知道了自己的接口下没有主机属于某个组，当到了某个组的流量，也不会转发，无动于衷。
先来一个简单的问题，请求报文的目标IP是多少？源IP是多少？源MAC是多少、目标MAC又是多少？
源IP应该就是网关的IP，那目标IP呢？目标IP是组播组的IP吗？是的，224.0.0.1是组播的组地址吗？其实不是的，224.0.0.1是指所有的主机 ，这样看来，目标地址 是224.0.0.1和广播也差不多；
其实这个目标IP地址起的作用并不大，因为没有终端的IP是地址是组播地址 ，组播地址是配置不到终端上的，那怎么样才能保证组员能收到，非组员就收不到呢？这就不能依靠目标IP地址了，而是依靠MAC地址 ，源MAC没有什么好说的，就是网关的MAC地址 ，但是目标MAC就很有意思了，关于MAC的前六个字符是固定的，后面六个字符是根据什么生成的呢？这是个重要的问题？是根据组播组地址生成的吗？不是的，不是的，不是的，路由器起初是不知道自己的接口下连接了哪些组，所以目标MAC地址不是根据组播组IP生成的，这个目标IP地址就是根据224.0.0.1这个目标IP产生的。
还要注意一个地址，我们发现IGMP协议的请求报文的真正内容的关键字段是0.0.0.0，从这里面可以看出，路由器接口在发现组播请求报文的时候，它也不知道下面哪些主播组，0.0.0.0的意思就是向接口下所有主机喊一声：有没有主机加入到组播组？如果有话，给我回复一个通告报文。
再来谈一个问题，通告报文的源MAC、IP和目标MAC、IP是多少？
源IP是肯定就是终端的源IP，那目标IP呢？目标决定这个数据包最终要到哪里？所以这个目标IP不能是网关，因为网关并不是最终在到达的位置，目标IP就要是组播组的IP，但我们要注意，这个目标组播IP实际没有什么意思？为什么这么说，是因为，在通告报文的记主要作用是告诉路由器，自己属于哪一个组播组，在IGMP的报文里面已经明确告诉路由器，自己属于哪个组播组，所以说，这里面的目标组播IP并没有什么实际的意义。
源MAC肯定是终端自己的MAC，目标MAC是多少呢？目标MAC是网关的mac吗？正常来看，目标MAC就应该是网关的MAC，毕竟我们下一跳要给网关呀，但这里面又穿插了一个问题，导致目标MAC并不是网关的MAC，尽管下一跳确实给它，实际上目标MAC是根据组播组地址算出来的，那问题来了，这么搞的话，那网关还能收到这个通告报文吗？为什么通告报文的目标MAC要这么设置？在讲清楚这个问题之前我们，我们先要看下一个问题。
第三个问题，如果一个路由器的接口下，有100多台终端都要使用组播，路由器还是发一次请求报文，那这接收多少份通告报文呢？
路由器发送一次请求报文，按理说每一台终端都要进行回应，这样的话，路由器的接口会非常繁忙，甚至往大了说，带宽也会受一定的影响，因为请求是周期性的，默认是60秒一次，那么有没有更简单的办法，其实是有的，那就是组播抑制，它是这样工作的，当有主机收了请求报文之后，并不是立马进行回应的，而是一个计时器计时，到了某个时间点之后，主机才会回复通告报文，这看起也挺正常，也没什么呀，怎么就抑制了呢？关键就这个通告报文的目标mac和目标Ip上，目标ip是所属组播组的IP地址，这没有什么好说的，但目标MAC地址并是网关的mac，而是根据组播IP计算出来了组播MAC地址，也就是说当一个主机回复通告报文 时，同域内的所有归属于相同组播组的主机也会收到，当其它组员收到之后，就会知道，有人已经发了通告报文 ，它们可以不用发了，毕竟，第一跳或最后一跳路由器他不需要知道当前接口有多少台主机，只需要知道当前接口下有没有主机 ，因为无论有多少台，路由器只发一份请求报文 。
第四个问题，组播通告报文的目标MAC是根据组播IP计算出来的MAC，同组内的主机会收到这好理解 ，我们可以理解因为这些主机就侦听了这个组播IP，自然能够识别这个目标MAC是这个MAC的报文 ，组播的第二个目的是让路由器知道，那路由器接口也会这个能力吗？如果可以 ，它为什么有这种能力？
当路由器的接口激活了IGMP协议之后，就拥有了能识别任意组播MAC地址的能力，当一个主机回复通告报文之后，其它同组的主机会被组播抑制，同组的主机能收到的原因之一是因为目标MAC是组播MAC，但这并不是最主要的原因，最重要的原因是交换机能收到了这样的组播包，那交换机收到这样的组播包之后是怎么处理的呢？普通交换机对组播的处理与广播报文是一样的，就是直接泛洪的，这样的话，不仅同组内的主机能收到通告报文 ，从而产生组播抑制，网关当然也能收到，在这里面，交换机的泛洪功能必不可少。
注意，我们上述所述的交换机就是普通交换机。
最后一个问题，当路由器知道自己的接口之下有组播组之后，会转发该组的报文到这个接口，但是，如果当组员不能接收了，也就是说当组员离组之后，路由器会立马知道吗？如果不立马知道会有什么结果?
IGMPV1只有两种类型的报文，一个请求，二是通告，请求这种类型的报文是周期性发送的，也只能由路由器的接口发送，这种报文对于离组有什么帮助吗？没帮助，但可以参照，怎么参照呢？当终端的主机正常的时候，路由器问一次就会回复一次，路由器会正常转发组播报文，但当主机离线之后，路由器是不知道的，为啥不知道？因为主机并没有通知它，为啥不通知它，因为IGMPv1就没有离线之后通知网关的这种机制，都说了IGMPV1非常简单，只有请求和通告这两种报文，主机总不能用请求报文，因为这是路由器的专属，那能用通告报文吗？不能，为啥呢？通告报文在设计的时候只有一种功能，它虽然在可以在两种场景下可以发送，一个是当路由器询问时，主机能发送通告报文，还有就是当主机上线时，主机也可以主动发送，这两种场景当中，最核心就是通告报文代表的是加入，它不能代表离开，所以V1的组员离线是静悄悄的。
写到这里面，我发现IGMPV1这个静悄悄的走很像一个和家长闹别扭的孩子，赌气之下在父母不知道情况之下从自己卧室离家出走，父母还以为孩子在屋里面睡觉，直到明天叫让孩子吃早饭才发现孩子不见了。当组员下线之后，由于网关不知道，网关仍然以为组员还在工作，于是继续发送组播报文，交接机也继续泛洪，这有什么问题呢？会浪费交换机的资源，非组员也得拆封装到二层才能发现这不是给自己报文，网关早晚会知道，那是什么时候呢？就是当网关通过请求报文询问三次(即三倍的请求报文周期)以后，发现没主机回复，于是认为组员已经走了，就停止转发报文了。人类的父母和网关在遇到这种情况时，前者会焦急寻找，后者会清除组员的痕迹然后，停止转发组播报文 。
还忽略了一个问题，那就是通告报文是立马发送的吗？
不是的，当主机收到请求报文之后，并不是立马发送通告报文的，而是有一个计数器，从一到十随机生成一个随机数，然后倒计时进行发送，为什么会这样？为什么要用这个计时器，目的就是尽可能错开所有主机发送通告报文的时机，为组播抑制打好基础。