網際網路上的直播，其資料傳輸方式都採用“單播”方式，所以大家在討論直播技術時，少有人提及“組播”這個詞。

然而，作為直播的組成部分，在廣電有線電視、IPTV等應用中，“組播”依然承擔著十分重要的作用。本文結合觀止雲運維處理“組播”case中碰到的一些問題，分享作為三大網路資料傳輸方式之一的——“組播”中的一些“大坑”。

1. 什麼是“IP組播技術”？

這張封面圖前段時間很火，描述的是一個主播將現場畫面通過數十個手機同時直播到各大直播APP。從該圖既能看出直播洪流的誇張、火爆，同時也有些許的無奈、諷刺，意味十足。如果拿掉多餘的手機，只通過一部手機將訊號直播到所有直播平臺，這就是“組播”典型的應用場景。

這麼說你可能會說太沒技術含量，所以小編還是從度娘那邊搬點內容來簡單介紹一下什麼是“IP組播技術”。當前的IP網路資料傳輸方式主要是以下三種：

單播（Unicast）傳輸：在資料傳送者和每一個接收者之間需要單獨的資料通道。如果一臺主機同時給很少量的接收者傳輸資料，一般沒有什麼問題。但如果有大量主機希望獲得資料包的同一份拷貝時就會導致傳送者負擔沉重、延遲大、網路擁塞，所以為保證服務質量，我們不得不增加大量的伺服器和頻寬。

組播（Multicast）傳輸：資料傳送者（組播源）將同一資料包傳送到多個接收者（組播組），無論有多少個目標地址（屬於該組播組的地址），在整個網路的任何一條鏈路上只傳送單一的資料包。組播組中的主機可以是在同一個物理網路，也可以來自不同的物理網路。

廣 播（Broadcast）傳輸：在IP子網內廣播資料包，所有在子網內部的主機都將收到這些資料包。廣播意味著網路向子網主機都投遞一份資料包，不論這些主機是否樂於接收該資料包。廣播的使用範圍非常小，只在本地子網內有效，因為路由器會封鎖廣播通訊。

比較而言，IP組播技術有其獨特的優越性，它提高了資料傳送效率，減少了主幹網擁塞，即使使用者（接受者）數量成倍增長，主幹頻寬也無需要隨之增加。下圖為組播網路資料傳輸示意圖：

2. 組播的應用場景？

雖然IP組播技術在安全性、資料丟失率、擁塞控制、流量計費等方面存在某些不完善因素，但因其在節省骨幹網頻寬上的獨特優勢，組播技術在諸多方面依然有著廣泛應用。本文僅討論組播技術在視訊直播中的應用，在視訊直播場景中，組播主要應用在廣電、IPTV的訊號源接受中。比如，某電視訊道訊號，往往通過組播方式向多個被授權的接受者同時傳送，接收方通過組播地址獲取到直播訊號。下文將通過觀止雲處理組播訊號源接收的實際案例，看看這方面都有哪些“大坑”。

3. 解決組播訊號接收問題

例項分享

（1）案例背景

某客戶使用觀止雲編碼器接受組播訊號，問題來了，使用者給出的組播地址在linux上無法接到流，在windows下用vlc卻可以正常接收流。這到底是為什麼呢？

下面我們就此案例進行簡單剖析，希望能給接組播流的朋友們提供一些參考。

觀止雲編碼器預設有2塊網絡卡，一塊網絡卡用來輸出編碼流，另外一塊用來做系統管理，網絡卡名稱分別為eth1和eth1。

eth1（IP：10.8.12.90 netmask:255.255.255.0） 連線組播網的網絡卡

eth2 (IP:192.168.100.1 netmask:255.255.255.0 Getway:192.168.100.254) 提供編碼流輸出

UDP組播地址：udp://@238.123.46.53:8001，組播源地址：192.168.193.144，接收組播網絡卡：eth1

（2）問題描述

使用者通過eth1接入組播網路，通過eth2輸出編碼流（主要是rtmp協議輸出），但是在編碼器後臺檢測流時一直檢測不到。在linux上通過ffmpeg接這個組播流也是接收不到的。

./ffmpeg -i "udp://@238.123.46.53:8001"

（3）問題處理過程

首先懷疑是不是組播地址有問題，用一臺windows的筆記本，接入組播網路，通過vlc檢視組播流是可以正常播放。

那麼問題就是出在了Linux這一端。那我們就從這一側入手解決。

從上圖看，彷彿沒有路由到組播地址，編碼器的預設路由是192.168.100.1(eth2)，那麼所有的包應該都是從eth2出去的，所以，接收不到。增加一跳路由：

注意：如果是一塊網絡卡，對於這樣的情況有一個很暴力的方法，ip route add 0.0.0.0/0 dev eth1,這樣只適用於只有一塊網絡卡的情況，組播網路和分發網路分離的情況是不適用的。

路由設定不正確，那加入組播的包就不能到達管理組播的交換機，交換機也就不知道本機器需要收組播，自然不會把組播包發過來。那麼問題得到解決了嗎 ？ NO，這麼容易就不用分享了。

一般情況下我們增加了路由或者設定對了閘道器就可以接受組播了，可是這次，組播流還是沒有接收到。

開始用tcpdump抓包：

OMG，一個包的都沒有！只有一個238.123.46.4的組播地址，過濾出來看下：

從上圖看，那說明我們配置的路由沒有問題，但是為什麼指定的組播地址就是接收不到訊號呢？

這裡就需要提到一個核心引數了：rp_filter

rp_filter是linux的用於實現反向過濾技術，它驗證反向資料包的流向，以避免偽裝IP攻擊.但是這和Linux的策略路由卻很容易發生衝突。

這個核心引數可以設定為3個值：0，1，2。預設情況Linux這個值為1。

我們可以看到當rp_filter的值為1的時候，是嚴格檢測模式，核心會嚴格檢測每一個進入主機的包的反向路徑，如果與 FIB（forwarding information base轉發資訊庫）衝突，並且，如果介面不是最佳的反向路徑，那麼包檢測就會失敗，預設情況下，檢測失敗的包會被丟棄。

意思就是核心要對從網絡卡進來的包進行方向路徑檢查，如果一個包出去的路徑和回來的路徑不一致，那麼認為這個包是非法的包，就丟棄掉了。當我們修改為0的時候就是不讓核心檢查了，雖然會有一定的風險，但是目前的環境是內外分離，所以風險不大。

修改/etc/sysctl.conf：

我們再來用ffmpeg接一下組播流就OK了，問題得以解決。

總結一下，書到用時方恨少，上面這個問題解決流程其實很簡單，①新增路由，②關閉接收組播網絡卡的rp_filter。但如果沒有這方面的積累，可能就要排查上半天了。

責任編輯 / 觀止雲PM羌人彧

觀止雲致力於打造最專業的運營級視訊雲平臺，現招募以下才俊加盟：

運維：有CDN、視訊行業運維經驗優先，Linux操作，shell、python等等語言不在話下，溝通能力強。

研發（伺服器/大資料/編碼器）、市場、售前、銷售等崗位OPEN中，請傳送簡歷至郵箱：[email protected]

觀止雲公眾號歷史文章中有大規模P2P商用資料、全球主流流媒體伺服器功能效能對比、編碼器等大量技術文章介紹，有網路直播市場、技術方案等介紹，請在【往期內容】欄目中檢視。想要了解更多觀止雲業務介紹，請點選【閱讀原文】