組播IP地址到底是誰的IP？

組播也是一種IP包，也有源IP地址，目的IP地址，源IP地址為組播源的伺服器IP地址，目的地址為一個特殊的IP地址，它位於 224.0.0.0 - 239.255.255.255 中，由於 224.0.0.0/8用於本地鏈路，即一跳的組播，239.0.0.0/8 為私有組播地址，所以實際的可用於在網際網路上組播地址是225.0.0.0/8 - 238.0.0.0/8，這個組播地址不屬於任何伺服器或個人，它有點類似一個微信群號，任何成員（組播源）往微信群（組播IP）傳送訊息（組播資料），這個群裡的成員（組播接收者）都會接收到此訊息。

IPTV就是組播的應用：

IPTV裡的一個電視訊道對應一個組播IP， 假設CCTV1 對應的組播IP =238.1.1.1 ，IPTV節目源IP=1.1.1.1，就以238.1.1.1 為目的地址封裝傳送，這裡有兩個問題需要解決：

IPTV組播源不知道收看此節目的使用者在哪裡？

收看此節目的使用者不知道IPTV組播源在哪裡？

使用者IPTV機頂盒只知道節目組播地址為238.1.1.1 ，至於誰是這個節目源（IP=1.1.1.1）並不清楚。

於是就引入了一個中介機構（RP），Rendezvous Point，RP點，組播的匯聚點，RP IP = 2.2.2.2 ，組播源通過單播隧道的方式把組播238.1.1.1 發給 RP，簡稱組播源的註冊。

機頂盒靜態配置了RP IP = 2.2.2.2，知道RP會有組播資料，於是就向RP（ 2.2.2.2）申請加入這個238.1.1.1 的組，於是RP就把自己收到的註冊組播源資料傳送給機頂盒，這個就是基於RP的 樹，RPT。

機頂盒收到第一個組播包，定睛一看，原來組播源是1.1.1.1，於是發一個申請給1.1.1.1 ，申請加入238.1.1.1，這就是基於源的 樹，SPT。即然已加入了SPT ，就不需要RPT 了，向RP申請退出就可以了。

著重強調一點：一旦組播使用者（接收者）知道了組播源，那RP的任務就算完成了，RP的存在就是為了組播接收者發現組播源，組播使用者會加入路徑更優的SPT樹，會申請退出路徑不是最優的RPT樹，避免收到兩份組播的複製。

以上就是組播工作的大概過程，IPTV是IGMPv2 以及 PIM SM mode 的一個應用。

IPTV是電信獨立的IP網路，部署起來很容易；但是如果在全球網路裡部署組播，將會遇到很多挑戰。

如果想了解IGMPv3 以及PIM SSM 請回復，會繼續更新。

想深入學習的童鞋請繼續
------------------------------------
IP multicast 組播

在組播的世界裡，我們又見到了樹的概念，關於樹，你一定會有似曾相識的感覺，二層交換網路就有樹的概念了，那個樹我們稱之為：生成樹，spanning tree，儘管這個樹中文名稱有點彆扭，但它就是一棵樹。

喜愛大自然的童鞋仔細觀察一棵樹，會發現一棵樹，有根，主幹，樹杈，葉子，水分通過根，源源不斷地輸送到主幹，樹杈，然後到達葉子。水分在從根擴散到葉子的過程中，一直是單向的，沒有水倒流的現象，即使水有倒流，也不會有環路，因為樹的結構是發散的，沒有物理的樹杈的交織，自然不會發生環路。

網路科學家發現了這個規律，有一個大膽設想，如果把樹的拓撲結構用於二層交換網路，在二層網路裡選擇一個根（root bridge)，其它交換機當作樹的樹杈，每個樹杈自然有一個根末梢（root port)，這個就是交換機的上游介面，除了根末梢，其它的介面都是下游介面，至於下游介面是暢通的、還是阻斷的，取決於到根的路徑成本，誰更接近根，誰就暢通（Forwarding) ，即常說的Designated Port; 誰遠離根，誰就需要被阻斷（Blocked), 即常說的 Non Designated Port。通過這種仿生的機制，可以有效地避免網路環路。

