组播原理详解Word文档下载推荐.docx
《组播原理详解Word文档下载推荐.docx》由会员分享，可在线阅读，更多相关《组播原理详解Word文档下载推荐.docx（16页珍藏版）》请在冰点文库上搜索。
客户数目很大的时候，媒体流服务器就有可能承受不了，因为这种
媒体流跟传统的窄带业务（比如HTTP等）不同，它需要很高的带宽
来传输，而且服务器还必须维护每个客户的信息；
严重浪费网络资源，相同的数据可能在网上传播了很多次，在一些
带宽较低的链路上，可能引起严重的通信瓶径。
在这个时候，我们自然而然的想起了组播。
这种技术最适合上面的这些新型业务。
因为组播通信有下列优点：
媒体流服务器不必知道某个客户端的存在，它只管把媒体流以组播
地址播放出去即可，而且仅仅播放一份；
媒体流数据在网上仅仅传送一份即可，即使有成千上万个客户端；
客户端不必向媒体流服务器注册，如果想接收某个媒体流服务器的
数据，仅仅加入该媒体流服务器所播放的数据所在的多播组即可。
组播技术从提出到现在，它的一些标准和技术已经相当完善了，但推广还不是十分广泛，尤其是在我国，人们对组播的认识还处于一个朦胧的阶段，更谈不上规模应用。
为了让大家尽快的了解组播技术，我们在本文中给出一些学习指引，主要有下列内容：
组播基础概念，这些概念是深入学习组播的最基础的东西，如果对这些基础概念不了解，学习组播将是一句空话；
流行组播协议，在文中我们不具体分析哪种组播协议，而给出组播协议的一些共性，并列举了目前比较流行的组播协议和它的应用场合；
列举了一些参考资料，这些资料按照不同的读者层次列举，既有面向组播专家的高级论题，也有面向初学者的入门文章。
总之，本文是面向组播初学者的，如果你从没有接触过组播技术，那么仔细的阅读本文并掌握介绍的一些基本概念，然后参考文中列举的其他文章，将会是一种良好的学习路径。
如果您是一位组播技术方面的专家，阅读本文也不无裨益，您可以从不同的角度来了解组播的基础概念，也可以参考文中提到的其他组播文章，相信对您也是有好处的。
第二章?
二层组播基础概念
在前面的介绍中，我们讨论了用多播的方式解决新型流媒体业务的好处，在该部分中，我们结合一个实际的网络给出一些多播的基础概念，掌握这些基础概念是深入掌握多播技术的前提。
2.1网络实例
有下面一个网络需求：
在图中，媒体流服务器通过以太网交换机LSWA，跟核心路由器GSRA连接起来，并启动流媒体进程，不断的以多播IP地址发送媒体流。
GSRA和GSRB之间采用以太网连接起来，GSRB通过以太网交换机LSWB连接了许多终端，其中两台终端需要媒体流服务器播放的媒体流。
下面我们仔细分析每一个步骤，在分析的过程中引入并介绍一些基础的组播概念。
2.2组播MAC地址和组播IP地址
在前面的介绍中，我们提到了媒体流服务器不断的以多播IP地址发送媒体流，这个IP地址就是一个多播IP地址。
按照IP协议规定，位于范围内的IP地址都是多播地址。
所谓多播地址，实际上是一个逻辑的概念，在网络上，没有一个计算机的IP地址是一个多播IP地址，多播IP地址仅仅代表了一个逻辑的组，加入该组的终端设备可以以该组所在的多播地址为目的IP地址来发送数据，这时候，发送的数据不是针对某个具体主机的，而是针对一组机器，想接收这个多播数据流的计算机，只要倾听接收到的每个数据报，判断该数据报的目的IP地址是不是组播组的IP地址即可。
若是，则接收，否则丢弃。
为了更好的理解组播IP地址的概念，我们举一个例子，如下面的网络图所示：
主机A（最左边的一台计算机）不断的以组播IP地址发送数据，这时候主机B（中间计算机）想接收组播组的数据，于是它就会监听每个收到的数据报，判断该数据报目的IP地址是不是，如果不是则丢弃，如果是则接收下来送到上层处理。
这里牵涉到了一个问题：
主机B的哪个模块判断接收到的数据报是不是组播数据报，并且是不是针对组的数据报？
答案是主机B的IP模块。
我们看一下一台计算机接收数据的过程：
数据链路层把接收到的数据帧剥掉链路层头后送给IP层（至于数据链路层怎样接收数据帧，在后面会详细探讨）；
IP模块维护一张接收列表（该列表是IP地址组成的结合），每当接收到一个数据报（链路层送上来的）后，便把数据报的目的IP地址提取出来，然后跟接收列表中的每个IP地址比较，如果有一项匹配，则接收该数据，并向上层传送，否则丢弃；
如果一台主机想加入一个多播组（加入与否由上层应用决定），比如你想看网络电视频道，这时候你需要启动一个应用程序，并告诉该应用程序网络电视频道的组播IP地址，该应用程序就会向IP模块注册，请求加入组播组。
IP模块于是在自己维护的接收列表里添加一项（同时也告诉数据链路层自己加入了一个组播组，并附带上组播组地址），添加的这项就是组播组的组播IP地址。
这样每当接收到目的地址是该组播IP地址的数据报的时候，IP模块就接收下来，并向上层传送。
4。
如果一台主机想退出组播组，比如你终止了电视频道接收程序，于是该程序在退出的时候会告诉IP模块，自己不再接收组播组的数据，并告诉IP模块组播组的组拨IP地址，于是IP模块就把该组播地址从接收列表中删除，这样以后如果再接收到该组播组的数据报的话，因为接收列表里没有匹配的项目，所以IP模块就丢弃该数据报。
经过上面的分析可以看出，问题的关键在于IP模块维护的接收列表。
通常情况下（主机没有加入任何组播组），该列表里只有两项，即主机自己的IP地址和广播IP地址（），这样主机只能接收针对自己的数据报和广播数据报。
细心的读者可以看出一个问题，就是数据链路层如何接收组播数据帧呢？
原来，数据链路层的接收过程跟IP层原理一致，即数据链路层也有自己的接收列表（不过该列表的内容不是IP地址，而是MAC地址），每当IP模块收到上层应用的加入组播组的请求之后，IP模块就会向数据链路层通告（上面提到过），通告的时候携带了组播组的IP地址，于是数据链路层就会把IP地址进行适当的变换，变换的结果就是一个组播MAC地址，于是数据链路层把这个组播MAC地址插入自己的接收列表里面，以后每当有数据帧到来的时候，数据链路层就会把数据正的目的MAC地址跟接收列表里的每项内容进行比较，遇到任何匹配的一项就接收下来，并向IP层传送。
这样又引出了两个问题：
数据链路层如何区分单播MAC地址跟组播MAC地址？
数据链路层做一个IP地址跟组播MAC地址的影射，这个影射是怎样的？
首先解释第一个，一般情况下，单播MAC地址的最高字节的最低比特为0，而组播MAC地址的最高字节的最低比特为1，如下所示：
这样数据链路层就可以根据该比特判断收到的数据帧是不是一个组播数据帧。
下图是第二个问题的答案：
从可以看出，MAC地址跟IP地址的低23比特是对应的，比如IP模块告诉数据链路层软件，自己加入了一个组播组，则数据链路层形成一个MAC地址01--00--5E--0A--0A--0A（取组播IP地址低23位，高位为上面介绍的规则），并加入接收地址列表中。
到此为止，我们分析了网络层和数据链路层对组播的处理过程，为了更加深理解，我们举一个实际中的例子，还是同样的网络拓扑：
假设图中从左到右计算机依次叫做PCA，PCB，PCC，并假设PCA上运行媒体流服务器发送程序，以组播地址来不停的发送电视频道数据流。
开始的时候，PCB和PCC都没有接收该数据流，于是在PCB，PCC的数据链路层和网络层的接收列表中都没有针对组播地址的接收项，从而当数据链路层接收到一个数据帧，该该数据帧的目的MAC地址是01--00--5E--0A--0A--0A的时候，因为接收列表中没有该地址，所以在数据链路层就被丢弃（到这里，读者应该能体会到，组播数据在数据链路层就可以被隔离，而广播数据则必须到达网络层才能判断出是否需要丢弃，这也是使用组播而不使用广播的最大好处）。
这时候，假设PCB计算机的一个用户想收看网络电视频道了，于是该用户启动一个程序（比如，WINDOWS平台下的WMPLAYER），并告诉该程序接收组播组的数据流。
于是发生下列事情：
该应用程序通过操作系统调用接口（API函数）告诉该PC机的IP模块，自己想接收组播组的数据（也就是说要加入组播组）；
IP模块接收到该加入请求后，便把组播组地址加入自己的接收列表中，同时向数据链路层发送一个请求，告诉数据链路层自己想接收组对应的数据流；
数据链路层接收到IP模块的这个请求后，根据组播MAC地址跟组播IP地址的影射规则，把组播IP地址影射成组播MAC地址01--00--5E--0A--0A--0A，然后加入自己的接收列表，到此动作完成。
完成上述动作后，PCB就可以接收组播组的数据流了。
如果这时候用户不想继续看网络电视了（比如用户关闭应用程序），则应用程序在退出的时候会通知网络层，自己退出组播组了，于是网络层会把自己的接收列表中项删除，并通知数据链路层删除相应的列表项目。
到此为止，我们对组播IP地址跟组播MAC地址做了个详细的介绍，并详细分析了各个协议模块怎么处理组播数据的。
这部分内容特别重要，如果还是不明白，请再读一遍，或者参考其他的书籍。
2.3二层组播协议
在上面介绍的几个例子中，我们使用了以太网交换机连接许多主机终端，并假设以太网交换机按照广播的形式发送组播数据，即以太网交换机每当接收到一个组播数据报，就向所有的端口上转发（除去接收端口）。
如下所示：
还是原来的命名规则，计算机从左到右依次为PCA，PCB，PCC。
这样当交换机从PCA所在端口接收到PCA发出的组播数据帧后，就向PCB，PCC所在端口转发。
这时候假设PCB在接收组播数据流，而PCC没有接收组播数据流，于是PCC就可能接收到一些多余的数据（虽然这些数据在数据链路层就被隔离掉了，但毕竟不是理想的做法）。
理想的做法是，交换机只向需要组播数据的端口设备转发组播数据流，比如PCB需要数据，则仅仅向PCB转发。
回忆我们以前讲解以太网技术的时候，曾经讲解了交换机的转发过程，交换机是根据内部的一张CAM表来做出转发决定的，我们可以从概念上理解CAM表是这样构成的：
{目的MAC地址，出口集合}，在单播情况下，交换机根据数据帧的目的MAC地址查找CAM表，找到一个出口（在单播情况下，出口集合中只有一个元素），然后把这个数据帧从该出口转发出去。
交换机上的这个CAM表同样适用于组播的情况，这时候，目的MAC地址就是一个组播MAC地址（其特点和形成过程严格按照前面介绍的规则），而出口集合就可能不是一个元素了，可能是多个元素的集合。
还是假设上面的例子，假设开始的时候只有PCB接收数据，则交换机创建一个转发项（01--00--5E--0A--0A--0A，{B}）（假设PCB连接交换机的B端口），并按照该转发项转发组播数据流，这样PCC就不能收到无用的数据流了。
这时候假设PCC也加入了组播组，于是交换机修改自己的转发表，把转发项（01--00--5E--0A--0A--0A，{B}）修改成（01--00--5E--0A--0A--0A，{B，C}）（假设PCC连接交换机的C端口），这样每当交换机从PCA接收到一个数据帧，就根据这个转发项，复制成两份，一份给PCB，一份给PCC。
大家对交换机上的组播转发项已经很清楚了，这时候又一个问题出现了：
交换机根据什么创建组播转发项，并对组播转发项的出口集合做出修改？
回忆单播的情况下，交换机是根据学习来获得单播转发表的，在组播情况下，学习能否奏效？
其实在组播情况下，学习是不行的，因为在单播情况下的学习，是针对数据帧的源MAC地址进行的，而组播MAC地址不可能出现在数据帧的源MAC地址位置上（组播MAC地址出现的唯一位置就是数据帧的目的MAC地址），所以根本无法学习。
这时候我们必须想一些其他办法来解决该问题，这些办法就是二层组播协议。
第一种办法，也是最容易理解的办法就是GMRP（通用组播注册协议），该协议需要计算机的网卡的配合。
该协议这样运行，每当计算机加入一个多播组的时候，计算机同时给交换机发送一条GMRP加入消息，该消息携带的内容之一就是计算机加入的组播组的MAC地址。
这样交换机会根据不同的情况而采取不同的动作：
如果交换机上没有创建针对该组播MAC地址的转发项，则创建一个转发项，把出口集合初始化为连接发出请求的计算机的端口，以后就根据这个转发项进行数据转发；
2，如果交换机上已经有了针对该组的转发项，则交换机仅仅把连接发出GMRP加入请求的计算机端口加入转发项的出口列表里面即可。
这种方式简单明了，容易理解，但需要计算机网卡驱动程序的支持，目前来说，很少网卡能有这种能力，所以应用不是很广泛。
另外一种应用很广泛的协议是IGMP窥探，这种协议是建立在IGMP协议上的，在介绍这种协议之前，我们先介绍一下IGMP协议。
所谓IGMP，即INTERNET组管理协议，是用于主机跟路由器之间交互的一种协议，为了说明这种协议出现的背景，请参考下面的图示：
一般情况下，路由器是不转发组播数据流的，即路由器假设自己的本地网络上不存在组播数据流的接收端，这样的假设是符合实际情况的。
在图中，媒体流不停的发送电视频道数据，这些数据被路由器阻隔，所以到达不了本地网络。
假设本地网络上有一台计算机想接收该媒体服务器发出的数据流，这时候该计算机必须告诉路由器自己的需求，这样路由器才能把组播数据流引入本地网络。
计算机告诉路由器使用的这种协议就是IGMP协议。
IGMP协议目前已经发展到了第三版，在这里我们仅仅对第一版做一个简单的讲解，其他版本跟第一版相差不大，可以参考相应的书目。
IGMP协议第一版主要有两种消息：
主机加入消息和成员查询消息，这两种消息分别从主机和路由器发出。
其中，主机加入消息是计算机用来告诉路由器，自己想加入某个组播组的，而成员查询消息是路由器发出，用来查询网络上是否还有某个组播组的成员的。
以上图为例，分析一下IGMP协议的运行过程：
本地网络上的一台主机加入了一个多播组G，于是该主机发出一个IGMP加入消息给路由器，告诉路由器自己想加入组播组G，于是路由器开始从上游引入组播组G的数据到本地网络；
路由器转发组播组G的数据一段时间后，会发出一个查询消息，看网络上是否还存在组播组G的成员（因为有可能刚才加入的那台主机已经退出组播组了），加入组播组的成员要重新发布IGMP加入消息来作为成员查询消息的响应，如果没有组播组的成员了，路由器将收不到响应，这时候路由器将再次进行查询尝试，如果还没有主机应答，路由器就认为网络上已经没有针对组播组G的主机了，于是停止转发组播组G的数据；
路由器发出组播组成员查询消息后，只要收到一台主机的响应，则路由器就必须继续转发组播组G的数据，不能因为网络上接收端的数目少而停止发送。
这样IGMP协议就很清楚了，我们来看一下IGMP窥探协议是怎样工作的。
IGMP窥探是这样的，交换机分析每个接收到的组播数据帧（IGMP加入消息是以组播方式发送的），看该数据正是否是一个IGMP加入消息，如果是，则从该消息中就可以判断出发出该消息的主机想加入的组播组，根据该组播组的IP地址形成组播MAC地址，并把接收到该消息的端口加入出口列表，这样一个组播转发项就创建完成了。
完成之后，交换机把刚才拦截的IGMP消息再不加改变的转发出去。
这样不停的窥探，交换机就可以掌握网络上的组播成员情况，并反映在自己内部的组播转发表里，以后就根据创建的组播转发表来进行数据的转发。
IGMP窥探存在一个严重的问题，就是交换机必须分析每个组播数据帧，判断该数据帧是否是IGMP加入消息，如果是，则进行进一步分析，否则转发。
这样对一些低性能的交换机来说，是一项很繁重的任务，所以该协议不适合低端交换机，而适合一些核心层的骨干交换机。
到此为止，一些二层的组播协议我们都做了个大体的介绍，相信读者读了这些介绍后，应该对这些协议有个大致的了解了，详细的了解以及一些具体的配置命令请参考相应的书籍。
第三章?
三层组播基础概念
在前面部分的介绍中，我们集中在了对二层组播基础概念的介绍上，在本章中，我们引入一些三层组播的基础概念，在这些概念的基础上，简单介绍目前流行的组播路由协议（注意跟二层组播协议的区分）原理及应用场合，使读者对这些协议有个大致的了解，并为以后详细学习这些组播路由协议打下基础。
3.1组播转发项，组播树和RPF检查
为了引入这些概念，我们首先看一个实际的网络图：
在该图中，路由器MR1连接了一台多播数据源，该数据源不停的播放多播数据，MR2和MR3连接的本地网络都有数据接收端，MR4的本地网络没有数据接收端。
这样MR1在转发多播源数据的时候，就只需向MR2和MR3转发即可，没有必要再转发给MR4。
这样我们可以通过在路由器MR1上创建三层转发项来完成，三层转发项可以是这样的结构：
（S，IIF，G，{S0，S1，...}），其中S是组播数据源的IP地址，IIF是到达组播源S所使用的接口，即在单播方式下，路由器如果要给组播源S发送数据，则通过IIF接口发送，而G则是组播组地址，{S0，S1，。
。
}是一个出口集合。
这个转发项的含义很明确，就是当路由器接收到一个数据报后，把这个数据报的源IP地址和目的IP地址（该目的IP地址是一个组播地址）读出来，跟转发项匹配，如果有一个转发项的源地址跟组播组地址相同，则把这个数据报向出口集合中所有的接口转发（需要注意的是，在把数据包发送出去之前，还需要进行一个RPF检查，只有通过了才转发，否则丢弃）。
网络上所有路由器的三层组播转发项串接起来，就构成了一棵组播转发树，比如，在下面的图形中，MR1的组播转发项为（S，E0，G，{S0，S1}）（其中S0，S1连接MR2和MR3路由器），MR2组播转发项为（S，S0，G，{E0}），MR3组播转发项为（S，S0，G，{E0}），这样就构成下面的树状结构（以红色线条标出）：
可以看出，这棵树是以数据源为根的，所以叫做源组播树（还有一种组播树叫共享组播树，后面介绍）。
组播数据就是沿着这棵树向下流动的。
在介绍了组播转发项和组播树之后，我们看一个在三层组播中的一个非常重要的概念：
RPF（反向路径转发）检查。
为了解释RPF检查提出的原因，请参考下面的示例：
在这个简单的网络结构中，流媒体服务器不断的发送出组播数据流，这样跟流媒体服务器连接到同一个以太网交换机上的两个路由器就都会接收并转发该组播数据流。
于是一个问题出现了：
路由器MR会从两个接口S0，S1上分别收到相同的组播数据流，这个时候MR选取哪个组播数据流并进行转发呢？
如果MR把两个组播数据流都进行转发，肯定是不合适的，假设组播数据流是一个电视频道，这样必然引起图象的重复出现，严重影响画面。
于是我们可以这样选择：
选择一个组播流，该组播流从组播源到路由器经过的路径最短。
比如在上面的网络中，我们让路由器MR选择从接口S0进入的组播流，因为S0直接连接了组播数据源，而S1的组播数据源则经过了另外一台路由器。
然而路由器怎样知道从哪个接口进入的数据流是最近的呢？
答案是查找单播路由表。
到此为止，大家对RPF检查的背景一定有印象了，下面我们给出RPF检查的定义：
支持组播的路由器每当接收到一个组播数据报，首先把组播数据报的源IP地址提取出来，然后根据这个源IP地址查自己的单播路由表，查找的结果是一个接口，如果该接口跟接收到报文的接口相同，则根据多播转发表来转发该组播数据报，如果不相同，则丢弃该组播数据报。
RPF检查是三层组播中一个最重要的特性，正是它的存在，才把组播转发表和单播转发表结合了起来，在进行组播数据转发的时候，把单播转发表作为参考依据。
而且RPF检查确保了到达的数据流不会重复，也确保了到达的数据流对网络的影响最小（因为数据流是通过最短的路径过来的）。
3.2组播路由协议
在上面我们介绍了组播转发表的概念，组播路由器在进行组播数据的转发的时候，就是依该转发表为基础来进行数据转发的，需要注意的是，在进行组播数据转发的时候，还需要做一个重要的动作：
RPF检查。
现在的一个问题是：
组播路由器上用于组播数据转发的组播转发项是如何建立起来的？
答案是组播路由协议。
跟单播路由协议一样，组播路由协议用于建立路由器上用于组播数据转发的组播转发项。
目前常用的组播路由协议有DVMRP，PIM-DM，PIM-SM等。
在介绍这些协议之前，首先引入两个概念：
剪枝和嫁接。
考虑下面的图形：
组播路由器MR从接口S0，S1上分别接收到组播数据，然而经过RPF检查后，S1上接收到的组播数据被丢弃了，因为在单播路由表中通往流媒体服务器的接口是S0。
但是RPF检查是发生在MR上的，连接MRS1接口的路由器（假设为RT1）却不知道MR不需要从自己那里接收数据流，因而一直不停的把数据流发给MR。
这样不但浪费链路带宽资源，而且浪费MR的系统资源，因为MR路由器必须做RPF检查。
因此，一个有效的办法就是让RT1停止从该接口上转发组播数据流，这可以通过一个特殊的消息—剪枝来解决，具体过程是这样的：
当MR路由器从接口S1接收到组播数据报后，马上进行RPF检查，如果失败，则MR路由器丢弃接收到的组播数据报，并通过S1接口给上游路由器（在这里就是RT1）发送一个剪枝消息，告诉上游路由器停止转发该组的数据。
这样当RT1接收到这个请求后，就不再从该接口转发数据流。
RT1是通过修改自己内部的多播转发表来做到这一点的，回忆一下多播转发表的结构，RT1路由器仅仅在多播转发表的出口集合中把相应接口删除即可。
了解了剪枝消息后，嫁接消息就很简单了，它跟剪枝消息刚好相反，是用来通知上游路由器，让上游路由器把组播数据转发给自己，比如，在上面的图形中，MR路由器的接口S0由于某种原因DOWN掉了，这时候MR路由器会通过S1接口给上游路由器发送一个嫁接消息，接收到该嫁接消息后，RT1路由器回重新发组播数据流给MR路由器（通过在多播转发表中把连接MR路由器的接口加入出口集合来实现），这样在MR上会通过S1接收到组播数据流，这时候MR上进行RPF检查就不会失败了，因为S0接口DOWN掉，通往媒体流服务器的单播路由项会自动的切换到S1接口上（通过动态路由协议完成）。
其实，组播路由协议可以理解为剪枝和嫁接消息的集合，任何组播路由协议都是由这两个消息作为基础的，只不过不同的路由协议发出该消息的时机不同罢了。
上面介绍的时候，提到了RPF检查，并提到，RPF检查需要路由器的单播路由表，这个说法严格来说其实是不正确的，因为要分两种情况：
对于某些协议（比如PIM-DM，PIM-SM等），这些协议在进行RPF检查的时候直接使用路由器用于转发单播数据的路由表，即这些协议信任路由器的单播路由协议，这种多播协议叫做协议无关多播协议（也就是PIM的由来，即ProtocolIndependMulticastProtocol），还有一些协议，比如DVMRP等，它们在进行RPF检查的时候，是根据自己建立的一个单播路由表进行的，所有这些多播路由协议至少有两部分构成：
一部分用于单播路由表的建立（该单播路由表跟路由器用来转发单播数据的路由表不同，它仅仅用于RPF检查），另外一部分用于组播路由表的建立。
比如DVMRP，它实际上集成
升级会员 