組播

通常，在傳統的網絡通訊中，有兩種方式，一種是源主機和目標主機兩台主機之間進行的“一對一”的通訊方式，即單播，第二種是一台源主機與網絡中所有其他主機之間進行的通訊，即廣播。那麼，如果需要將信息從源主機發送到網絡中的多個目標主機，要麼採用廣播方式，這樣網絡中所有主機都會收到信息，要麼，採用單播方式，由源主機分別向各個不同目標主機發送信息。可以看出來，在廣播方式下，信息會發送到不需要該信息的主機從而浪費帶寬資源，甚至引起廣播風暴：而單播方式下，會因為數據包的多次重複而浪費帶寬資源，同時，源主機的負荷會因為多次的數據複製而加大，所以，單播與廣播對於多點發送問題有缺陷。

在此情況下，組播技術就應用而生了。

組播又稱多目標廣播、多播。網絡中使用的一種傳輸方式，它允許把 所發消息傳送給所有可能目的地中的一個經過選擇的子集，即嚮明確指出的多種地址輸送信息。是一種在一個發送者和多個接收者之間進行通信的方法。與任播(anycast)和單播(unicast)一起，組播也是一種IPv6的包傳送方式。組播在CDPD技術中的無線數據網絡中也可以使用。 ^[2] 

1985年9月，Steve與其導師提出了支持IP組播的擴展模型，明確了Internet組管理協議 (Internet Group Management Protocol, IGMP) 概念。12月，Steve將此概念提交給了IETF, 而後經過兩次更新該組播模型，越不同網段的轉發沒有定義，此方面的工作已經被獨立為組播路由技術。1989年8月，RFC1112作為IGMPv1的規範被廣泛接受，這是組播發展歷程中的一個重要里程碑。 ^[3] 

組播技術是IP網絡數據傳輸三種方式之一，在介紹IP組播技術之前，先對IP網絡數據傳輸的單播、組播和廣播方式做一個簡單的介紹。

在發送者和每一接收者之間實現點對點網絡連接。如果一台發送者同時給多個的接收者傳輸相同的數據，也必須相應的複製多份的相同數據包。如果有大量主機希望獲得數據包的同一份拷貝時，將導致發送者負擔沉重、延遲長、網絡擁塞；為保證一定的服務質量需增加硬件和帶寬。

廣播指在IP子網內廣播數據包，所有在子網內部的主機都將收到這些數據包。廣播意味着網絡向子網每一個主機都投遞一份數據包，不論這些主機是否樂於接收該數據包。所以廣播的使用範圍非常小，只在本地子網內有效，通過路由器和網絡設備控制廣播傳輸。

組播在發送者和每一接收者之間實現點對多點網絡連接。如果一台發送者同時給多個接收者傳輸相同的數據，也只需複製一份相同的數據包。它提高了數據傳送效率，減少了骨幹網絡出現擁塞的可能性。

組播解決了單播和廣播方式效率低的問題。當網絡中的某些用户需求特定信息時，組播源（即組播信息發送者）僅發送一次信息，組播路由器藉助組播路由協議為組播數據包建立樹型路由，被傳遞的信息在儘可能遠的分叉路口才開始複製和分發。

公共互聯網中的一些團體經常會用到IP組播（Mbone就是一個例子），此外IP組播還被用於Internet2等私有IP網絡中的一些特殊應用。鏈路本地組播是指將IP組播包發往處於同一物理的或虛擬的數據鏈路層的若干主機組。由於這種組播不需要複雜的路由，因此其應用要廣泛得多。在IPv6中，它被用於地址解析，而在零配置網絡中，它取代了低效的廣播協議，完成服務發現、名字解析和地址衝突解析的功能。

IP組播會議的第一次大規模演示是在1992年3月的第23屆IETF大會上，當時它被用於向全世界的研究人員和感興趣的觀察員們廣播一些會議。之後，IETF的一些會議就被有選擇地繼續在MBONE和一些私有組播網絡上多播。

組播安全性是一個重要的問題。標準的、實用的通信安全解決方案一般採用的是對稱加密。但是將其應用於IP組播流量可能會使任何一個接收方都擁有冒充發送方的能力。這顯然是令人無法接受的。IETF的MSEC工作組正在開發用以解決這一問題的安全協議，這些協議大多都是在IPsec協議集的體系框架內開發的。

IPsec不能被用於組播方案，這是因為IPsec安全關聯是被綁定到兩個而非多個主機的。IETF提出了一個新的協議——TESLA，就組播安全性而言，這個協議是靈活且令人信服的。