今天我們主題並不是spanning tree，而是組播樹。至於為什麼要有樹的概念，上文已經闡述，為了避免潛在的網路環路，那我們來談談組播樹的概念。

組播第一個挑戰就是組播的接收者（Receiver）不知道組播源在哪裡，換句話說，就是不知道組播源的IP地址，如果知道了，可以直接向這個IP地址傳送加入組播的請求，那一切就簡單了，組播可以直接推送到組播的接收者。這僅僅是一個美好的假設，事實是接收者無從知道組播源的IP地址。

為了克服這個困難，引入了一個中介機構（RP），Rendezvous Point，RP點，組播的匯聚點。

為了更便於闡述這個複雜的過程，假定：

Multicast Source IP: 1.1.1.1
Multicast Group IP : 238.1.1.1
Rendezvous Point IP: 2.2.2.2
IGMPv2: Host chat with Router
PIM Sparse Mode: Router chat with Router

於是組播源就把組播238.1.1.1封裝在一個單播（source IP 1.1.1.1，destination IP 2.2.2.2) 發給RP，我們稱之為組播源的單播註冊。

雖然組播的接收者不知道組播源在哪裡，但他們深深地知道，他們所在的廣播域裡的路由器一定知道，而路由器如果靜態配置RP，或動態發現RP，可以知道RP在哪裡，可以間接的知道組播源在哪裡。這就是美其名曰的：曲線救國！

於是組播接收者用IGMPv2傳送一個廣播請求，這個廣播域裡的路由器聽到了這個廣播請求，查詢自己的單播路由表，可以知道誰是通向RP的上游路由器，然後傳送一個PIM Join請求給上游，上游路由器按照相同的方式把這種Join 請求一級一級的中繼到RP，RP簡單地將收到Join請求這個介面放入組播出介面列表（OIL），然後把組播僅僅複製（Replication)一份從OIL傳送出去。PIM Join 在層層向上中繼的過程，路由器已經形成一個上下游的關係，越是靠近RP的路由器，為上游；而遠離RP的路由器，為下游。這其實就是一種樹，因為樹的根是RP，我們稱這種組播樹為基於RP的樹，即RP-Based Tree，簡稱RPT。

當組播接收者直連的路由器收到第一個組播，就知道組播源在哪裡？為什麼？因為組播包裡的源IP告訴我們的啊！於是向組播源IP發起了一個新的PIM Join請求，為什麼要這樣啊？是不是畫蛇添足啊？好，我們來分析一下：

組播先從組播源發到RP，然後再從RP順著RPT樹一級一級向下遊擴散，直到到達組播的接收者，這條路徑有點繞，因為先要繞到RP，所以不是最優路徑。既然RP的存在是為了組播的接收者發現組播源，那一旦這個任務完成了，也就沒有必要再走這條有點繞路的路徑了，為什麼不直接走組播源到達組播接收者的路徑呢？省時、省力、省路徑！於是組播接收者的直連路由器向著組播源1.1.1.1的方向，如何知道？查詢單播路由表啊，然後順著朝向1.1.1.1 的方向傳送 Join 請求，也是一級級向著上游發請求，直到到達組播源1.1.1.1，這個有上下游關係也是組播樹，因為樹的根是組播源，我們稱之為：基於源的樹，Source Path Tree，簡稱SPT。

即然加入了SPT樹，收到了組播資料，就沒有必要賴在RPT樹上，否則將會收到兩份複製，這實在沒有必要。於是組播接收者直連的路由器向RP提出leave 請求，RP將收到 leave 請求的這個介面從OIL列表裡刪掉，即不會再複製組播資料了。

