TCP/IP详解卷1:协议学习笔记第十二章广播和多播

我就是我 2022-11-14 11:44 206阅读 0赞

广播和多播仅用于UDP。TCP是面向连接的协议，它意味着运行于两主机（由IP地址确定）和两进程（由端口号确定）之间存在一条连接。

多播处于单播和广播之间，仅传送给属于多播组的多个主机。  
![在这里插入图片描述][20210329000328211.png]  
由上图，网卡查看由信道传送过来的帧，确定是否接收该帧，若接收，将它送往设备驱动程序，通常网卡仅接收目的地址为网卡物理地址或广播地址的帧。另外，多数接口被设为混合模式，这种模式能接收每个帧，tcpdump程序使用这种模式。

目前，大多网卡经过配置都能接收目的地址为多播地址或某些子网多播地址的帧，对于以太网，当物理地址中的最高字节的最低位设为1时表示该地址是一个多播地址，用十六进制可表示为01:00:00:00:00:00，以太网广播地址ff:ff:ff:ff:ff:ff可看作是以太网多播地址的特例。

网卡将接收到的帧传送给设备驱动程序（如果帧检验和错，网卡将丢弃该帧），设备驱动程序进行另外的帧过滤，首先，帧类型中必须指定要使用的协议（IP、ARP等），其次，进行多播过滤来检测该主机是否属于多播地址说明的多播组。

设备驱动程序将数据帧传送给下一层，如帧类型为IP数据报，则传往IP层。IP根据IP地址中的源地址和目的地址进行更多过滤，如果正常，将数据报传送给下一层（如TCP或UDP）。

每次UDP收到由IP传送来的数据报，就根据目的端口号，有时还有源端口号进行数据报过滤。如果当前没有进程使用该目的端口号，就丢弃该数据报并产生一个ICMP不可达报文。如果UDP数据报存在检验和错，将被丢弃。

使用广播会增加对广播不感兴趣的主机的负荷，不感兴趣的主机在UDP层才会丢弃广播数据报，丢弃的原因为这些主机没有使用广播的目的端口。使用多播可避免此问题。

受限的广播地址是255.255.255.255，该地址用于主机配置过程中IP数据报的目的地址，此时，主机可能还不知道它所在网络的掩码，甚至连自己的IP都不知道。

任何情况下，路由器都不转发目的地址为首先的广播地址的数据报，这样的数据报仅出现在本地网络中，这也是为什么叫它受限的原因。

Host Requirements RFC没有涉及多接口主机是否应当向其所有接口发送受限的广播。

如果一个进程向本网广播地址发送数据报时，不将数据报发送到本机的所有接口，那么想对主机所有接口广播的应用必须确定主机中支持广播的所有接口，然后向每个接口发送一个数据报。

指向网络的广播地址是主机号全1的地址，向某类网络（如A类或B类网络中的所有主机发送消息）。一个路由器必须转发指向网络的广播，但它也有一个不进行转发的选择。A类网络广播地址为netid.255.255.255，其中netid为A类网络的网络号。

指向子网的广播地址为主机号全1且有特定子网号的地址。

指向所有子网的广播即向多个子网进行广播，如果一个网络没有划分子网，则就变成了指向网络的广播。当前认为这种广播是陈旧过时的，更好的方式是使用多播。

4.2 BSD是第一个影响广泛的TCP/IP实现，它使用主机号全0作为广播地址，RFC 894认为4.2 BSD使用不标准的广播地址，但RFC 906承认缺少标准的广播地址，并强烈推荐将主机号全1作为广播地址。到了4.3 BSD，开始使用主机号全1作为广播地址，但直到90年代早期，某些操作系统（著名的是SunOS 4.x）还继续使用非标准的广播地址。

广播怎样传送、路由器及主机怎样处理广播取决于广播的类型、应用的类型、TCP/IP的实现方法以及有关路由配置，如果执行以下命令在本地电缆上进行广播：  
![在这里插入图片描述][20210329225825171.png]  
它无法进行，原因在于ping程序存在一个程序设计上的问题，大多应用在收到点分十进制的IP地址或主机名后，会调用函数inet\_addr将其转换为32bit二进制IP地址，如果转化失败则返回-1，但本网广播地址255.255.255.255也被当作差错而返回-1。大多程序均假定接收到的字符串是主机名，然后查找DNS，失败后输出差错信息，如未知主机。即使改正了这个问题，大多会将255.255.255.255IP用作默认路由器地址，向默认路由器单播一个数据报，最终该数据报被路由器丢弃。

使用指向子网的广播，ping该地址时：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70]  
指向子网的广播接收对象为局域网中包括发送主机在内的所有主机，因此受到了来自自身sun的答复。

