Internet組管理協議

主機IP軟件需要進行組播擴展，才能使主機能夠在本地網絡上收發組播分組。但僅靠這一點是不夠的，因為跨越多個網絡的組播轉發必須依賴於路由器。路由器為建立組播轉發路由必需瞭解每個組員在Internet中的分佈，這要求主機必須能將其所在的組播組通知給本地路由器，這也是建立組播轉發路由的基礎。主機與本地路由器之間使用Internet組管理協議（IGMP，Internet Group Management Protocol）來進行組播組成員信息的交互。IGMP是TCP/IP中重要標準之一，所有IP組播系統（包括主機和路由器）都需要支持IGMP協議。

組播協議包括組成員管理協議和組播路由協議。組成員管理協議用於管理組播組成員的加入和離開，組播路由協議負責在路由器之間交互信息來建立組播樹。IGMP屬於前者，是組播路由器用來維護組播組成員信息的協議，運行於主機和組播路由器之間。IGMP 信息封裝在IP報文中，其IP的協議號為2。

若一個主機想要接收發送到一個特定組的組播數據包，它需要監聽發往那個特定組的所有數據包。為解決Internet上組播數據包的路徑選擇，主機需通過通知其子網上的組播路由器來加入或離開一個組，組播中採用IGMP來完成這一任務。這樣，組播路由器就可以知道網絡上組播組的成員，並由此決定是否向它們的網絡轉發組播數據包。當一個組播路由器收到一個組播分組時，它檢查數據包的組播目的地址，僅當接口上有那個組的成員時才向其轉發。

IGMP提供了在轉發組播數據包到目的地的最後階段所需的信息，實現如下雙向的功能：

IGMP共有三個版本，即IGMP v1、v2 和 v3。

IGMPv1 定義了主機只可以加入組播組，但沒有定義離開成員組的信息，路由器基於成員組的超時機制發現離線的組成員。 ^[2] 

IGMPv1 主要基於查詢和響應機制來完成對組播組成員的管理。當一個網段內有多台組播路由器時，由於它們都能從主機那裏收到IGMP 成員關係報告報文（Membership Report Message），因此只需要其中一台路由器發送IGMP查詢報文（Query Message）就足夠了。這就需要有一個查詢器（Querier）的選舉機制來確定由哪台路由器作為IGMP 查詢器。對於IGMPv1 來説，由組播路由協議（如PIM）選舉出唯一的組播信息轉發者DR（Designated Router，指定路由器）作為IGMP 查詢器。

IGMPv1 沒有專門定義離開組播組的報文。當運行IGMPv1 的主機離開某組播組時，將不會向其要離開的組播組發送報告報文。當網段中不再存在該組播組的成員後，IGMP路由器將收不到任何發往該組播組的報告報文，於是IGMP 路由器在一段時間之後便刪除該組播組所對應的組播轉發項。

iGMPv2 是在版本1 上基礎上增加了主機離開成員組的信息，允許迅速向路由協議報告組成員離開情況，這對高帶寬組播組或易變型組播組成員而言是非常重要的。另外，若一個子網內有多個組播路由器，那麼多個路由器同時發送IGMP 查詢報文不僅浪費資源,還會引起 ^[1]  網絡的堵塞。為解決這個問題，IGMPv2。不同使用路由選舉機制, 能在一個子網內查詢多個路由器。

igmp版本2對版本1所做的改進主要有：

(1)共享網段上組播路由器的選舉機制

共享網段表示一個網段上有多個組播路由器的情況。在這種情況下，由於此網段上運行igmp的路由器都能從主機那裏收到成員資格報告消息，因此，只需要一個路由器發送成員資格查詢消息，這就需要一個路由器選舉機制來確定一個路由器作為查詢器。其選舉過程如下：

(1) 所有IGMPv2路由器在初始時都認為自己是查詢器，並向本地網段內的所有主機和路由器發送IGMP 普遍組查詢（General Query）報文（目的地址為:224.0.0.1）；

(2) 本地網段中的其它IGMPv2路由器在收到該報文後，將報文的源IP 地址與自己的接口地址作比較。通過比較，IP 地址最小的路由器將成為查詢器，其它路由器成為非查詢器（Non-Querier）；