忘了一個細節，RP在接收到組播源的單播註冊，會發一個單播停止訊息給組播源，即 Register Stop 訊息，既然RP已經知道組播源在哪裡了，繼續單播註冊就沒有必要了。同時RP也會朝著組播源1.1.1.1 的方向傳送Join請求，請求加入SPT樹。

例子：視訊網站在放NBA（信源），當我切換頻道到NBA後，我就是組播接收者
當然和我同時看NBA的人肯定不止一個，組播地址就是為了描述我們這一組人，組播流量最終也會推向我們這群同時收看NBA的人。

2. 加入組播組意思是通過這個有組播IP的伺服器獲取資料麼？
答：概念性錯誤，組播IP不是伺服器的IP，我前面說了伺服器的IP是單播地址

例子：伺服器裡有一個軟體，專門用來放NBA，這個軟體寫好到每天早上9點後就準時向22x.x.x.x這個組播地址去flooding視訊流量（這股流量的三層報頭裡源地址是視訊伺服器的單播IP地址，目的地址就是22x.x.x.x這個組播地址）
而22x.x.x.x這個組播地址就是我們看NBA的客戶端上寫死的頻道地址，我切到NBA的頻道，就表示我要接受22x.x.x.x的流量，沿途的網路裝置就會將NBA相關的流量給我送下來

儘量沒寫那些複雜的理論，用我能做到的簡單的方式給你解釋了（￣▽￣）
因為IGMP，PIM-DM，PIM-SM，RPF，RP，BSR，MSDP這些東西一說，都能寫一本厚厚的書了

歡迎大家留言討論更深層次的東西(=・ω・=)

接收者到終端節點採用的是IGMP技術，目前主要應用的是IGMPv2，v1和v3不去擴充套件。IGMP技術完成的主要功能就是題主問的加入組播地址的意思。要研究IGMPv2工作的機制（偷懶不分析報文了）有幾個關鍵點，目的地址（給誰發），加入的組，TTL = 1。
服務端會向目的地址（224.0.0.1），加入的組（0.0.0.0），這條報文的意思是，朋友有誰加了哪個組播組嗎？告訴我一下。
客戶端，也就是PC使用者，如果你點播了某個節目，加入了組，比方說是224.1.1.1這個組。那就是傳送報文，目的地址（224.1.1.1），加入的組（224.1.1.1）。目的地址和組是同一個的目的是為了抑制其它PC傳送同樣的報文，因為路由器已經知道這個組有人，不需要再傳送一次了。
在IGMPv2中，客戶端離組也是要發訊息的。會發一條目的地址（224.0.0.2），加入的組（224.1.1.1）這樣一條訊息，告訴服務端，我走了，你再看看其它人吧。
就簡單說這三種報文吧，想詳細瞭解時間資訊，報文包頭等內容可以留言。

好了，經過IGMP報文提供的訊息後，我們已經知道了，最終端使用者有哪幾個組，也就是說，我們需要給哪些終端的伺服器傳送哪些組播報文是已經清楚了，但從最初始的源是如何經過層層裝置到達終端的呢？幸好我們有PIM協議。
PIM協議也是很複雜，在這裡大概介紹一下。PIM模式完成的主要功能是儘可能簡單的給相應組的路由器傳送訊息。完成簡單這項功能，採用了SPT: Shortest-Path Trees or Source Distribution Tree，RPT: Shared Distribution Trees，這兩種樹型結構和DR一同完成了這項功能。正確的傳送資訊有兩種模式Dense Mode，Sparse Mode。Dense是推流模式，也就是說相當於從源端主動向客戶端路由器推送組播資訊，Sparse是拉流模式，相當是客戶端路由器從源端拉取自己想要的資訊。還有兩者結合的方式，Auto-RP這些先不說了。有需要再留言吧。

其實，IPv6對組播的支援要更好一些，但掌握點IPv4的技術總是沒有錯的，學習一個技術的歷史才能更好的瞭解它。