組播（一）
從組播的角度看OSPF
當我們在路由器上配置OSPF的時候，我們需要network 后面往往跟一個網段，這意味什么？這其實意味着兩件事。
- network我們后面跟的是網段，路由器所在這個網段的接口會向某個組播地址（224.0.0.5）發送hello報文；
- 第二件事，就是自己加入224.0.0.5這個組；
從這個角度看，每個OSPF路由器，即是服務器、也是客戶端；
在多路訪問網絡當中，當OSPF被選舉成為DR或BDR之后，接口又會加入另外一個組播組224.0.0.6，注意，僅是加入了224.0.0.6，也意味着僅僅能識別224.0.0.6，但不向224.0.0.6發送報文，DR和BDR向其它路由器通告的時，目標IP用的是224.0.0.5，因為所有其它路由器只偵聽224.0.0.5；其它路由器有消息想要告訴DR或BDR時，除了DR和BDR之外，不希望別的路由器收到，是因為只有DR和BDR會偵聽224.0.0.6.
組播初了解
我們知道報文有三種發送的方式：單播、廣播、組播。
單播就是點對點，廣播和組播有點相似，是對多的，我們不以能說組播和廣播是一對多的，因為組播除了一對多，還有多對多場景、和多對一場景 。那么他們三者到底是一種怎樣的關系？我認為組播是一種“中庸”的選擇，單播是點到點，范圍太小，有些場景是不適合的，比如一對多的場景（上課時的屏幕分享），而廣播的范圍又太大了，同一個局域網內所有主機無論想不想收到，就都會收到，而組播的出現就恰到好處的解決了這個問題，即達到了單播這種精准投放的效果，又達到了廣播這種批量分發從而節省資源的效果。
- 多對多場景，比如共享文檔，釘釘共享屏幕
- 多對一場景，監控大屏收集各地監控
解釋上面的一個名詞，這個“節省資源”怎么理解？廣播為什么節省資源，這個節省資源是對“發送者”來講的，發送者就是信號的源頭，我們后面簡稱為“信源”，還是用上課分享屏幕這個場景來講，這是典型的一對多場景，如果是使用單播，假如說是有50位同學，那么信源就要將同一份信息同時發送五十份，這樣的話對於信源也是一種負擔，同時50份數據排隊發送，也無法保證數據的即時性，一旦數據排隊，那肯定是有先有后的。組播可以實現信源只發送一份數據，其它的接收者可以同時收到。
世上安得兩全法，不負如來也不負卿。單播通過大量的機制（比如tcp保持連接 ）實現了數據的精准投放、完整性等，缺點是資源消耗過高。廣播以最小的代價在批量投放上做到了極致，缺點是不安全，不精准（廣播所有主機都能收到），無法保證完整性，組播有點偏向於廣播，但在精准投放上做了改進，但數據的完整性依然沒有得到解決。那數據完整性沒有得到解決的一個體現就是當老師在分享屏幕的時候，接收者會出現因為數據沒有完整到達屏幕卡頓的情況。
這個缺點是組播的鍋嗎？其實我們不能說組播沒有解決數據的完整性問題，這是UDP的特性，UDP是特性就是盡最大努力交付，組播使用了UDP，所以組播也擁有了UDP的缺點。廣播和組播傳輸層都是調用的是udp，所以udp的缺點，廣播和組播都有，那這種缺點可避免嗎？其實是可以的，我們可以在應用層做規避，在微信和QQ上，當我們發送短消息的時候，有時候會有一個紅色的嘆號，這是沒有發送成功，只要當網絡恢復正常之后我們再點擊一下就能發送出去的，qq、微信在發短消息時使用的就是UDP，就是通過在應用層上設計某種機制做規避，其實這樣的機制很多，比如我們通過微信視頻聊天的時候，應用層會對數據做壓縮，這種數據包就比較小，手機再發送的時候就會比較順暢，對方的畫面也會比較順暢。
- 廣播還有一個缺點，對於接收者分布在任意位置的情況無能為力，但組播就能解決。
值得一提的是，ospfv3全面廢除廣播，使用組播。
還有一點值得一提，既然組播這么好用，那現在我們經常看的直播，這是點到多點的場景，是不是就用的組播呢？按理說，應該用組播，但是中國的三大運營商在路由器均是不允許組播報文通過的，如果游戲的服務器用組播的話，就不再需要大帶寬了，以及支持大帶寬的設備了，這個影響是非常大的。
組播和路由器
路由器默認是工作在單播模式下，路由器會隔絕廣播和組播，路由器隔絕廣播這種特性除非做中繼，否則這種特性是定死的，但我們可以讓路由器支持組播並配置組播協議 ，這樣路由器就可以轉發組播報文，在路由上最常見的組播協議就是PIM。
PIM這名字有點意思，PIM（Protocol Independent Multicast）協議無關組播，PIM直接利用單播路由表的路由的路由信息創建組播路由表項，轉發組播報文。協議無關也就是說PIM是運行在路由協議之上的，路由協議你運行什么我不管，靜態也可以，在單播路由協議可達的前提下才PIM才會工作正常。
路由器隔絕廣播，這句話是真的嗎？
路由器只要有默認路由，其實路由器能轉發三層廣播報文的，但我們在實際的環境當中是看到路由順路不轉發廣播數據是因為這些廣播數據它二層也是廣播，當路由器見到二層是廣播的數據時就會直接丟棄了，路由表還沒來得及起作用。
這對於黑客來講，是相當簡單的，我搞一個三層廣播報文，但是二層搞成單播，這時候路由器就會正常轉發。
如何組播使用TCP有什么結果？
其實有人搞過TCP的組播，用於一些特殊場合，但沒有普及開。
比如語音丟包了，用TCP那會重新發送，接受者一句話要聽兩遍；
如果足球直播tcp、進球的畫面，不斷重復的話，會出大問題 。
存在的問題和角色
組播的源IP是就是普通的單播源IP，但是目標IP是一個組播組，也就是目標是一個范圍，這樣的話，在路由器上進行轉發時，可能由於報文的延時，接收者可能會收到兩份同樣的報文 ，如果報文當中傳輸的是一些控制指令，這樣有可能會出問題，所以在組播協議就必須要解決這個問題。
組播的三個角色，信源、轉發路由器、接收者，我們更多關注的是轉發路由器和接收者，因為信源往往是軟件，比如說是屏幕分享軟件，由程序員進行定義。
通過以上的內容，我們大概有這么幾點疑惑：
- 怎樣把單播路由器變成組播路由器？
- IGMP與PIM是什么關系？
- 路由器依據什么轉發組播報文 ？
- 最后一跳路由器怎么實現比較精准的投放？
- 又如何規避接收者收到兩次報文這種隱患？
PIM這種路由協議並不是唯一的協議 ，我們學習PIM的協議的原因是因為PIM簡單，用途廣泛，與PIM比較類似的協議分為兩類，我們可以類比成IGM和EGP，前者是域內的，后者是域外的，域內的有DVMRP、PIM、MOSFP、CBT，我們發現有一個MOSPF，這個OSPF與單播里面OSPF是一回事嗎？是的，我們在學習OSPF的的LSA的時候，會忽略掉6類的LSA， 里面MOSPF用的就是6類LSA，域外的組播網絡協議有MBGP/MSDP，這里也現出了BGP，沒錯，你沒看錯，這里面的BGP也是那個我們熟悉的BGP。
組播IP地址
明確幾點：
- 組播地址范圍就是D類地址范圍：224.0.0.0——239.255.255.255
- 組播地址是無法配置在路由器和主機的接口上的。
- 組播地址是沒有子網掩碼的
- 一個組播地址即是一個組播組
要記下來的組播地址 ：
- 224.0.0.1 代表網絡內所有主機，作用和廣播差不多；
- 224.0.0.2 代表網絡內所有路由器
- 224.0.0.5/6 是OSPF協議使用的（值得一提的是EIGRP是通過單播建立鄰居的，ripv1是廣播）
- 224.0.0.9是ripv2使用的
- 224.0.0.10是eigrp使用的
- 224.0.0.13是PIM使用的，用於路由器之間建立鄰居。
組播地址種類
- 永久組播地址的范圍是224.0.0.0——224.0.0.255，這類地址我們最熟悉的，比如OSPF使用的224.0.0.5和224.0.0.6就是出自這個范圍，這類地址最大的一個特定是路由器不轉發，TTL值為1.
- 224.0.1.0——224.0.1.255，永久組播地址，分配給網絡協議使用的，與224.0.0.0不同的的224.0.1.0是可以被路由器轉發的。
- 232.0.0.0——232.255.255.255 專用於SSM的組播地址。
- 239.0.0.0——239.255.255.255，私有組播地址，使用這類地址不需要申請，相當於IPV4的私有地址。
組播模型
根據IGMP接收者對組播源的控制程度不同，可以把IP組播分為三種模型：
ASM(any-source multicast)
任意源組播，組員不知道信源的地址，任意信源都能成為組播源。
無論信源發什么、有多少相同信源，組員都只能被動接收，無法對自己感興趣的信源做選擇。
SSM（sourde-specific multicast）
特定源組播，組員可以選擇只接受感興趣的信源，特定源組播與任意源組播最大的區別是任意源組播組員不知道信源的位置，而特定源組播，組員明確知道信源的位置。
SSM使用組播地址范圍與ASM不同，可以實現在接收者和指定的組播源之間建立專用的組播轉發路徑。
SFM（source-filtered multicast）
過渡源的組播，SFM和ASM是“近親”，對ASM這種簡單粗暴的工作方式進行了改進，可以實現組播員節點對於接收到了組播報文的源地址進行檢查，允許或禁止某些報文通過，從而實現過濾的目的。
我們也可以把ASM和SFM統稱為ASM。
組播MAC地址
其實我一直有一個疑問，最后一跳路由器是怎么實現精准投放的？
其實最后一跳路由器將信源交給組員的時候，目標IP地址並不是組播IP，因為組播IP是根本無法配置在設備上的，那路由器是怎么將信源交給組員呢？是通過MAC交的，接收者會根據要接收信源的組播地址計算一個MAC地址 ，這個MAC專門用於接收組播信息。
那你說，如果不生成這個MAC地址的PC會收到這個組播幀嗎？其實也會收到，只不過沒有配置這個組播MAC地址的話，即使收到組播MAC幀，在拆封裝的時候只拆到第二層就丟棄了，這一點和廣播還是有區別的，如果是廣播這個數據幀的話，會在傳輸層拆封裝的時候才會發覺，這樣一來，浪費的資源比較少。
那這個組播MAC地址怎么生成的呢？組播MAC也單播MAC一樣，也是十六進制的，前25位固定了0x01005e，低23比較是組播IP的低23位。舉個例子，如果一個主機要接收組播組229.1.2.3，那低23位是多少，010203，那整個MAC就是0x01005e010203，但228.1.2.3、229.12.9..3的MAC地址也是一樣，一旦這么多的MAC一樣，在MAC層就無法分辨是否是自己想要的流量了，就只能再往上層，要到IP層才分分辨出來，這樣就比較浪費資源了，所以管理員應該避免這種情況。