网络中存在各种各样的业务，从流量模型的角度去看，业务大体分为两类，第一类是点到点业务，这类业务的特点，一般情况下，不同的用户有着不同的需求，比如说FTP和Weib业务就是典型的点到点的业务，而这类业务，一般情况下，使用单播的形式去承载数据流量，帮助不同的用户去实现不同的需求，同时具有很高的安全性。第二类业务是新型的点到多点的业务，这类业务比较特殊，它一般是指不同的用户有着相同的需求，比如说IPTV就是一个典型的点到多点的业务，可能说不同的用户他想要接收同一频道的节目，这个时候应该用怎样的方式去传输点到多点的业务呢？用传统的单播和广播的形式去传输点到多点的流量，可能存在多种问题，因此就产生了组播技术，使用组播来解决单播和广播传输点到多点流量存在的问题，本单课程将介绍IP组播的相关概念。
IP组播基本概念
点到多点业务的困境
在正式介绍点到多点业务所面临的问题之前，首先需要清楚一个问题，什么是组播，组播，单播，广播，有什么区别，在网络中从IP传输报文的角度去看，将传输的流量可以分为三大类，第一种是单播，单播一般指的是主机一对一之间实现通信，在数据封装的过程中，目的MAC地址就是一个典型的单播地址，是针对某一用户而设定的，同时，沿途中间所接收的设备，根据目的地址转发，转发相应的数据流量，给接收者，来实现一个一对一的通讯。而广播一般是指一对所有的通读，数据源会将数据发送给可能存在要接收的用户，同时设备接收到这样的一个广播流量之后，除了自己的接收广播流量的端口，其它所有端口，都会将这样的一个广播流量转发出去，因此广播流量相较于单播流量而言，它不需要确定转发的路径，实现起来就更加简单。组播，类似一种一对多的通讯方式，这个多是指针对发送源而言，想要接收的用户，不现是所有者或者说是单一的用户，而是多个想要接收，特定源数据的这样的一批用户，同时和广播传输的过程中，虽然中间设备也会将数据流量进行复制，但是和广播很大不同的一点在于，它所复制的流量都是根据有效性的，选择性的，将组播数据流量从相应的接口转发出去。而广播它其实更类似于一种，广而告之，并不知道接收者在哪里这样的一个概念。这个其实有点好比小时个在操场里面，所听到的校园喇叭播放的一些节目一样，所有用户都会去接收到广播，针对安全性而言，是不是就会有问题。因此，在面对点到多点的新型业务时，使用单播和广播会产生怎样的问题呢？
使用点到多点的业务去承载数据流量时，单播，组播，广播，都可以进行传输，但是单播和广播会存在一些问题，这些问题是什么呢？使用单播去承载点到多点的业务，也就是说下面的接收者可能接触的是同一个数据流量，这个时候会发现，数据源发给接收者，它会不停的重复发相同的数据给不同的用户，这样沿途所经历的这些中间设备，它一直在转发相同的数据的数据源，给它的下游设备，这个时候不带宽就会被大量的单播流量去占用了，同时网络可能就会发生一定的拥塞，而针对中间设备而言，它可能也会产生一个问题，我为什么一直在转发相同的数据流给我的下游设备，这个数据流刚刚已经发过了，为什么还要再发一次， 它并不知道数据流是给不同的用户的，因此面对这种形势， 如果采用单播的形式去传输点到多点的业务，针对网络框架中的中间设备而言，是一个非常大的隐患，无论设备的负荷，还是链路的带宽。这个时候可能会说，有没有办法通过广播的办法去解决这个问题，看一下广播会有什么问题，广播去承载点到多点的业务数据的时候，会发现，它将数据源发送给设备之后，因为设备收到广播报文它应该是怎样处理的，正常情况下，一个设备收到广播报文之后，他除了接收端口以外的其他所有端口，都会转发出去，也就是说将这个流量进行复制，到其它端口，然后群发，这个中间的沿途设备，并没有多次复制流量，好像只发了一次，对于链路的带宽或者设备的负荷并没有那么大了，但是它最大的一个问题，在于，既然是群发的方式，有可能将这样的一个数据流，发送给非正常接收的用户，比如说，按图中的这个安全，在一个IPTV场景下去发送数据，发广播的形式去承载数据流量，这个时候可能我们IPTV客户端是正常想要接收视频源的，而中间的普通终端，它是并不想接收这样的一个广播数据源，这样以广播的形式去发，它就可能接收到广播的数据，这个数据对于他而言是他不想要的，安全性和有偿性得不到保证，假设在一栋楼里面，要去收看IPTV，这个IPTV是收费性质的，现在只有一家用户交了费用，剩下的用户并没有交钱，但是以广播的形式发这样的一个IPTV视频流量，是不是其它用户全部都收到了，这个时候对于收费的用户而言，它有有偿性和安全性，都没有得到保障，因此广播去承载点到多点业务数据流量，虽然它并没有给设备以及链路的带宽造成影响，但是对于用户而言，安全性和有偿性得不到保障，而单播去承载点到多点的业务，虽然非常安全可靠，但是对中间的设备而言负荷比较大。因此，无论是单播和广播，去传输点到多点的业务，都会存在一些问题，于是产生了组播技术去解决，在点到多点业务时，使用单播和广播所面临的困境。
使用组播承载点到多点业务
在组播的方式下，数据源从源端发给用户，沿着组播分发树，中间的设备沿途只需要发送一次，这个和单播相比，它就不再重新发送重复的流量，虽然它也会在相关的设备上将流量进行复制，从其它端口进行转发，但是这个复制是有针对性和选择性的，因为它知道这个端口下面存在想要接收组播数据的用户，只有这个用户存在时，才会将这一条的组播流进行复制，从该端口下发，如果该端口下面没有潜在的用户，这个端口是不再发放任何组播数据流量，因此，它相较于广播型而言，并没有浪费设备的资源带宽，同时在安全性和有偿性方面也得到了保障，只发给想要接收的特定用户，也就是说组播数据，可以说是将单播和广播在传输的方式中，各自的优点结合在一起，然后去承载点到多点的这样的一个业务。
问题，主机是如何去区分流量是单播，广播，还是组播呢。
组播数据报文结构
主机用户是根据IP地址用来去判断所接收的流量是一个单播流量，还是广播流量，还是组播流量。组播技术可能在别的教科书上看见它有一些别称，或者说是不太官方正式的名称。比如说多播，多址广播，其实它们都是广播的概念。这个组播他所以的IP地址是多少呢？应该知道在IPv4中，将网络分为5大类，分别是a类 b类 c类，d类以及e类。其中d类就是组播地址。地址范围是224.0.0.0到239.255.255.255。每一类地址它都会有相应的取值范围，这个取值范围不要死记硬背。记住它的定长比特位。比如说d类，它就是组播地址所在的范围。它的前4比特为1110。这个时候就可以将组播IP地址的范围推断出来。那就是224.0.0.0`239.255.255.255。会发现，组播的数据范围和单播的报文是类似的，只不过在封装方面有所区别。所封装的目的IP地址，不再是一个普通的单播地址，正常情况下，a类,b类,c类就是一个单播地址。封装的是一个组播的IP地址，相对就的目的MAC地址也是一个组播的MAC地址，但是这里有一个非常大的问题，源IP地址依然是单播地址。
因为这个组播地址指的是发送一个数据流给一个组播地址，但是这一个组播地址，可以代表着多个用户都能够同时接收，而源一般情况下是指独立的设备，因此它是一个单播地址。目的IP是组播地址，它所在的范围是224.0这个网段，组播MAC地址它又是哪个网段呢？
组播IP地址
关于IP地址的分类中，224.0.0.0/4这个网段，所在的D类地址，就是一个组播地址的集合，在这个组播地址集合里面，以将地址进行了分类，进行了进一步的定义，224.0.0.0`224.0.0.255,这个是为路由协议所预留的永久组播地址，也就是说，这个范围所存在的组播地址，已经不能是人工正常干预的了，已经是给路由协议分配好了，比如说在学习OSPF中，有两个IP地址，分别是224.0.0.5和224.0.0.6这两个地址，会经常出现在OSPF报文里面，作为组播的目的IP，这个就是为路由协议所预留的，其中224.0.0.5，是OSPF发送Hello报文的组播地址，而224.0.0.6，是DR和BDR发送报文的组播IP地址。
Any-Source临时组播地址，任何一台设备，临时想要成为组播数据源，它就可以使用这个范围内的一个地址，用来标识组播，第三个Source-Specific，指定源的一个临时组播地址范围，所谓的指定源就是，指定某台设备作为数据源的发起者，可以临时用这个范围内的地址，进行发送。最后一个是本地管理的一个任意源临时组播地址。
现网中常见的业务，比如说IPTV，语音会议都是采用组播的地址，进行发送的。
组播MAC地址
刚才在前面的课程中介绍了D类IP地址，它属于一个组播IP地址范围，组播MAC地址它又是怎样生成的呢？组播MAC地址，实际上和组播IP地址它具有一定的关联性，存在着映射关系，这个映射关系是什么呢？组播IP地址有前4个比特固定为1110，而MAC地址一共48比特，而组播MAC地址规定前面25个比特为固定的，再往后面看，剩下的组播的MAC地址后面还有23比特，因为MAC地址一共有48比特，前25定长，后面还剩下23比特，这23比特怎么来的呢？将一个组播IP地址的后23比特，映射到组播目的MAC地址中，形成了一个映射关系，这样就标识成了一个组播目的MAC地址。这样会有什么问题呢，前4个比特为1110为固定的，后23比特映射到组播MAC地址中，中间还剩下5个比特的信息丢失，所谓5比特信息丢失指的是和组播MAC地址并没有任何映射关系。也没有某个固定某个取值的关系，因此会产生什么问题。只要组播的IP地址后23比特相同，中间的5个比特不同，是不是就有可能造成不同的组播IP地址映射到同一个目的的MAC地址中，那是不是就有可能造成32个组播IP地址映射到同一个组播目的MAC地址中，只要你的后23比特相同就可以了。但是IETF组织认为在同一个局域网里面，多个组播IP地址，映射同一个目的的MAC地址的概率性非常小，它认为可能是千万分之一这样的概率，因此忽略不计。其中，组播的目的MAC地址，前25比特是固定的。
组播网络的基本架构
组播网络整体架构一共分为三个部分，其中，最简单的部分是一个源端网络，由源端网络，转发网络，以及成员端网络三大部分组成。其中源端网络指的是组播数据源的产生，它的产生是指组播源，比如说一台服务器，它就将组播数据，推送到整个转发网络中，后续就不再做任何管理和操作，所以说对它而言是比较简单的，然后整个组播转发网络，它所存在的范围，是组播第一跳路由器，到组播最后一跳路由器，这么大的一个范围，组成的这样的一个网络区间，什么是组播第一跳路由器和组播最后一跳路由器呢？组播第一跳路由器指的是第一个接收组播源推送下来的数据流这一台路由器。组播最后一跳路由器指的是，这台路由器会将这样的一个数据流，给下面的用户进行转发，也就是说，这台路由器下面连接的是接收者，这个中间，就构成了整个组播的转发网络，在整个组播转发网络里面，会沿着组播分发树传播这样一个组播流量，同时要运行相关的组播路由协议，去解决可能存在的一些环路问题，在整个组播转发网络里面所运行的协议是PIM协议。而最后一跳路由器和用户，也就是说想要接收组播数据的成员，所组成的是成员端网络，成员端网络，也就是最后一跳路由器，它是用来管理接收者想要接收的数据，成员端网络通过IGMP这个协议，来实现对下面的接收成员管理，以及想要加入的这样的一个组播组。组播这个IP地址，它代表的一批想要接收的用户，同时一个用户能够接收不同组播的流量。
组播服务模型
组播服务模型，一共分为两大类，根据组播数据源，进行区分服务模型。
第一种叫做ASM，这个指的是任意源，就是说组播组成员，它能够接收任何源产生的组播报文，但是，在ASM模型里面，如果把它细化的话，其实又分为两小类，第一种就是传统的Any-Source Multicast，第二种可以理解为它是一种特殊的ASM，又称它为FSM，叫做过滤源，可以在相应的组播路由器上过滤或者允许或者拒绝某些组播数据流量的转发。只发送想要发送的源的数据流量，将它的流量推送给组播成员，也就是说针对组播源进行了一个过滤，它其实一种特殊的ASM。第二种是SSM，这种一般叫它指定源，指定源是指可以在接收者上面去指定它只感兴趣的那一台数据源的组播流量。其他源产生的组播流量不再接受。这两种模型主要是根据所接收原组播源来自于哪个位置所进行区分的。
组播数据转发原理
组播数据转发的困局
组播数据在转发时候，是需要依赖于路由表的，但是如果基于目的网络的路由表在转发数据时，又会存在着一些问题。假设路由器接收到组播源发送过来的组播报文，它的出接口有两个接口都需要转发组播报文，路由器收到组播报文之后会复制流量，但是不同于广播的是，这个流量复制是指它知道下面存在接收者，它就会将这个流量复制到接口，然后下发给它的下游路由器，而组播成员 在整个网络中可以说是无处不在的，只要路由器感受到接口下面存在着接受者，就应该将这个组播流量复制一份到接口上，然后往下游去转发。按图中的案例，实际上路由器左边这个接口下面存在接收者，是这台PC，而右边这个接口下面也存存一台接收者，是这个PC。但是对于这台路由器而言，它并不知道这个接收者是同一个用户，它只要感受到下面有想要存在接收组播浪漫流量成员在，就应该将流量复制到我的接口上，然后向下游传递，路由器接收到组播流量之后，通过其它端口进行转发，然后流量会形成转发环路，第二个，针对组播组成员而言，它接收到了相同的组播数据流，从不同的路径中。接收者，从不同的路径中接收到了相同的报文，这个时候就产生了重复报文。第二个问题有可能产生次优路径，同理，路由器收到组播报文之后，通过不同的接口转发这样的一个组播报文，按图中的案例，实际上，接收都直接从RT1到RT3,接收到这个报文之后是最优路径，但是从R1,R2,R3这条路径，又接收到了一个组播报文，不仅可能会造成重复报文，同时这条路径是一条次优路径。因此，会发现，基于普通的单播路由表，去转发这样的一个组播数据流量，会产生严重的问题。
组播路由与RPF检查
RPF反向路径检查
这个检查是指，设备仅转发从特定接口收到的组播数据流，避免了转发中所产生的环路次优路径，以及重复报文等。
(192.168.0.2,239.0.0.1)（S,G）,S代表的是组播源，组播源是一个单播的IP地址，不能用组播IP地址去表示，G，就是发送的组播目的IP地址，Upstream Interface：GigabitEthernet1/0/0，这个就是想要确定的唯一入接口，从该接口接收到的组播报文，才是最合理的。下面是下游接口。如何去确定这个唯一接口，那就是通过RPF，反向路由检查来确定，比如说这样的一个路由器RT3，从接口接收到了组播流量之后，它会进行查看，RT3通过RPF,反向路径检查，确定了入接口是IF1，这个时候从其它接口收到了组播流量，将接收到组播流量存在的端口和入接口进行对比，如果不是该入接口，会直接将流量进行丢弃，避免了问题的产生。按图中的案例，明显从R1,R2和R3这样的一条路径，转发过来的是一条次优路径，这个时候从2口接触到了组播流量，将2口和入接口1进行对比，发现它并不是我想要的入接口，因此从该接口接收到的组播流量就会直接被丢弃。如何确定这样的一个接口呢？
RPF检查工作原理
当路由器接收到一个组播数据流之后，会查看组播源对应的单播路由对应的出接口。组播源是用单播地址来代替的，这个时候在保证路由器IP路由可达性的情况下，存在着一条去往源设备的优路径，是通过单播路由协议计算出来的，这个单播路由协议指的是前面学习的OSPF,IS-IS，或者说静态路由，从该接口发出去到达组播源的最优路径，是不是代表从组播源发送的流量到达该设备，这条路由也是最优的，去往组播源路由的该接口为想要的入接口，然后将接收到的组播报文和确定后的入接口进行对比，如果接口信息一致，就正常接收组播报文，然后进行转发，如果不一致，就直接丢弃。以RT3来说，回顾一下它的工作机制，它接到了组播源IP地址后，查看这样的一个组播源IP地址，然后计算单播路由表里面去往这个源IP的最优路径所对应的出接口，这个出接口就是RPF检查里面想要确定的最优的入接口，然后这个时候将其它接口所收到的组播数据信息里面，所存在的接口进行对比，如果和所检查的这样的一个入接口信息是一致的，那就检查通过，如果不一致，就直接丢弃。
RPF路由选举规则
RPF路由分别是从单播路由，MBGP路由以及组播静态路由中去产生的，MBGP路由以及组播静态路由还没有深入学习，也没有关系，但是要知道它是从这三个路由里面产生的。当路由器收到组播流量去查看里面的组播源IP之后，就会在路由表中去查看相应的表项，通过这个表项去确定里面的出接口，如果表中都包含了这样的一个RPF最优路由，依然三个条件，第一个掩码长度，第二个路由优先级，第三个根据路由表所存在的排序，组播静态路由>MBGP路由>单播路由，然后选择一个最优的RPF路由，从而确定出接口，后面根据接收到的组播数据源进行对比，来确定哪一条是最优路径。其实这个RPF检查相当于
RPF检查的本质是为了解决组播数据在依赖单播路由转发中所存在的次优路径，环路问题和重复数据包，但是，RPF恰恰是利用了单播路由表，去选择一条最佳的路径来接收和处理组播流量。RPF通过利用单播路由协议的特征，然后去确定组播源的入接口，为组播数据流量确定一条最优路径，来实现路径的转发，而不需要通过自己再产生一个新的路由协议来确定路径，因此它可以说是一种利用的关系。
组播分发树
组播数据转发需要保证转发路径无环，无次优路径且无重复包，形成一个完美的组播分发树，这样组播分发树就会以源为根，其中叶子节点为转发路径，实现从源到终端设备，沿着组播分发树进行转发，同时没有环路的产生。
组播数据转发流程
首先组播数据源将数据推送到第一跳路由器，也就是说到达的组播网络中，这个时候路由器会进行一个RPF检查，RPF检查通过，正常接收和处理组播数据流量。这个时候会有一个问题，会将第一跳路由器里面所接收到的组播流量转发到最后一跳路由器，如何去确定这个组播分发树呢。第二个最后一跳路由器要将这样的一个数据发送给相应的接收者，如何去确定组播成员位置，和如何判断哪些用户要接收组播流。
组播协议介绍
在整个组播网络的框架中，包含了多个组播协议，共同完成了整个组播网络的架构，其中IGMP是用来实现成员端网络之间的管理和确定接收者。而在整个组播转发网络中去建立分发树的协议有很多，比如说PIM协议，MSDP，MBGP，这个时候就比较复杂了，如果说组播流量是跨域的话，还要跨域帮助去传输组播流量，因此，会发现这三个组播转发网络协议，分别应用的场景是单域的组播分发树，帮助域间去建立组播分发树和跨域流量进行RPF校验。因此，所学的组播技术还没有完整。