对于arp缓存，每个响应回显请求的主机在ARP缓存中均有一个条目。使用tcpdump查看ping执行过程会发现，广播数据帧的接收者发送响应之前，首先对sun主机发送一份arp请求，因为应答是单播的，而arp请求的接收者通常还将请求主机的IP地址和物理地址加入到arp缓存中去。

ping程序特殊之处在于，它允许向一个广播地址发送数据报，如果使用不支持广播的应用，如TFTP：  
![在这里插入图片描述][20210329232140977.png]  
程序立即产生了一个差错，不向网络发送任何信息，原因在于应用使用的API不允许发送广播UDP，这主要为了防止用户错误地采用广播地址（正如此例）。

在广播UDP数据报前，必须设置SO\_BROADCAST选项。并非所有系统都有这个限制。某些系统广播进程还需要root权限。

关于是否转发广播数据，有些系统内核和路由器存在配置选项以允许或拒绝转发。

IP多播提供两类服务：  
1.向多个目的地址传送数据。如交互式会议系统、向多个接收者分发邮件或新闻，目前这些应用大多使用TCP完成功能，因为多播使用UDP可靠性差。  
2.客户对服务器的请求。如无盘工作站需要启动引导服务器，目前这项工作由广播提供，但使用多播可降低不提供这项服务主机的负担。

D类IP一般用于多播：  
![在这里插入图片描述][20210330173758510.png]  
如上图，28bit均用作多播组号而不再表示其他含义。

能接收发往一个特定多播组地址数据的主机集合称为主机组，一个主机组可跨越多个网络，主机组中的成员可随时加入或离开主机组，主机组中对主机的数量没有限制，不属于某主机组的主机可以向该组发送信息。

一些多播组地址被IANA（互联网号码分配局，Internet Assigned Numbers Authority）确定为知名地址，它们也被当做永久主机组，它们的组成员不是永久的。

IANA拥有一个以太网地址块，高位24bit为00：00：5e，IANA将其中的一半分配为多播地址，为指明一个多播地址，任何以太网地址的首字节必须是01，即IP多播对应的以太网地址范围从01：00：5e：00：00：00到01：00：5e：7f：ff：ff。以上地址都是以大端序（网络序）表示。

上述地址分配使以太网多播地址中的23bit与IP多播组号对应起来：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 1]  
由于多播组号中的最高5bit在映射过程中被忽略，因此每个以太网地址有32个不同的多播组号。既然地址映射不是唯一的，那么设备驱动程序或IP层必须对数据报进行过滤，因为网卡可能接收到主机不想接收的多播组的数据帧，如果网卡不提供过滤功能，则设备驱动就必须接收所有多播数据帧并对它们过滤。

单个网络的多播比较简单，多播进程将目的IP指定为多播地址，设备驱动将其直接转换为以太网地址，然后发送出去。

当把多播扩展到单个物理网络以外，需要通过路由器转发多播数据时，需要有一个协议让多播路由器确定网络中属于某个多播组的所有主机，这个协议是Internet组管理协议（IGMP）。

一个主机上可能存在多个属于同一多播组的进程。

FDDI（光纤分布式数据接口，Fiber Distributed Data Interface）网络使用相同的方法将D类IP地址映射到48 bit FDDI地址。令牌环网通常使用不同的映射方法。

路由器默认是不转发UDP广播分组的，因此广播一般不会增加网络通信量，但它增加了额外的主机处理时间。如果一个主机不正确地响应了ICMP端口不可达之类的差错，则广播也可能导致额外的网络通信量。

如果某以太网有使用TCP/IP的主机，也有使用其他协议的主机，则主机收到另一个协议族的广播时，接口层先接收到该帧，之后将它传送给设备驱动程序，如果类型字段是其他协议，则设备驱动程序会丢弃该帧。

ifconfig命令可查看接口是否支持广播。

伯克利演变的实现不允许对一个广播数据报进行分片，这是策略上的决定，不是技术上的原因。

多播数据报可能被接口卡忽略或被设备驱动程序丢弃。

[20210329000328211.png]: /images/20221022/09a0d31f5ea04090abe5a2464a5c7e5a.png
[20210329225825171.png]: /images/20221022/06a33372a757467eb2d59e40d6306830.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70]: /images/20221022/387424ed1bf3438593ed62f00204e812.png
[20210329232140977.png]: /images/20221022/79c4af5fa3fd4cdfaba2b150bd11ea04.png
[20210330173758510.png]: /images/20221022/c45905fa00dc44fcb5c885395a5b13d4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3R1czAwMDAw_size_16_color_FFFFFF_t_70 1]: /images/20221022/1165732a609747c8984363958e7b6611.png