(3) 所有非查詢器上都會啓動一個定時器（即其它查詢器存在時間定時器OtherQuerier Present Timer）。在該定時器超時前，如果收到了來自查詢器的IGMP查詢報文，則重置該定時器；否則，就認為原查詢器失效，併發起新的查詢器選舉過程。

在igmp版本1中，查詢器的選擇由組播路由協議決定；igmp版本2對此做了改進，規定同一網段上有多個組播路由器時，具有最小ip地址的組播路由器被選舉出來充當查詢器。

(2)igmp版本2增加了離開組機制

在igmp版本1中，主機悄然離開組播組，不會給任何組播路由器發出任何通知。造成組播路由器只能依靠組播組響應超時來確定組播成員的離開。而在版本2中，當一個主機決定離開時，如果它是對一條成員資格查詢消息作出響應的主機，那麼它就會發送一條離開組的消息。

在IGMPv2 中，當一個主機離開某組播組時：

(1) 該主機向本地網段內的所有組播路由器（目的地址為224.0.0.2）發送離開組（Leave Group）報文；

(2) 當查詢器收到該報文後，向該主機所聲明要離開的那個組播組發送特定組查詢（Group-Specific Query）報文（目的地址字段和組地址字段均填充為所要查詢的組播組地址）；

(3) 如果該網段內還有該組播組的其它成員，則這些成員在收到特定組查詢報文後，會在該報文中所設定的最大響應時間（Max Response Time）內發送成員關係報告報文；

(4) 如果在最大響應時間內收到了該組播組其它成員發送的成員關係報告報文，查詢器就會繼續維護該組播組的成員關係；否則，查詢器將認為該網段內已無該組播組的成員，於是不再維護這個組播組的成員關係。

(3)igmp版本2增加了對特定組的查詢

在igmp版本1中，組播路由器的一次查詢，是針對該網段下的所有組播組。這種查詢稱為普遍組查詢。

在igmp版本2中，在普遍組查詢之外增加了特定組的查詢，這種查詢報文的目的ip地址為該組播組的ip地址，報文中的組地址域部分也為該組播組的ip地址。這樣就避免了屬於其它組播組成員的主機發送響應報文。

(4)igmp版本2增加了最大響應時間字段

igmp版本2增加最大響應時間字段，以動態地調整主機對組查詢報文的響應時間。

IGMPv3 在兼容和繼承IGMPv1 和IGMPv2 的基礎上，進一步增強了主機的控制能力，並增強了查詢和報告報文的功能。 ^[2] 

IGMPv3 增加了針對組播源的過濾模式（INCLUDE/EXCLUDE），使主機在加入某組播組G 的同時，能夠明確要求接收或拒絕來自某特定組播源S 的組播信息。當主機加入組播組時：

若要求只接收來自指定組播源如S1、S2、……的組播信息，則其報告報文中可以標記為INCLUDE Sources（S1，S2，……）；

若拒絕接收來自指定組播源如S1、S2、……的組播信息，則其報告報文中可以標記為EXCLUDE Sources（S1，S2，……）。

(1) 攜帶源地址的查詢報文

IGMPv3 不僅支持IGMPv1 的普遍組查詢和IGMPv2 的特定組查詢，而且還增加了對特定源組查詢的支持：

z 普遍組查詢報文中，既不攜帶組地址，也不攜帶源地址；

z 特定組查詢報文中，攜帶組地址，但不攜帶源地址；

z 特定源組查詢報文中，既攜帶組地址，還攜帶一個或多個源地址。

(2) 包含多組記錄的報告報文

IGMPv3 報告報文的目的地址為224.0.0.22，可以攜帶一個或多個組記錄。在每個組記錄中，包含有組播組地址和組播源地址列表。組記錄可以分為多種類型，如下：

IS_IN：表示組播組與組播源列表之間的過濾模式為INCLUDE，即只接收從指定組播源列表發往該組播組的組播數據。

IS_EX：表示組播組與組播源列表之間的過濾模式為EXCLUDE，即只接收從指定組播源列表之外的組播源發往該組播組的組播數據。

z TO_IN：表示組播組與組播源列表之間的過濾模式由EXCLUDE 轉變為INCLUDE。

TO_EX：表示組播組與組播源列表之間的過濾模式由INCLUDE 轉變為EXCLUDE。

ALLOW：表示在現有狀態的基礎上，還希望從某些組播源接收組播數據。如果當前的對應關係為INCLUDE，則向現有組播源列表中添加這些組播源；如果當前的對應關係為EXCLUDE，則從現有組播源列表中刪除這些組播源。