組播協議分為主機-路由器之間的組成員關係協議和路由器-路由器之間的組播路由協議。組成員關係協議包括IGMP（互連網組管理協議）。組播路由協議分為域內組播路由協議及域間組播路由協議。域內組播路由協議包括PIM-SM、PIM-DM、DVMRP等協議，域間組播路由協議包括MBGP、MSDP等協議。同時為了有效抑制組播數據在鏈路層的擴散，引入了IGMP Snooping、CGMP等二層組播協議。對組播的技術歷史作出了巨大的貢獻！

IGMP建立並且維護路由器直聯網段的組成員關係信息。域內組播路由協議根據IGMP維護的這些組播組成員關係信息，運用一定的組播路由算法構造組播分發樹進行組播數據包轉發。域間組播路由協議在各自治域間發佈具有組播能力的路由信息以及組播源信息，以使組播數據在域間進行轉發。

組播IP地址用於標識一個IP組播組。IANA（internet assigned number authority）把D類地址空間分配給IP組播，其範圍是從224.0.0.0到239.255.255.255。如二進制表示，IP組播地址前四位均為1110八位組⑴ 八位組⑵ 八位組⑶ 八位組⑷1110

XXXX XXXXXXXX XXXXXXXX XXXXXXXX組播組可以是永久的也可以是臨時的。組播組地址中，有一部分由官方分配的，稱為永久組播組。永久組播組保持不變的是它的ip地址，組中的成員構成可以發生變化。永久組播組中成員的數量都可以是任意的，甚至可以為零。那些沒有保留下來供永久組播組使用的ip組播地址，可以被臨時組播組利用。

224.0.0.0～224.0.0.255為預留的組播地址（永久組地址），地址224.0.0.0保留不做分配，其它地址供路由協議使用。

224.0.1.0～238.255.255.255為用户可用的組播地址（臨時組地址），全網範圍內有效。

239.0.0.0～239.255.255.255為本地管理組播地址，僅在特定的本地範圍內有效。常用的預留組播地址列表如下：

224.0.0.0 基準地址（保留）

224.0.0.1 所有主機的地址

224.0.0.2 所有組播路由器的地址

224.0.0.3 不分配

224.0.0.4dvmrp（Distance Vector Multicast Routing Protocol，距離矢量組播路由協議）路由器

224.0.0.5 ospf（Open Shortest Path First，開放最短路徑優先）路由器

224.0.0.6 ospf dr（Designated Router，指定路由器）

