组播IP地址
组播IP地址
关于组播地址的分类：
224.0.0.0～224.0.0.255为预留的组播地址（永久组地址），地址224.0.0.0保留不做分配，其它地址供路由协议使用；
224.0.1.0～224.0.1.255是公用组播地址，可以用于Internet；
224.0.2.0～238.255.255.255为用户可用的组播地址（临时组地址），全网范围内有效；
239.0.0.0～239.255.255.255为本地管理组播地址，仅在特定的本地范围内有效。
=======================
组播也是一种IP包，也有源IP地址，目的IP地址，源IP地址为组播源的服务器IP地址，目的地址为一个特殊的IP地址，它位于 224.0.0.0 - 239.255.255.255 中，由于 224.0.0.0/24用于本地链路，即一跳的组播，239.0.0.0/8 为私有组播地址，所以实际的可用于在互联网上组播地址是225.0.0.0/8 - 238.0.0.0/8，这个组播地址不属于任何服务器或个人，它有点类似一个微信群号，任何成员（组播源）往微信群（组播IP）发送消息（组播数据），这个群里的成员（组播接收者）都会接收到此消息。
IPTV就是组播的应用：
IPTV里的一个电视频道对应一个组播IP， 假设CCTV1 对应的组播IP =238.1.1.1 ，IPTV节目源IP=1.1.1.1，就以238.1.1.1 为目的地址封装发送，这里有两个问题需要解决：
IPTV组播源不知道收看此节目的用户在哪里？
收看此节目的用户不知道IPTV组播源在哪里？
用户IPTV机顶盒只知道节目组播地址为238.1.1.1 ，至于谁是这个节目源（IP=1.1.1.1）并不清楚。
于是就引入了一个中介机构（RP），Rendezvous Point，RP点，组播的汇聚点，RP IP = 2.2.2.2 ，组播源通过单播隧道的方式把组播238.1.1.1 发给 RP，简称组播源的注册。
机顶盒静态配置了RP IP = 2.2.2.2，知道RP会有组播数据，于是就向RP（ 2.2.2.2）申请加入这个238.1.1.1 的组，于是RP就把自己收到的注册组播源数据发送给机顶盒，这个就是基于RP的 树，RPT。
机顶盒收到第一个组播包，定睛一看，原来组播源是1.1.1.1，于是发一个申请给1.1.1.1 ，申请加入238.1.1.1，这就是基于源的 树，SPT。即然已加入了SPT ，就不需要RPT 了，向RP申请退出就可以了。
着重强调一点：一旦组播用户（接收者）知道了组播源，那RP的任务就算完成了，RP的存在就是为了组播接收者发现组播源，组播用户会加入路径更优的SPT树，会申请退出路径不是最优的RPT树，避免收到两份组播的复制。
以上就是组播工作的大概过程，IPTV是IGMPv2 以及 PIM SM mode 的一个应用。
IPTV是电信独立的IP网络，部署起来很容易；但是如果在全球网络里部署组播，将会遇到很多挑战。
如果想了解IGMPv3 以及PIM SSM 请回复，会继续更新。
------------------------------------
IP multicast 组播
在组播的世界里，我们又见到了树的概念，关于树，你一定会有似曾相识的感觉，二层交换网络就有树的概念了，那个树我们称之为：生成树，spanning tree，尽管这个树中文名称有点别扭，但它就是一棵树。
喜爱大自然的童鞋仔细观察一棵树，会发现一棵树，有根，主干，树杈，叶子，水分通过根，源源不断地输送到主干，树杈，然后到达叶子。水分在从根扩散到叶子的过程中，一直是单向的，没有水倒流的现象，即使水有倒流，也不会有环路，因为树的结构是发散的，没有物理的树杈的交织，自然不会发生环路。
网络科学家发现了这个规律，有一个大胆设想，如果把树的拓扑结构用于二层交换网络，在二层网络里选择一个根（root bridge)，其它交换机当作树的树杈，每个树杈自然有一个根末梢（root port)，这个就是交换机的上游接口，除了根末梢，其它的接口都是下游接口，至于下游接口是畅通的、还是阻断的，取决于到根的路径成本，谁更接近根，谁就畅通（Forwarding) ，即常说的Designated Port; 谁远离根，谁就需要被阻断（Blocked), 即常说的 Non Designated Port。通过这种仿生的机制，可以有效地避免网络环路。
今天我们主题并不是spanning tree，而是组播树。至于为什么要有树的概念，上文已经阐述，为了避免潜在的网络环路，那我们来谈谈组播树的概念。
组播第一个挑战就是组播的接收者（Receiver）不知道组播源在哪里，换句话说，就是不知道组播源的IP地址，如果知道了，可以直接向这个IP地址发送加入组播的请求，那一切就简单了，组播可以直接推送到组播的接收者。这仅仅是一个美好的假设，事实是接收者无从知道组播源的IP地址。
为了克服这个困难，引入了一个中介机构（RP），Rendezvous Point，RP点，组播的汇聚点。
为了更便于阐述这个复杂的过程，假定：
Multicast Source IP: 1.1.1.1
Multicast Group IP : 238.1.1.1
Rendezvous Point IP: 2.2.2.2
IGMPv2: Host chat with Router
PIM Sparse Mode: Router chat with Router
于是组播源就把组播238.1.1.1封装在一个单播（source IP 1.1.1.1，destination IP 2.2.2.2) 发给RP，我们称之为组播源的单播注册。
虽然组播的接收者不知道组播源在哪里，但他们深深地知道，他们所在的广播域里的路由器一定知道，而路由器如果静态配置RP，或动态发现RP，可以知道RP在哪里，可以间接的知道组播源在哪里。这就是美其名曰的：曲线救国！
于是组播接收者用IGMPv2发送一个广播请求，这个广播域里的路由器听到了这个广播请求，查询自己的单播路由表，可以知道谁是通向RP的上游路由器，然后发送一个PIM Join请求给上游，上游路由器按照相同的方式把这种Join 请求一级一级的中继到RP，RP简单地将收到Join请求这个接口放入组播出接口列表（OIL），然后把组播仅仅复制（Replication)一份从OIL发送出去。PIM Join 在层层向上中继的过程，路由器已经形成一个上下游的关系，越是靠近RP的路由器，为上游；而远离RP的路由器，为下游。这其实就是一种树，因为树的根是RP，我们称这种组播树为基于RP的树，即RP-Based Tree，简称RPT。
当组播接收者直连的路由器收到第一个组播，就知道组播源在哪里？为什么？因为组播包里的源IP告诉我们的啊！于是向组播源IP发起了一个新的PIM Join请求，为什么要这样啊？是不是画蛇添足啊？好，我们来分析一下：
组播先从组播源发到RP，然后再从RP顺着RPT树一级一级向下游扩散，直到到达组播的接收者，这条路径有点绕，因为先要绕到RP，所以不是最优路径。既然RP的存在是为了组播的接收者发现组播源，那一旦这个任务完成了，也就没有必要再走这条有点绕路的路径了，为什么不直接走组播源到达组播接收者的路径呢？省时、省力、省路径！于是组播接收者的直连路由器向着组播源1.1.1.1的方向，如何知道？查询单播路由表啊，然后顺着朝向1.1.1.1 的方向发送 Join 请求，也是一级级向着上游发请求，直到到达组播源1.1.1.1，这个有上下游关系也是组播树，因为树的根是组播源，我们称之为：基于源的树，Source Path Tree，简称SPT。
即然加入了SPT树，收到了组播数据，就没有必要赖在RPT树上，否则将会收到两份复制，这实在没有必要。于是组播接收者直连的路由器向RP提出leave 请求，RP将收到 leave 请求的这个接口从OIL列表里删掉，即不会再复制组播数据了。
忘了一个细节，RP在接收到组播源的单播注册，会发一个单播停止消息给组播源，即 Register Stop 消息，既然RP已经知道组播源在哪里了，继续单播注册就没有必要了。同时RP也会朝着组播源1.1.1.1 的方向发送Join请求，请求加入SPT树。
组播是个很有趣，又很实用的技术，简单的介绍一下三层环境、IPv4情况下，组播的简单概念吧。
P2P会造成大量的数据重复，并且给路由器造成很大的压力，广播又让每一个接收者去判断流量是不是给自己的，在浪费带宽的同时也给所有人带来判断流量的压力。组播便应运而生，它实现的关键技术在于把流量给合适的路由器，并且在合适的节点复制，尽可能的减轻网络负担。
组播的关键技术有两大块，一个是IGMP: internet Group Management Protocol，一个是PIM: Protocol Independent Multicast。我们从接收者往上说。先说下组播基础知识，224.0.0.1是向本网段所有设备发送组播报文，224.0.0.2是向本网段所有路由器发送组播报文。换句话说收到这个报文的接收者会因此判断这个包是不是给自己的。
接收者到终端节点采用的是IGMP技术，目前主要应用的是IGMPv2，v1和v3不去扩展。IGMP技术完成的主要功能就是题主问的加入组播地址的意思。要研究IGMPv2工作的机制（偷懒不分析报文了）有几个关键点，目的地址（给谁发），加入的组，TTL = 1。
服务端会向目的地址（224.0.0.1），加入的组（0.0.0.0），这条报文的意思是，朋友有谁加了哪个组播组吗？告诉我一下。
客户端，也就是PC用户，如果你点播了某个节目，加入了组，比方说是224.1.1.1这个组。那就是发送报文，目的地址（224.1.1.1），加入的组（224.1.1.1）。目的地址和组是同一个的目的是为了抑制其它PC发送同样的报文，因为路由器已经知道这个组有人，不需要再发送一次了。
在IGMPv2中，客户端离组也是要发消息的。会发一条目的地址（224.0.0.2），加入的组（224.1.1.1）这样一条消息，告诉服务端，我走了，你再看看其它人吧。
就简单说这三种报文吧，想详细了解时间信息，报文包头等内容可以留言。
好了，经过IGMP报文提供的消息后，我们已经知道了，最终端用户有哪几个组，也就是说，我们需要给哪些终端的服务器发送哪些组播报文是已经清楚了，但从最初始的源是如何经过层层设备到达终端的呢？幸好我们有PIM协议。
PIM协议也是很复杂，在这里大概介绍一下。PIM模式完成的主要功能是尽可能简单的给相应组的路由器发送消息。完成简单这项功能，采用了SPT: Shortest-Path Trees or Source Distribution Tree，RPT: Shared Distribution Trees，这两种树型结构和DR一同完成了这项功能。正确的发送信息有两种模式Dense Mode，Sparse Mode。Dense是推流模式，也就是说相当于从源端主动向客户端路由器推送组播信息，Sparse是拉流模式，相当是客户端路由器从源端拉取自己想要的信息。还有两者结合的方式，Auto-RP这些先不说了。有需要再留言吧。
其实，IPv6对组播的支持要更好一些，但掌握点IPv4的技术总是没有错的，学习一个技术的历史才能更好的了解它。
组播并不像单播，有一个明确的目的主机和IP地址，也不像广播，局域网内的所有主机都是目的主机，广播IP地址也明确（主机标识全部置为1）。组播不同，它并不知道要把信息发给谁，因为谁都可能随时加入组播组，谁都可能随时离开，不可能用某一个主机的IP地址作为组播地址
组播IP
组播不可能以某一个主机的IP作为自己的目的IP，但是以太网报文在封装时必须要填入目的IP
怎么办？
回想一下，组播IP不能以某个主机的IP作为自己的目的IP，换句话说，组播IP不需要考虑主机标识，哪个类型的IP地址没有主机标识，D类
“由于224.0.0.0/24用于本地链路，239.0.0.0/8为私有组播地址，所以实际可用的组播地址为225.0.0.0/8 - 238.0.0.0/8“
组播MAC
同样地，组播报文在数据链路层需要填充目的MAC地址，如何填充正确的MAC地址呢？
单播报文在填入目的MAC时，会通过ARP协议根据目的IP询问目的主机的MAC地址，而组播由于目的IP并不是某个主机的IP，所有无法用ARP协议询问目的MAC。既然ARP寻址方式行不通，组播MAC地址有自己的转换方式
组播IP映射为组播MAC
虽然无法ARP寻址，但是可以借鉴通过目的IP寻找目的MAC的方式，把组播IP映射为组播MAC
IEEE对MAC地址定义：MAC地址的第一个八位组的bit0指明了目标地址是广播/组播地址，还是单播地址
所以在对网卡设置MAC地址时，这一位千万不能设置成1
对于以太网而言，组播MAC地址以0x 01 00 5E为前缀，剩下的24位可以被组播使用，通过把组播IP映射到这24位
如何映射？
“组播IP的前四位固定1110，剩下的28位才是有用的信息，而这28位由于某些原因，我们需要把前5位扔掉，取后23位，映射到组播MAC地址的后24位
”
至于为什么只取23位，有一个有趣的历史
============ End
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· SQL Server 2025 AI相关能力初探
· Linux系列：如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 探究高空视频全景AR技术的实现原理
· 阿里最新开源QwQ-32B，效果媲美deepseek-r1满血版，部署成本又又又降低了！
· SQL Server 2025 AI相关能力初探
· AI编程工具终极对决：字节Trae VS Cursor，谁才是开发者新宠？
· 开源Multi-agent AI智能体框架aevatar.ai，欢迎大家贡献代码
· Manus重磅发布：全球首款通用AI代理技术深度解析与实战指南