BLOCK：表示在現有狀態的基礎上，不再希望從某些組播源接收組播數據。如果當前的對應關係為INCLUDE，則從現有組播源列表中刪除這些組播源；如果當前的對應關係為EXCLUDE，則向現有組播源列表中添加這些組播源。

實現步驟如下：

1、當主機某個進程加入一個組播組時，主機發送一個IGMP 報告。若一個主機多個進程同時加入同一組，則發送一個IGMP 報告。

2、進程離開一個多播組時，主機不發送IGMP 報告，即便是組中最後一個進程離開多播組。當主機確定已不再有組成員後，在隨後收到的IGMP 查詢中就不應答報文。

3、多播路由器定時發送IGMP 查詢是否還有其他主機包含有屬於多播組的進程。多播路由器必須向每個接口發送IGMP 查詢。

4、主機通過發送IGMP 報告來響應一個IGMP 查詢，對每個至少還包含一個進程的組均要發回IGMP 報告。

使用上述查詢和報告報文，多播路由器對每個接口保持一張映射表，表中記錄了接口上包含的一個或多個主機多播組。當路由器收到要轉發的多播數據報時，只需將該數據報轉發到該接口上。

IP 組播使用用户數據報UDP 協議，然而UDP 是盡最大能力投遞的一種協議。因此，IP 組播應用勢必會遇到數據包丟失和亂序問題。為此，對於IGMP 不同類型的應用必須在確認方式( 肯定確認ACK 和否定確認NACK)，集中確認與分佈確認、重傳機制、流量控制、擁塞控制等方面綜合考慮，提出解決方案。迄今為止，儘管在廣域網環境中已經存在許多可靠組播協議，包括可靠組播協議RMP(ReliableMulticast Protocol)，可擴可靠組播SRM(Scalable Reliable Multicast)，和可靠組播傳輸協議RMTP(ReliableMulticast Transport Protocol)。組播的可靠性研究仍然是重點研究課題之一。 ^[2] 

組播安全性是隻有註冊的主機才能夠向組發送數據和接收組播數據。

然而IP 組播很難保證這一點。首先，IP 組播使用UDP，網絡中任何主機都可以向某個組播地址發送UDP 包；其次，Internet缺少對於網絡層的訪問控制，組成員可以隨時加入和退出組播組，使得組播安全性問題仍然是一個技術難點。

IGMP 組播協議是IPv4 環境下重要的協議。IGMPv1 實現簡單，但是主機離開多播組延遲過大，選擇查詢路由器需要依賴具體的組播路由協議；IGMPv2缺少對主機進程加入多播組的定義，制約了其應用範圍。IGMPv3 主要改進是支持源特定組播。大部分的網絡設備和主機操作系統協議棧都支持IGMPv1 和IGMPv2，但為適應複雜的網絡需求，必須大力推進IGMPv3 協議的用應用。Windows XP 已經支持IGMPv3 ，UNIX 操作系統也可以與IGMP v1/ v2 版本向後兼容，組播技術有着廣闊的發展前景。

IGMP的組成員查詢利用報文中類型字段0x11來標識。IGMP的組成員查詢包含了兩種子類型：一般組成員查詢（General Query）和特定組成員查詢（Group-Specific Query）。子類型利用報文中的組播組地址（Group Address）字段來區分：組地址段等於0，表示一般組成員查詢；組地址地段不等於0，則表示特定組成員查詢，用於查詢本地網絡中的每個指定組播組的成員，其中組播組的地址由組地址（Group Address）字段來指定被查詢的組播組。在IGMPv1中只支持一般組成員查詢，IGMPv2支持特定組成員查詢。 ^[1] 

IGMP約定，本地路由器利用一般組成員查詢方式來週期性地向本網絡內的所有主機發送IGMP組成員查詢報文；本地網絡中的主機在接收到IGMP查詢報文時，將會對該報文作出相應，返回一個組成員報告報文，通知路由器本主機所在的組播組的地址。

正常情況下，IGMP採用一般組播組成員查詢來輪詢本地網絡中的組成員信息。這種查詢並非針對某一個組播組，而是針對本地網絡中所有組進行查詢。在某些特定環境中，路由器也需要查詢在本地網絡中是否存在某個特定組播組的成員。這時可使用特定組成員查詢。