组播（一）
从组播的角度看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层才分分辨出来，这样就比较浪费资源了，所以管理员应该避免这种情况。