周传炽发给你的程序发不成功，那就只能先聊点正经的——组播问题，几乎每个搞网络、搞音视频、搞工业通信的人都会碰见，而且十有八九会问出同一个困惑：multicast 组播流必须用 UDP 吗？TCP 为什么不行？ 这个问题看着简单，但解释不好容易越讲越绕。我最初是在调试一套 IPTV 组播转发链路时被这个问题卡住的，后来把 TCP 的协议机制和组播的传输模型摆在一起对比，才算彻底想明白。这篇就把我自己的理解、踩过的坑、以及实际测试验证的过程完整写出来。
1. 需求源头：什么场景下会出现“组播流”这种说法
1.1 组播解决的核心问题：一份流喂饱一群终端
组播的英文叫 multicast，直译过来就是“多点传输”。它解决的是一个很朴素的问题：网络上同一份数据要发给多个接收端，怎么发最省？
最直接的思路是每个接收端单独发一份，这就是单播（unicast）。一个会议室里 50 台终端都要看同一路视频，那就得发 50 遍。网络本身没问题，但出口带宽和交换机压力成倍增长。如果是公网上的流媒体平台，服务器带宽更是烧钱的大头。
另一种思路是广播（broadcast），把数据发给网段内所有人，网段内每台机器都会收到。但广播有个巨大缺陷——没有选择性。不管你想不想要，只要在同一广播域内都会被强制接收，网络里如果广播流量一多，所有主机都得花 CPU 去处理跟自己无关的报文，效率反而更差。
组播站在中间：数据只发一份，路由器或交换机根据接收者的实际分布，在需要的地方复制报文，最终精准送到每一个申请了该组播组的接收者。发送端既不关心具体有谁在收，也不需要维护一堆连接，一份流量从头走到尾，直到最后一跳才复制。
我做 IPTV 项目时就深有体会：一路 8Mbps 的高清流，如果给 200 个机顶盒各自单播，核心交换机出口就得扛 1.6Gbps；而用组播，服务器出去的流量始终只有 8Mbps，压力全在交换机复制那一下子，技术上完全不是一个量级。
1.2 和广播、单播的边界在哪里
这三个概念经常被放在一起对比，但它们的核心区别在“接收者是谁”上：
- 单播：一对一的通信，源地址和目标地址都是单一的 IP。
- 广播：一对所有的通信，目标地址是广播地址（如 255.255.255.255），数据会发给同一个二层广播域下所有设备，不管人家愿不愿意收。
- 组播：一对多（或多对多）的通信，目标地址是 D 类组播地址（IPv4 的 224.0.0.0/4），只有加入了对应组播组的设备才会收到数据。
注意，这里的目标地址是一组设备的抽象，不是某一台设备。这个“组”是动态的：主机可以随时加入，也可以随时退出。这正是后面理解“TCP 为什么不行”的关键线索。
1.3 现实场景：IPTV、行情分发、视频会议
组播最常见的应用场景我再补充几个：
- IPTV/数字电视：运营商电视业务基本都走 IP 组播，频道切换时通过 IGMP 加入对应的组播组，机顶盒立刻开始收流。
- 金融行情分发：证券、期货行情系统里，行情数据同时推送给成千上万个交易终端，组播几乎是标配。我们测试时用组播行情，交易所到机房的链路流量非常稳定，不会因为终端数量增加而线速暴涨。
- 视频会议/在线课堂：多人同时观看同一个画面，MCU（多点控制单元）或 SFU 转发时，也会用到组播来优化带宽（虽然很多商业会议软件出于 NAT/防火墙考虑最终选择了应用层单播转发）。
- 工业自动化/集群同步：分布式系统中做状态同步、日志复制，也会用到组播组发现和数据分发。
知道了这些应用场景，我们再回头看“为什么非要用 UDP”，思路就清楚了。因为 TCP 的整套设计赌的是“一个发送者对一个接收者”，而组播的模型是“一个发送者对一组动态接收者”。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。