IPv6 Multicast用于全场景通信的弊端及替代Unicast的技术权衡

背景与核心疑问 #

我已经在本地网络实现了IPv6组播，并且成功在家庭和办公室之间完成全局通信，效果很好。但我注意到，IPv6组播支持发布-订阅模型，理论上适配绝大多数通信场景，可实际除了视频流之外极少被采用。我想搞清楚：

• 这是因为它仅对大型组通信高效，还是因为开发者理解不足、单播/任播的实现门槛更低？
• 即便只有2个成员的组，组播理论上也比单播更高效灵活——任意一方都能随时退出组，而且发送数据时仍依赖单播地址。那为什么没被广泛替代？
• 我意识到组播需要维护订阅者集合的状态，但只要在网络边缘按需复制数据包，应该不会增加太多开销？
• 我知道当前全局作用域IPv6组播存在部分支持限制，但这个问题更关注用IPv6组播替代单播的理论层面与权衡点，希望了解我忽略的问题，以及相关的核心权衡逻辑。

容易忽略的关键限制与弊端 #

1. 端到端可靠性的天然缺陷 #

组播的设计目标是尽力交付，不像单播有成熟的TCP协议提供重传、拥塞控制、顺序保证等可靠性机制。如果要在组播上实现可靠传输，需要自行构建上层协议（比如自定义ACK/NACK逻辑），但多成员场景下的ACK风暴、丢包恢复复杂度极高，远不如单播的TCP开箱即用。

2. 网络设备的支持差异与部署复杂度 #

虽然你在自己的环境里实现了全局通信，但公网中不同运营商、路由设备对IPv6组播的支持程度参差不齐：

• 部分骨干网路由器可能禁用组播路由，或者对组播组的数量、流量有严格限制；
• 网络地址转换（NAT）场景下，组播的穿透处理比单播复杂得多，尤其是IPv6过渡阶段的混合网络环境；
• 组播需要IGMPv3/MLDv2等协议来维护订阅状态，这些协议的配置、调试对运维人员的要求比单播更高。

3. 应用层生态的缺失 #

绝大多数现有应用都是基于单播设计的：

• 开发框架、SDK几乎没有原生支持组播的通用方案，开发者需要从零实现组播的订阅、发送、异常处理逻辑；
• 监控、调试工具对组播流量的支持远不如单播，排查问题难度大；
• 服务发现、负载均衡等配套机制在组播场景下需要重新设计，没有现成的成熟方案。

4. 小型组通信的实际效率劣势 #

你提到2成员组的组播理论更高效，但实际场景中：

• 单播的数据包不需要经过组播路由的状态查询、复制逻辑，在网络设备层面的处理延迟更低；
• 组播的订阅/退订流程本身会产生额外的控制平面流量，对于小型、频繁变更的组，这些控制流量的开销可能超过数据传输的收益；
• 多数网络对单播流量的优先级、带宽保障更完善，组播流量可能被限流或优先丢弃。

5. 安全层面的挑战 #

组播的开放性导致安全问题更难处理：

• 任意节点都可以加入组播组，容易出现恶意节点监听或发送垃圾流量；
• 组播的加密需要采用组密钥管理方案，密钥分发、更新的复杂度远高于单播的端到端加密；
• 缺乏成熟的身份验证机制来限制组播组的成员资格。

内容的提问来源于stack exchange，提问作者Monkish Rex