网络程序设计教材第七章 广播和多播.doc

第七章 广播和多播7.1概述IP地址有三种类型，分别是单播地址、广播地址和多播地址。广播和多播地址仅应用于UDP协议，它们主要应用在将报文同时传送到多个接收者的情况。TCP协议是一个面向连接的协议，它意味着分别运行在两个主机（由IP地址确定）上的两个进程（由Socket端口号确定）间存在一条连接。对于多个主机的共享信道网络，例如以太网，每个以太网帧结构包含源主机和目的主机的以太网地址（MAC地址）。通常，每个以太网帧仅发往单个目的主机，目的地址指明单个接收者，这种通信方式通常称为单播（unicast）。使用这种通信方式，任意两个主机的通信不会干扰其他主机间的通信（竞争共享信道的情况除外）。除了单播、广播和多播三种通信方式外，还有一种IPv6将支持的任播（anycasting）通信方式，但目前它还是一个尚未实现的概念。RFC1546对任播通信方式作了详细的描述。然而，有时一个主机要向网络上的所有主机发送帧，例如可视会议，这种通信方式成为广播（broadcast）。多播（multicast）处于单播和广播之间：帧仅传送给属于多播组的多个主机。为了更好地理解广播和多播，需要了解主机对由信道传送过来帧的过滤过程。图7-1说明了这个过程。接收方对收到的数据帧由低层向高层交付。 图7-1 协议栈各层对收到帧的过滤过程首先，网络适配器（接口卡）查看信道传送过来的帧，确定是否接收该帧；若确定接收该帧，就将它传送到设备驱动程序。通常，网络适配器仅接收那些目的地址为其物理地址或广播地址的帧。目前，大多数网络适配器经过配置都能接收目的地址为多播地址或某些子网多播地址的帧。对于以太网，当地址中（MAC地址由6个字节组成）最高字节的最低位设置为1时表示该地址是一个多播地址（以太网广播地址ff:ff:ff:ff:ff:ff可以看作是以太网多播地址的特例）。如果网络适配器收到一个帧，这个帧将被传送给设备驱动程序（如果该帧发生差错，例如：帧过长或过短，检查和错误等，网络接口卡将丢弃该帧）。设备驱动程序将进行另外的帧过滤。首先，帧类型中必须指定要使用的协议（IP, ARP, RARP等）；其次，进行多播过滤来检测该主机是否属于多播地址说明的多播组。设备驱动程序随后将数据帧传送给下一层，例如，当帧类型指定为IP数据报时，就传送给IP层实体。IP实体根据数据报中的源地址和目的地址进行相应的过滤检测。如果正确，就将数据报传送给下一层（例如TCP或UDP）。UDP实体每次收到由IP传送来的数据报，根据目的端口号和源端口号进行数据报过滤。如果当前系统中没有进程使用该目的端口号，则丢弃该数据报并产生一个ICMP不可到达报文（TCP实体根据端口号作相似的过滤）。如果UDP数据报存在检查和错，则被丢弃。广播的使用增加了对广播不感兴趣主机的处理负荷, 例如一个由30台计算机组成的计算机网络, 但仅有20台机器参与该广播通信, 但其余的10台机器不得不处理该广播数据报。为了减少对广播不感兴趣主机的处理负荷, 可以使用多播, 网络中的主机可以加入一个或多个多播组, 这样, 网卡将获悉一个主机属于哪个多播组, 然后仅接收主机所在多播组的那些多播帧。对于多播和广播通信只能使用UDP协议，IPv4对多播的支持是可选的，而IPv6是必须支持的；IPv6没有提供对广播的支持，当使用广播的IPv4应用程序移植到IPv6时，必须使用IPv6的多播形式进行重新编码。7.2 广播用户已经知道了四种IP广播地址(参见IP地址)。7.2.1 广播的用途广播的用途主要有两个，一个是假定服务器主机在本地子网上，但不知道其单播IP地址时，对它进行定位，这就是通常所说的资源发现（resource discovery）；另一个用途是当有多个顾客和单个服务员通信时，减少局域网上数据流量。下面是使用广播进行Internet应用例子。1. ARP：ARP是IPv4的一个基本组成部分，而不是一个用户应用程序。ARP在本地子网上广播一个请求：“具有IP地址a.b.c.d的系统请表明自己，并告诉我你的硬件地址。”2. BOOTP：顾客假定有一个服务员主机在本地子网上。它以广播地址（通常为255.255.255.255，因为这时顾客还不知道自己的IP地址、子网掩码或子网的受限广播地址）为目的地址发出自己的引导请求。3. NTP：一个NTP顾客主机可能配置成使用一个或多个服务器主机的IP地址，其上面的NTP顾客于是以某个频率（每64秒一次）轮询这些服务器。顾客采用基于服务器返回的时刻和到达服务器的往返时间的精确算法更新时钟。但在支持广播的局域网上，就不需要采用顾客轮询服务器的方法，而代之以服务器以每64秒一次的频率向本地子网上的所有顾客广播当前时刻。这样便可以减少网络上的数据流量。4. routed：routed是一个常用的后台进程，它输出自己的路由表的方法便是局域网广播。所有其它连接到这些局域网上的路由器便可以同时接收这些路由通告，而不必每个路由器都必须配置其邻居路由器的IP地址。这个特点也被局域网上的主机用于倾听路由通告并相应更新它们的路由表。7.2.2 受限广播受限广播的IP地址是: 255.255.255.255。该地址用于主机配置过程中IP数据报的目的地址, 这时, 主机可能还不知道它所在网络的网络掩码, 甚至连它的IP地址也不知道。在任何情况下, 路由器都不转发目的地址为受限的广播地址的数据报, 这样的数据报仅能在本地网络中传递。对于受限广播, 如果一个主机是多接口的, 当一个进程向本网广播地址发送数据报时, 为了实现广播, 是否需要将数据报发送到每个相连的接口上? 如果不是这样, 想对主机所有接口广播的应用必须确定主机中支持广播的所有接口, 然后向每个接口发送一个数据报复本。大多数BSD系统将255.255.255.255看作是配置后第一个接口的广播地址, 并且不提供向所属具备广播能力的接口传送数据报的功能。对于这种情况, 守护进程routed 和rwhod(参见UNIX操作系统)是向每个接口发送UDP数据报的两个应用程序。这两个应用程序均用相似的启动过程来确定主机中的所有接口, 并了解哪些接口具备广播能力。同时, 将对应于那些接口的指向网络的广播地址作为发往该接口的数据报的目的地址。7.2.3 指向网络的广播指向网络的广播地址是主机号为全1的地址。对于A类网络, 其广播地址为 netid.255.255.255, 其中netid为A类网络的网络号。一个路由器必须能够转发指向网络的广播, 但它也必须有一个不进行转发的选择。7.2.4 指向子网的广播指向子网的广播地址为主机号为全1且有特定子网号的地址。作为子网直接广播地址的IP地址子网掩码的支持。例如，如果路由器收到发往128.1.2.255的数据报，当B类网络128.1的子网掩码为255.255.255.0时，该地址就是指向子网的广播地址；但如果该子网的掩码是255.255.254.0时，该地址就不是指向子网的广播地址。7.2.5 指向所有子网的广播指向所有子网的广播需要了解目的网络的子网掩码，以便与指向网络的广播地址区分开。指向所有子网的广播地址的子网号及主机号为全1。例如，如果子网掩码为255.255.255.0，那么IP地址128.1.255.255是一个指向所有子网的广播地址。但是，如果网络没有划分子网，这个地址就是一个指向网络的广播地址。目前的观点是Almquist 1993是这种广播方式已经过时，更好的方式是使用多播而不是对所有子网的广播。Almquist 1993虽然指出RFC922要求将一个指向所有子网的广播传送给所有子网，但当前的路由器没有这样做。因为一个因错误配置而没有子网掩码的主机会把它的本地广播传送到所有子网。例如，如果IP地址为128.1.2.3的主机没有设置子网掩码，它的广播地址在正常情况下的默认值是128.1.255.255。但如果子网掩码被设置为255.255.255.0，那么由错误配置的主机发出的广播将指向所有子网。1983年问世的BSD4.2是一个影响广泛的TCP/IP实现，它使用主机号全0作为广播地址。RFC894Horning 1984认为BSD4.2使用非标准的广播地址，但RFC906 Finlayson 1984考虑到对广播地址还没有Internet标准，因此RFC编辑在RFC906中增加了一个脚注承认缺少标准的广播地址，并强烈推荐将主机号全1作为广播地址。尽管1986年出现的BSD4.3采用主机号全1表示广播地址，但直到90年代早期，许多著名的操作系统，例如SunOS4.x,还继续使用非标准的广播地址。7.2.6 广播的例子广播的具体传输过程以及路由器和主机如何处理广播，主要依赖于广播的类型、应用的类型、TCP/IP实现方法以及有关路由器的配置。首先，应用程序必须支持广播。例如执行ping命令打算在本地电缆上进行广播。但它无法进行。 sun % ping 255.255.255.255 /usr/etc/ping: unknown host 255.255.255.255原因在于该应用程序（ping）中存在一个程序设计上的问题。 大多数应用程序收到点分十进制的IP地址或主机名后，会调用函数inet-addr()来把它们转化为32bit的二进制IP地址。例如要转化的是一个主机名，如果失败，该库函数将返回-1来表明发生某种错误。但本地网广播地址（255.255.255.255）也被当作存在错误而返回-1。大多数程序均假定接收到的字符串是主机名，然后查找DNS，失败后输出差错信息，例如“未知主机”。7.2.7 IP分片和广播源自Berkeley的内核不允许广播数据报分片。如果发送到广播地址的IP数据报超过外出接口的MTU，就返回EMSGSIZE错误。这是一个自BSD4.2以来就存在的策略。事实上，并没有什么原因不让广播数据报分片，只是认为广播通信已经给网络带来很大负担，没有必要再由于分片而使这种负担加剧。目前很多操作系统（例如AIX、BSD、Digital Unix和UnixWare）都不允许广播数据报分片。UnixWare虽然不发送过大的数据报，但也不返回错误信息。Linux和Solaris都允许对发送到广播地址的数据报分片。为了保证程序的可移植性，需要广播的应用程序应将广播数据报限制在1472字节以内，因为对于局域网而言，以太网的MTU通常是最小的。7.3 多播 连接到子网上的所有主机都要接收广播数据报。广播的缺点是子网上的所有主机都要处理这个数据报。如果是UDP数据报，需要一直向上处理到UDP层，即使不参与广播应用系统的主机也是这样。像音频、视频等高数据速率应用系统将给这些主机带来过度的处理负担，而在多播通信时，只有对这个应用系统感兴趣的主机才会接收到多播数据报。通常，IP多播提供两类服务：1 向多个目的地址传送数据。有许多向多个接收者同时传送信息的应用：例如交互式会议系统和向多个接收者发送邮件和新闻。如果不采用多播，目前这些应用大多采用TCP/IP来完成（向每个目的地址传送一个单独的数据复制）。然而，即使使用多播，某些应用为了保证可靠性仍然使用TCP。2 客户对服务器的请求。例如，无盘工作站系统需要确定启动引导服务器。目前，这项服务是通过广播来提供的（参见BOOTP协议），但是使用多播通信可降低不提供这项服务主机的负载。7.3.1多播组地址下面的图7-2显示了D类IP地址的格式。 图7-2 D类IP地址格式和其他三类地址（A、B和C类）不同，D类IP地址中的28位均用作多播组号而不在表示其他含义。多播组地址包括710的最高4bit和多播组号，它们通常可表示为点分十进制数，其范围从224.0.0.0到239.255.255.255。能够接收发往一个特定多播组地址数据的主机集合称为主机组（host group）。一个主机组可跨越多个网络。主机组中成员可以随时加入或离开主机组。主机组中对主机的数量没有限制，同时不属于某一主机组的主机可以向该组发送信息。一些多播组地址被IANA确定为知名地址，这些地址也被当作永久主机组，这和TCP协议及UDP协议中的知名端口类似。同样，这些知名多播地址在RFC最新分配数字中列出，这些多播地址所代表的组是永久组，而它们的成员却不是永久的。例如，224.0.0.1代表“该子网中的所有系统组”，224.0.0.2代表“该子网中的所有路由器组”。多播地址224.0.1.1用作网络时间协议NTP，224.0.0.9用作RIP-2，224.0.1.2用作SGI公司的dogfight应用。7.3.2 多播组地址到以太网地址的转换IANA拥有一个以太网地址块，即高位24bit为00:00:5e（十六进制），该地址块所拥有的地址范围从00:00:5e:00:00:00 到00:00:5e:ff:ff:ff。IANA将其中的一半分配为多播地址。为了指明一个多播地址，任何一个以太网地址的首字节必须是01，这意味着与IP多播相对应的以太网地址范围从01:00:5e:00:00:00 到01:00:5e:ff:ff:ff。这种地址分配使以太网多播地址中的23bit与IP多播组号对应起来，通过将多播组号中的低位23bit映射到以太网地址中的低位23bit实现。由于多播组号中的最高5bit在映射中被忽略，因此每个以太网多播地址对应的多播组是不唯一的。32个不同的多播组号被映射为一个以太网地址。例如，多播地址224.128.64.32和224.0.64.32都映射为同一个以太网地址01:00:5e:00:40:20。由于地址映射是不唯一的，那么设备驱动程序或IP层就必须对数据报进行过滤。因为网络适配器可能收到主机不想接收的多播数据帧。另外，如果网络适配器不提供足够的多播数据帧过滤功能，设备驱动程序就必须接收所有多播数据帧，然后对它们进行过滤。目前绝大多数网络适配器趋向两种处理类型：一种是网络适配器根据对多播地址的散列值实行多播过滤，即仍会接收不想接收的多播数据；另一种是网络适配器只接收一些固定数目的多播地址，即当主机想接收超过网络适配器预先支持多播地址以外的多播地址时，必须将网络适配器设置为“多播混杂（multicast promiscuous）”模式。因此，这两种类型的网络适配器仍需要设备驱动程序检查收到的帧是否真正是主机所需要的。即使网络适配器实现了完整的过滤（基于48bit的MAC地址），由于从D类IP地址到48bit的硬件地址的映射不是一一对应的，所以过滤仍然是必要的。尽管存在地址映射不完善和需要硬件过滤的不足，多播相对广播仍然具有较大优点。单个物理网络的多播通信很简单。多播进程将目的IP地址指定为多播地址，设备驱动程序将它转换为相应的以太网地址，然后把数据发送出去。对应的接收进程必须通知它们的IP层，它们想接收的发往给定多播地址的数据报，并且设备驱动程序必须能够接收这些多播帧。这个过程就是“加入一个多播组”。当一个主机收到多播数据报时，它必须向属于那个多播组的每个进程均传送一个复制。这一点和单个进程收到单播UDP数据报不同。使用多播，一个主机上可能存在多个属于同一多播组的进程。当把多播通信扩展到单个物理网络以外需要通过路由器转发多播数据时，复杂性就增加了。需要一个协议让多播路由器了解确定网络中属于确定多播组的任何一个主机。这个协议就是Internet组管理协议（IGMP）。广播是将数据报发送到网络中的所有主机（通常是本地相连的网络），而多播是将数据报发送到网络中的一个主机组。这两个通信方式的主要区别在于当收到送往上一个协议栈的数据帧时采用不同类型的过滤。每个协议层均可因为不同的理由丢弃数据报。目前有四种类型的广播地址：受限广播、指向网络的广播、指向子网的广播和指向所有子网的广播。最常用的是指向子网的广播。受限广播通常只在系统初始启动时才会用到。试图通过路由器进行广播而发生的问题，经常是因为路由器不了解目的网络的子网掩码。另外也与广播地址类型、路由器参数配置等因素有关。D类IP地址通常称为多播组地址。通过将其低位23bit映射到相应以太网地址中便可实现多播组地址到以太网地址的转换。由于地址映射是不唯一的，因此需要其他协议实现数据报过滤。7.4 单播与广播的比较在基于UDP协议的网络程序设计部分用户已经清楚了向单播地址发送UDP数据报的步骤。图7-3说明了在一个以太网环境上（包括三台主机）向单播地址发送UDP数据报的情况。接收进程发送进程Sendto目的IP=128.7.6.5目的端口=7566端口=7566UDPUDPUDP协议=UDPIPv4IPv4IPv4类型=0800128.7.6.5=单播128.7.6.255=广播数据链路数据链路数据链路02:60:8c:4a:f3:0802:60:8c:35:60:28子网128.7.6图7-3 UDP数据报单播过程在图7-3中网络号码为128.7.6，左边主机上应用程序在一个UDP套接口上调用sendto函数，将数据发往IP地址为128.7.6.5、端口为7566。UDP层附加一个UDP头部，并将UDP数据报传送到IP层。IP层给它附加一个IPv4头部，并确定其外出接口。在以太网环境下，将调用ARP来确定与目的IP地址相对应的以太网MAC地址：02:60:8c:4a:f3:08。然后，将分组作为以太网帧发送出去， 具体结构如图7-4所示。UDP数据UDP头部IPv4头部以太网头部目的地址=02:60:8c:4a:f3:08帧类型=0800目的端口=7655目的IP=128.7.6.5协议=UDP图7-4 以太网帧结构示例以太网帧的目的地址是48位的MAC地址，帧类型字段为0800，指示这是一个IPv4分组，IPv6帧类型字段的值为86dd。在以太网帧传递过程中，中间主机的以太网接口会发现该帧，并将它的目的以太网地址与自己的以太网地址进行比较，由于二者比相等，接口便忽略该帧。因此，单播帧不会对这台主机造成任何额外开销。图7-3中右边主机的以太网接口也会发现该帧。当它将该帧的目的以太网地址与自己的以太网地址进行比较时，发现二者相等，该接口就读入整个帧。当帧全部读入后，通常是产生一个硬件中断，设备驱动程序于是从接口缓冲区中读取该帧。由于帧类型字段值为0800，于是将分组放入IP输入队列。当IP层处理该分组时，它首先将目的IP地址与自己的IP地址进行比较。由于目的地址和自己的IP地址相同（包括本地IP地址和广播IP地址），于是就接收这个分组。然后，IP层检查IPv4头部协议字段，其值对于UDP为17，于是将IP数据报传送到UDP层。UDP层检查其目的端口（如果其UDP套接口已连接，也可能检查源端口），将数据报放到相应套接口的接收队列。如果需要，就唤醒相应进程，由进程读取这个新接收的数据报。在单播数据报整个传播过程中，只是由IP地址指定的主机接收，子网中的其它主机不受任何影响。但是，如果发送进程发送的是子网广播数据报，其目的地址为128.7.6.255，情况就不同了。当左边的主机发送一个数据报，该数据报的目的IP地址是子网广播地址，于是便将它映射成48位的以太网地址：ff.ff.ff.ff.ff.ff。这使得子网上的每个以太网接口都会接收该帧。在图7-3中右边两台运行IPv4的主机都接收该帧。由于以太网帧类型为0800，两个主机都将数据报传递到IP层。由于目的IP地址匹配两者的广播地址，并且协议字段为17（UDP），两个主机都将分组传送到UDP。这种广播数据报要到达网络中的所有主机，也包括发送者自身。本例子也说明了广播存在的根本问题：子网上所有未参与广播应用系统的主机也必须完成对数据报的处理，直到在UDP层将其丢弃（应用进程没有绑定到特定的UDP端口）。所有非IP主机（例如运行IPX的主机）也必须在数据链路层接收完整的数据帧，并在该层将其丢弃（即不支持该帧的帧类型，对于IPv4分组的帧类型为0800）。因此，对于以高速率产生IP数据报的应用系统（例如音频和视频数据传输）会严重影响子网上其它主机的运行。7.5 局域网上多播与广播比较单播地址标识单个接口，广播地址标识子网上的所有接口，而多播地址标识一组接口。单播和广播是编址方案的两个极端，多播通信的目的是提供一种折中方案。多播数据报仅由对该数据报感兴趣的接口接收。广播一般局限于局域网，而多播既可以用于局域网，也可以跨越广域网。图7-5说明了数据报多播通信的情况，图7-6说明了以太网帧结构。接收进程发送进程Sendto目的IP=224.0.1.1目的端口=166加入224.0.1.1端口=166UDPUDP协议=UDPIPv4数据链路UDP基于目的IP的完备软件过滤IPv4IPv4接收01:00:5e:00:01:01类型=0800基于目的以太网的非完备硬件过滤数据链路数据链路02:60:8c:35:60:2802:60:8c:4a:f3:08图7-5 UDP数据报多播过程UDP数据UDP头部IPv4头部以太网头部目的地址=01:00:5e:00:01:01帧类型=0800目的端口=166目的IP=224.0.1.1协议=UDP图7-6 多播通信中以太网帧结构在图7-5中，最右边主机的用于接收的应用进程启动，创建UDP套接口，捆绑端口166，然后加入多播组224.0.1.1。这种加入操作是通过调用setsockopt完成的。在上述操作完成后，IPv4将这些信息保存起来，告诉适当的数据链路接收以01:00:5e:00:01:01为目的地址的帧。该地址是多播组地址映射得到的。在图中最左边的用于发送的应用进程创建一个UDP套接口，并向IP地址224.0.1.1及端口166发送数据报。发送多播数据报不需要任何特殊处理，应用程序不需要加入多播组。发送主机将IP地址映射到相应的以太网目的地址，并将帧发送出去。在图中假定中间主机不支持IPv4多播（在IPv4中支持多播是可选的）。它将忽略该帧，原因如下：1 目的以太网地址和接口地址不匹配；2 目的以太网地址不是以太网广播地址；3 没有通知接口接收任何组地址。该帧基于一种称之为非完备过滤（imperfect filtering）的机制被右边的数据链路接收。这种机制是接口利用以太网目的地址实现的。之所以称它为不完备是因为当告诉接口接收某个具体以太网组地址为目的地址的帧时，它也可能接收以其它以太网组地址为目的地址的帧。当用户告诉以太网接口接收目的地址为某个具体以太网组地址的帧时，当前许多网络适配器对该地址实施一种散列函数运算，计算出一个介于0和63之间的一个值，并将一个64位数组的相应位置1。当一个发往某个组地址的帧在电缆上经过时，接口对其目的地址实施同样的散列函数运算，计算出一个介于0和63之间的一个值。如果数组中的相应位置1，就接收这个帧，否则就忽略这个帧。为了减少接口接收与它无关帧的可能性。较新的网络适配器便将位数组的大小从64增加到512。随着多播的广泛使用，位数组的大小可能进一步增加。目前，某些网络适配器已经实现了完全过滤。但有些网络适配器根本不进行多播过滤，当告诉它接收某个具体组地址时，它必须接收所有的多播帧（多播混杂模式）。流行的网络适配器能跟512位散列表一样准确地完成16个组地址的完备过滤。但即使接口实现了完备过滤，IP层的完备软件过滤仍然是需要的，因为从IP多播地址到硬件地址的映射不是一对一的。在图中假设右边主机的数据链路接收该帧。由于以太网帧类型为IPv4，相应分组被传送到IP层。由于所接收分组的目的地址为多播IP地址，IP层就将该分组的目的地址和自己的应用进程已加入的所有多播地址进行比较，如果是自己需要的分组就接收，否则就丢弃。这个过程成为完备过滤（perfect filtering），因为它是基于完整的32位D类地址完成的。随后该分组被传送到UDP层，UDP层随后将相应的数据报传送到绑定端口166的套接口。在图7-5中没有说明以下情况：1 对于一台运行并加入到多播地址225.0.1.1的主机，以太网接口将接收该帧。由于多播地址的高5位在映射到以太网地址的过程中被忽略，该主机的以太网地址也将接收以太网目的地址为01:00:5e:00:01:01的帧。在这种情况下，分组将在IP层由完备过滤丢弃。2 一台运行并加入某个多播组的主机，其多播组的相应以太网地址实施散列后恰好与01:00:5e:00:01:01的散列结果相同（即接口执行非完备过滤）。这种帧将在数据链路层或IP层丢弃。3 发往同组（224.0.1.1）但不同端口（例如168）。图7-5中最右边的主机仍接收这类分组，但它们由IP层接收后由UDP层丢弃。即一个进程要接收多播数据报，该进程必须加入相应组并绑定相应端口。7.6 广域网上的多播在单个局域网上的多播是很简单的。一台主机发送一个多播分组，任何有兴趣的主机都会接收此数据报。多播相对于广播的优势在于会减轻其它对此多播分组不感兴趣的主机的负担。在广域网上，多播也十分有用。图7-7是用5台多播路由器连接5个局域网的网络环境。MR5MR1MR3MR4MR2图7-7用5台多播路由器连接的5个局域网假设在其中的5台主机上启动了一些程序（例如监听多播音频会话的程序）且这5个进程加入了一个给定的多播组，于是这5台主机也加入了这个多播组。这里假设多播路由器都与相邻的多播路由器通过多播路由协议（multicast routing protocol，简称MRP）相互通信。整个情况如图7-8所示，主机H1、H2、H3、H4和H5加入了多播组，多播路由器之间使用MRP通信。AH1MRPMR5MR1MR3MR4MR2H5H4H3H2图7-8 广域网上5台主机加入一个多播组当一个主机上的进程加入一个多播组时，这台主机向所有连接着的多播路由器发送一个IGMP消息，通知它们该主机加入了那个组。这些多播路由器于是利用多播路由协议交换这个消息。这样每台路由器在它收到一个目的地址为多播地址的分组时就知道如何处理。这时，如果在主机A上的一个进程开始发送一个到多播地址的数据报，可以观察随着多播数据报从发送方到接收方的过程。l 在图7-8左上方的局域网上，数据报由发送方多播。接收方H1和MR1接收到了这些数据报。（由于H1加入了这个组，而多播路由器必须接收所有多播数据报。）l MR1将多播数据报转发给MR2，因为多播路由协议告诉MR1，MR2要接收目的地址为这个组的数据报。l MR2向和它相连的局域网多播此数据报，因为主机H2和H3属于这个组；MR2也向MR3发送一个数据报的复本。像MR2那样复制数据报是多播转发时特有的，单播分组在被路由器转发时是从不被复制的。l MR3向MR4发送多播数据报，但它不在和自己相连的局域网上多播，因为在这个局域网上没有主机加入这个组。l MR4将数据报多播到与它相连的局域网上，因为主机H4和H5属于这个组。MR4并不向MR5发送数据报的复本，因为在MR5所连接的局域网上没有主机属于这个组，而且MR4根据与MR5交换的多播路由信息已经知道这一点。在广域网上的两个稍差的多播替代方式是广播泛滥（broadcast flooding）和给每个接收方都发送一个单独的数据报复本。在第一种方法中，数据报由发送方广播，每个路由器也要向除了该数据报的到达接口以外的每个接口广播。显然，这样做会增加对该数据报不感兴趣但又必须处理它的主机和路由器的数量和相应的处理开销。在第二种方法中，发送方必须知道所有接收方的IP地址并且发送给每个接收方一个复本。在图7-8中的5个接收方例子中，要求在发送方的局域网上发送5个数据报。其中从MR1到MR2走4个数据报，从MR2到MR3到MR4走2个数据报。7.7 多播套接口选项套接口API中增加的多播支持内容比较简单：5个套接口选项，其中3个选项影响到多播数据报的发送，另外2个选项影响到多播数据报的接收。表7-1说明了这5个套接口选项和在IPv4和IPv6中调用getsockopt和setsockopt时所期望参数的数据类型。指向所给出数据类型变量的指针是getsockopt和setsockopt的第四个参数。所有10个（5对）选项对setsockopt都是合法的，但加入和离开多播组的4个（2对）选项在getsockopt中是不允许的。表7-1 多播套接口选项选项名数据类型说明IP_ADD_MEMBERSHIPstruct ip_mreq加入一个多播组IP_DROP_MEMBERSHIPstruct ip_mreq离开一个多播组IP_MULTICAST_IFstruct in_addr指定外出多播数据报的外出接口IP_MULTICAST_TTLu_char指定外出多播数据报的TTLIP_MULTICAST_LOOPu_char使能或禁止外出多播数据报的回馈IPV6_ADD_MEMBERSHIPstruct ipv6_mreq加入一个多播组IPV6_DROP_MEMBERSHIPstruct ipv6_mreq离开一个多播组IPV6_MULTICAST_IFu_int指定外出多播数据报的外出接口IPV6_MULTICAST_HOPSint指定外出多播数据报的跳限IPV6_MULTICAST_LOOPu_int使能或禁止外出多播数据报的回馈IPv4的TTL和回馈选项用u_char的参数，而IPv6的跳限和回馈选项使用int和u_int的参数。对于IPv4和IPv6的各自5个选项在概念上是相同的，只是名字和参数类型不同。IP_ADD_MEMBERSHIP 和IPV6_ADD_MEMBERSHIP在一个指定的本地接口上加入一个多播组。可以使用IPv4中的单播地址或IPv6中的接口索引去指定本地接口。当加入或者离开一个组时，要使用下面两个数据结构。struct ip_mreqstruct in_addr imr_multiaddr; /*IPv4 class multicast addr*/struct in_addr imr_interface; /*IPv4 addr of local interface*/;struct ipv6_mreqstruct in6_addr ipv6mr_multiaddr; /*IPv6class multicast addr*/unsigned int ipv6mr_interface; /*interface index or 0*/;如果本地接口指定为通配地址（在IPv4中为INADDR_ANY）或者IPv6中的索引0，那么本地接口就由内核来选择。如果某台主机上当前有一个或者多个进程属于某个接口上的一个给定多播组，就称该主机在那个接口上属于所给定组。在一个给定的套接口上可以多次加入多播组，但是每次加入的必须是一个不同的多播地址，或者虽然是同一个多播地址但不在此套接口以前加入此地址的接口上。这一点可以用于多宿主机，例如，创建一个套接口，接着以给定的多播地址加入每个接口。大多数实现对允许每个套接口加入的（多播组本地接口对）数目有一个限制。对源自Berkeley的实现这个限制是20。当加入的接口没有指定时，源自Berkeley的内核在通常的IP路由表中查找多播地址，并使用查出的接口。有些系统在初始化时给所有多播地址安装一个路径去处理这种情况。在IPv6中有了改变，它使用接口索引去指定接口，而不象IPv4那样使用本地单播地址，这样可允许加入未指定网络地址的接口和隧道端点。IP_DROP_MEMBERSHIP 和IPV6_DROP_MEMBERSHIP将一个指定的本地接口离开一个多播组。上面加入一个多播组的数据结构也可以用于这对套接口选项。如果本地接口没有指定（即其值为IPv4的INADDR_ANY或者IPv6的接口索引0），那么第一个匹配的多播组的组成员将被从组中撤消。如果一个进程加入了一个组但从未明确地离开那个组，当套接口关闭时（或者显示关闭或者进程终止），成员关系将被自动解除。同一个主机上的多个进程都加入同一个组也是可以的，这种情况下，主机一直是该组的成员，直到最后一个进程离开那个组。IP_MULTICAST_IF 和IPV6_MULTICAST_IF给从本套接口上发出的外出多播数据报指定接口。这个接口在IPv4中被指定为in_addr结构，在IPv6中被指定为接口索引。如果其值为IPv4中的INADDR_ANY或IPv6中的接口索引0，这将去掉以前通过这个选项指派给此套接口的接口，系统于是给每个外出数据报选择接口。源自Berkeley的内核通过在通常的IP路由表中检索通往目的多播地址的路径来给多播数据报选择缺省端口。同样的技术也可以用于当进程加入组时没有指定接口的情况下选择接收接口。这里假定如果存在通往给定的多播地址的路径，那么检索出的接口被用于输入和输出。IP_MULTICAST_TTL 和IPV6_MULTICAST_HOPS给外出的多播数据报设置IPv4的TTL或者IPv6的跳限。如果不指定，那么缺省值都将设置为1，也就是限制数据报在本地子网。IP_MULTICAST_LOOP 和IPV6_MULTICAST_LOOP打开或者关闭多播数据报的本地回馈。缺省时回馈是打开的，即如果一个主机在发送接口上属于一个多播组，该主机上的进程发送的每个数据报的复本也会回馈，被主机当作接收的数据报处理。这一点类似广播，一个主机上发送的广播数据报也被当作接收的数据报，但在广播通信方式中是无法禁止回馈的。这意味着如果一个进程属于它所发送数据报的多播组，它将会收到自己发送的数据报。这里的回馈是在IP层或更高层进行的内部回馈。如果接口监听到了它自己发送的数据报，RFC712文档要求驱动程序忽略这些复本。该RFC文档还指出回馈选项缺省情况下打开，目的是作为一种某些上层协议的性能优化措施，而这些协议（例如路由协议）的特点是把一个组的成员限定到每台主机上的单个进程。在上述套接口选项中，前两对套接口选项（ADD_MEMBERSHIP和DROP_MEMBERSHIP）影响多播数据报的接收，后三对选项影响多播数据报的发送（外出接口、TTL或跳限及回馈）。如果在发送多播数据报之前没有指定多播套接口选项，数据报的外出接口将由内核来选择，TTL或跳限将为1，且有一个复本回馈回来。一个进程如果要接收多播数据报就必须加入那个多播组，并捆绑UDP套接口到某个端口，而这个端口将用作发到这个多播组的数据报的目的端口，这两个操作是必须的。加入这个多播组就是告诉所在主机的IP层和数据链路层接收发送到这个组的多播数据报。捆绑端口是应用程序向UDP指示它想接收发送到此端口的数据报。有些应用程序不仅捆绑端口，而且还将多播地址也捆绑到套接口上，这样做可以防止此端口可能接收的其它数据报也传送到此套接口。源自Berkeley的实现仅要求主机上的某个套接口加入多播组，而不必给它捆绑端口就能接收多播数据报。但这些实现使多播数据报传递到并没有多播行为的应用进程存在可能性。新的多播内核要求进程绑定端口并设置任意一个多播套接口选项，后一个操作指明应用进程意识到多播。最通常设置的多播套接口选项是加入组。Solaris2.5的实现与此不同，它仅传递收到的多播数据报到不但加入了组而且绑定了端口的套接口。因此，为了程序的移植性，所有的多播应用程序都应当加入组并捆绑端口。有些较早版本的支持多播的主机不允许捆绑多播地址到套接口。为了移植性，应用程序可能需要忽略多播地址的bind函数调用出错。下面的程序例子说明了如何设置多播回馈选项。/* include mcast_set_loop */#includeunp.hintmcast_set_loop(int sockfd, int onoff)switch (sockfd_to_family(sockfd) case AF_INET: u_charflag;flag = onoff;return(setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_LOOP, &flag, sizeof(flag);#ifdefIPV6case AF_INET6: u_intflag;flag = onoff;return(setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_LOOP, &flag, sizeof(flag);#endifdefault:errno = EPROTONOSUPPORT;return(-1);void Mcast_set_loop(int sockfd, int onoff)if (mcast_set_loop(sockfd, onoff) 0)err_sys(mcast_set_loop error);多播应用进程从加入指派给它的多播组开始，这个操作告诉IP层加入这个组，IP层再告诉数据链路层接收送到相应硬件层多播地址的多播帧。多播可以利用多数网络适配器上有的硬件过滤，而且过滤得越好，所收到的不需要的分组也越少。利用这种硬件过滤减少了其它不参与同一应用系统的主机上的负载。在广域网上的多播需要有多播能力的路由器和多播路由协议的支持。在Internet网络上的所有路由器都能进行多播前，称为Mbone的虚拟网络将一直被使用。5对套接口选项提供了支持多播的API：l 在一个接口上加入一个多播组l 离开一个多播组l 给外出的多播数据报设置缺省接口l 给外出的多播数据报设置TTL或跳限l 使能或者禁止多播数据报的回馈7.8 虚拟网络7.8.1 概述当TCP中加进一个新特性（例如定义在RFC1323中的长肥管道支持）时，相应支持只在使用TCP的主机上需要，而路由器上是不需要改动的。像RFC1323这样的变动是慢慢出现在TCP的主机实现中的，当建立新的TCP连接时，两端主机能够彼此判定对方是否支持新特性，如果通信双方都支持就能用上这些特性。这和诸如80年代末的多播和90年代中的IPv6对IP层所做的修改是不同的，因为这些新特性要求主机和所有路由器都要改动。然而用户不愿意等到所有系统都升级才开始使用这些新特性。为此目的人们使用隧道（tunnel）技术在已有的IPv4因特网上建立虚拟网络（virtual network）。7.8.2 MBone使用隧道建立的第一个虚拟网络例子是Mbone，它是从1992年开始的。如果一个LAN上有2个或多个主机支持多播，多播应用进程就能运行在所有这些主机上并彼此通信。要把这样的LAN连接到另外一个同样有可多播主机的LAN上，每个LAN 中得有一个主机相互间配置成一个隧道，如图7-9所示。图中用数字标出了如下的步骤。隧道端点，用作多播路由器（Mrouted）MH1可多播主机可多播主机可多播主机MR24312IPv4DataUDP多播（D类）目的IPv4地址单播路由器（UR3）5多播（D类）目的IPv4地址DataUDPIPv4IPv4单播路由器（UR4）IPv4头部由隧道源端加上，由末端去除。目的IP地址=隧道末端单播地址， IPv4协议域=4IPv4UDPData687隧道端点，用作多播路由器（Mrouted）可多播主机可多播主机可多播主机MR5图7-9 基于Mbone的IPv4多播通信过程1 源主机MH1上的某个应用进程向一个D类地址发送一个多播数据报。2 该数据报由本地LAN上所有可多播主机接收，包括MR2。这里MR2也用作多播路由器，运行着mrouted程序，由它进行多播路由选择。MR2是隧道的源端（tunnel source）。3 MR2在这个数据报前添加另一个IPv4头部，并把这个新头部的目的IPv4地址设置成隧道末端（tunnel endpoi