組播（二）---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這個靜悄悄的走很像一個和家長鬧別扭的孩子，賭氣之下在父母不知道情況之下從自己卧室離家出走，父母還以為孩子在屋里面睡覺，直到明天叫讓孩子吃早飯才發現孩子不見了。當組員下線之后，由於網關不知道，網關仍然以為組員還在工作，於是繼續發送組播報文，交接機也繼續泛洪，這有什么問題呢？會浪費交換機的資源，非組員也得拆封裝到二層才能發現這不是給自己報文，網關早晚會知道，那是什么時候呢？就是當網關通過請求報文詢問三次(即三倍的請求報文周期)以后，發現沒主機回復，於是認為組員已經走了，就停止轉發報文了。人類的父母和網關在遇到這種情況時，前者會焦急尋找，后者會清除組員的痕跡然后，停止轉發組播報文 。
還忽略了一個問題，那就是通告報文是立馬發送的嗎？
不是的，當主機收到請求報文之后，並不是立馬發送通告報文的，而是有一個計數器，從一到十隨機生成一個隨機數，然后倒計時進行發送，為什么會這樣？為什么要用這個計時器，目的就是盡可能錯開所有主機發送通告報文的時機，為組播抑制打好基礎。