multicast 组播流必须用udp吗？ tcp为何不行

multicast 组播流必须用udp吗？ tcp为何不行

先说结论：实际使用中没有tcp方式

为什么 TCP 无法实现组播

1. ACK 风暴问题
   TCP 要求接收方发送 ACK 确认。如果 1 个发送者向 10,000 个接收者组播：

   发送者会收到 10,000 倍的 ACK 流量（ACK implosion）
   网络瞬间被反向流量拥塞，发送者无法处理

2. 重传冲突

   不同接收者丢失的数据包不同
   TCP 无法决定"该重传哪个包给谁"——没有独立的 per-receiver 队列
   发送者无法维护与数千个节点的独立滑动窗口

3. 连接建立悖论
   TCP 需要三次握手建立连接：

   组播组成员动态变化（随时加入/离开）
   发送者无法与所有潜在接收者预先建立连接
   无法处理"谁在线"的不确定性

4. 状态爆炸
   维护 10,000 个 TCP 连接的状态（序列号、窗口大小、重传定时器）需要巨大内存和 CPU，且完全违背组播"高效分发"的设计目标。
   组播的正确设计哲学
   组播追求的是网络层效率，而非端到端可靠性：

传统单播：服务器 → 复制 N 份 → 分别发送给 1000 人（带宽 ×1000）
组播：     服务器 → 发送 1 份 → 路由器复制分发（带宽 ×1）

如果强行叠加 TCP 的可靠性，会摧毁组播的核心优势。
需要可靠性时的解决方案
当业务需要可靠组播时，采用应用层方案而非 TCP：

UDP + 组播 = 天生一对，无连接特性完美匹配一对多分发
TCP + 组播 = 技术上不可能，语义冲突无法调和
可靠性需求 = 在 UDP 之上构建应用层协议，而非改用 TCP

这也是为什么 RTP/RTSP（流媒体）、NTP（时间同步）、mDNS（局域网发现） 等所有组播应用都基于 UDP 的原因。