网络直播，如何跳出组播的坑！

互联网上的直播，其数据传输方式都采用“单播”方式，所以大家在讨论直播技术时，少有人提及“组播”这个词。

然而，作为直播的组成部分，在广电有线电视、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中，请发送简历至邮箱：hr@bravovcloud.com

观止云公众号历史文章中有大规模P2P商用数据、全球主流流媒体服务器功能性能对比、编码器等大量技术文章介绍，有网络直播市场、技术方案等介绍，请在【往期内容】栏目中查看。想要了解更多观止云业务介绍，请点击【阅读原文】