224.0.0.7 st (Shared Tree，共享樹）路由器

224.0.0.8 st主機

224.0.0.9 rip-2路由器

224.0.0.10 Eigrp(Enhanced Interior Gateway Routing Protocol，增強網關內部路由線路協議）路由器　224.0.0.11 活動代理

224.0.0.12 dhcp服務器/中繼代理

224.0.0.13 所有pim (Protocol Independent Multicast，協議無關組播）路由器

224.0.0.14 rsvp （Resource Reservation Protocol，資源預留協議）封裝

224.0.0.15 所有cbt 路由器

224.0.0.16 指定sbm（Subnetwork Bandwidth Management，子網帶寬管理）

224.0.0.17 所有sbms

224.0.0.18 vrrp（Virtual Router Redundancy Protocol，虛擬路由器冗餘協議）

239.255.255.255 SSDP協議使用

組播MAC地址

組播MAC地址的高24bit為0x01005e，第25bit為0，即高25bit為固定值。MAC地址的低23bit為組播IP地址的低23bit。由於 IP組播地址的前4bit 是1110，代表組播標識，而後28bit 中只有23bit 被映射到MAC 地址，這樣IP 地址中就有5bit 信息丟失，導致的結果是出現了32 個IP 組播地址映射到同一MAC 地址上。

IP組播的最大的用處就是用來做Internet上的音頻和視頻的傳輸，比如向成百上千的使用者發送音頻和視頻數據流。可是傳統的IP組播的有一個最大的缺點就是這些所有的使用者都是被動的接受者。換句話説，IP組播並沒有讓這些使用者進行交互式主動參與的內置機制。

利用H.323國際標準中對會議成員的管理技術，SAP（Session Announcement Protocol），SDP(Session Description Protocol),RTCP(Real-time Transport Control Protocol）等協議，就可以使傳統的IP組播技術具有交互功能。交互式IP組播技術應用範圍很廣，特別是Internet上多媒體的傳輸業務。比如視頻會議，遠程教育，Internet上的視頻點播（VoD）等。

在組播方式中，信息的發送者稱為“組播源”，信息接收者稱為該信息的“組播組”，支持組播信息傳輸的所有路由器稱為“組播路由器”。加入同一組播組的接收者成員可以廣泛分佈在網絡中的任何地方，即“組播組”沒有地域限制。需要注意的是，組播源不一定屬於組播組，它向組播組發送數據，自己不一定是接收者。多個組播源可以同時向一個組播組發送報文。

假設只有 Host B、Host D 和Host E 需要信息，採用組播方式時，可以讓這些主機加入同一個組播組（Multicast group），組播源向該組播組只需發送一份信息，並由網絡中各路由器根據該組播組中各成員的分佈情況對該信息進行復制和轉發，最後該信息會準確地發送給Host B、Host D 和Host E。

組播協議分為主機與路由器之間的組成員關係協議和路由器與路由器之間的組播路由協議。 ^[4] 

IGMP協議運行於主機和與主機直接相連的組播路由器之間，主機通過此協議告訴本地路由器希望加入並接受某個特定組播組的信息，同時路由器通過此協議週期性地查詢局域網內某個已知組的成員是否處於活動狀態（即該網段是否仍有屬於某個組播組的成員），實現所連網絡組成員關係的收集與維護。

IGMP有三個版本，IGMPv1由RFC1112定義，通用的是IGMPv2，由RFC2236定義。IGMPv3仍然是一個草案。IGMPv1中定義了基本的組成員查詢和報告過程，IGMPv2在此基礎上添加了組成員快速離開的機制，IGMPv3中增加的主要功能是成員可以指定接收或指定不接收某些組播源的報文。這裏着重介紹IGMPv2協議的功能。

IGMPv2通過查詢器選舉機制為所連網段選舉唯一的查詢器。查詢器週期性的發送普遍組查詢消息進行成員關係查詢；主機發送報告消息來應答查詢。當要加入組播組時，主機不必等待查詢消息，主動發送報告消息。當要離開組播組時，主機發送離開組消息；收到離開組消息後，查詢器發送特定組查詢消息來確定是否所有組成員都已離開。

通過上述IGMP機制，在組播路由器裏建立起一張表，其中包含路由器的各個端口以及在端口所對應的子網上都有哪些組的成員。當路由器接收到某個組G的數據報文後，只向那些有G的成員的端口上轉發數據報文。至於數據報文在路由器之間如何轉發則由路由協議決定，IGMP協議並不負責。

IGMP Snooping的實現機理是：交換機通過偵聽主機發向路由器的IGMP成員報告消息的方式，形成組成員和交換機接口的對應關係；交換機根據該對應關係將收到組播數據包只轉給具有組成員的接口。

IGMP Proxy與IGMP Snooping實現功能相同但機理相異：IGMP snooping只是通過偵聽IGMP的消息來獲取有關信息，而IGMP Proxy則攔截了終端用户的IGMP請求並進行相關處理後，再將它轉發給上層路由器。

CGMP（Cisco Group Management Protocol）是Cisco基於客户機/服務器模型開發的私有協議，在CGMP的支持下，組播路由器能夠根據接收到的IGMP數據包通知交換機哪些主機何時加入和脱離組播組，交換機利用由這些信息所構建的轉發表來確定將組播數據包向哪些接口轉發。GMRP是主機到以太網交換機的標準協議，它使組播用户可以在第二層交換機上對組播成員進行註冊。

眾多的組播路由協議中，應用最多的協議是 PIM-SM稀疏模式協議無關組播。

在PIM-SM域中，運行PIM-SM協議的路由器週期性的發送Hello消息，用以發現鄰接的PIM路由器，並且負責在多路訪問網絡中進行指定路由器（DR）的選舉。這裏，DR負責為其直連組成員朝着組播分發樹根節點的方向發送"加入/剪枝"消息，或是將直連組播源的數據發向組播分發樹。

組播的規範是在1989年出版的，但是它的使用受到了限制。Internet上的路由器並不是都具有組播的能力。在這樣一種情況下，研究者們為了在現有情況下開發和測試組播協議的應用，建立了組播骨幹網（Multicast Backbone，Mbone）。Mbone支持組播分組的路由選擇而不打擾其它的因特網業務流。

Mbone是一種跨越幾個大陸的，由志願者合作完成的實驗性的網絡。它是一個相互連接的子網和路由器的集合，這些子網和路由器支持IP組播業務流的傳送。作為因特網上的虛擬網絡，Mbone通過隧道（Tunneling）來旁路因特網上無組播能力的路由器。

隧道把組播數據包封裝在IP包（即單播數據包）中來通過哪些不支持組播路由的網絡。MR3和MR4是支持IGMP協議的有組播能力的路由器，他們把組播數據包封裝在單播數據包中來發送，同時它們還從收到的單播數據包中取出組播數據包。R1和R2是沒有組播能力的路由器，它們像傳送其它普通單播數據包那樣來傳送封裝有組播數據包的單播數據包。

組播應用大致可以分為三類： 點對多點應用，多點對多點應用和多點對點應用。

點對多點應用是指一個發送者，多個接收者的應用形式，這是最常見的組播應用形式。典型的應用包括：

媒體廣播：如演講、演示、會議等按日程進行的事件。其傳統媒體分發手段通常採用電視和廣播。這一類應用通常需要一個或多個恆定速率的數據流，當採用多個數據流（如語音和視頻）時，往往它們之間需要同步，並且相互之間有不同的優先級。它們往往要求較高的帶寬、較小的延時抖動，但是對絕對延時的要求不是很高。

媒體推送：如新聞標題、天氣變化、運動比分等一些非商業關鍵性的動態變化的信息。它們要求的帶寬較低、對延時也沒有什麼要求。

信息緩存： 如網站信息、執行代碼和其他基於文件的分佈式複製或緩存更新。它們對帶寬的要求一般，對延時的要求也一般。

事件通知：如網絡時間、組播會話日程、隨機數字、密鑰、配置更新、有效範圍的網絡警報或其他有用信息。它們對帶寬的需求有所不同，但是一般都比較低，對延時的要求也一般。

狀態監視：如股票價格、傳感設備、安全系統、生產信息或其他實時信息。這類帶寬要求根據採樣週期和精度有所不同，可能會有恆定速率帶寬或突發帶寬要求，通常對帶寬和延時的要求一般。

多點對多點應用是指多個發送者和多個接收者的應用形式。通常，每個接收者可以接收多個發送者發送的數據，同時，每個發送者可以把數據發送給多個接收者。

典型應用包括：

多點會議：通常音/視頻和白板應用構成多點會議應用。在多點會議中，不同的數據流擁有不同的優先級。傳統的多點會議採用專門的多點控制單元來協調和分配它們，採用組播可以直接由任何一個發送者向所有接收者發送，多點控制單元用來控制當前發言權。這類應用對帶寬和延時要求都比較高。

資源同步：如日程、目錄、信息等分佈數據庫的同步。它們對帶寬和延時的要求一般。

並行處理: 如分佈式並行處理。它對帶寬和延時的要求都比較高。

協同處理：如共享文檔的編輯。它對帶寬和延時的要求一般。

遠程學習：這實際上是媒體廣播應用加上對上行數據流（允許學生向老師提問）的支持。它對帶寬和延時的要求一般。

討論組：類似於基於文本的多點會議，還可以提供一些模擬的表達。

分佈式交互模擬（DIS）：它對帶寬和時延的要求較高。

多人遊戲：多人遊戲是一種帶討論組能力的簡單分佈式交互模擬。它對帶寬和時延的要求都比較高。

Jam Session：這是一種音頻編碼共享應用。它對帶寬和時延的要求都比較高。

多點對點應用是指多個發送者，一個接收者的應用形式。通常是雙向請求響應應用，任何一端（多點或點）都有可能發起請求。典型應用包括：

資源查找：如服務定位，它要求的帶寬較低，對時延的要求一般。

數據收集：它是點對多點應用中狀態監視應用的反向過程。它可能由多個傳感設備把數據發回給一個數據收集主機。帶寬要求根據採樣週期和精度有所不同，可能會有恆定速率帶寬或突發帶寬要求，通常這類應用對帶寬和延時的要求一般。

網絡竟拍：拍賣者拍賣產品，而多個竟拍者把標價發回給拍賣者。

信息詢問: 詢問者發送一個詢問，所有被詢問者返回應答。通常這對帶寬的要求較低，對延時不太敏感。

Juke Box：如支持準點播（Near-On-Demand）的音視頻倒放。通常接收者採用“帶外的”協議機制（如HTTP、RTSP、SMTP，也可以採用組播方式）發送倒放請求給一個調度隊列。它對帶寬的要求較高，對延時的要求一般。

組播技術還有許多未解決的問題，例如：組播安全、組播擁塞控制、組播狀態聚集、組播流量計費、無擁塞控制、數據包重複、數據包的無序交付等等。