一句话：NO

多播是一个一对多的系统。TCP 需要一对一的握手来同步计数器（序列号）以确保可靠传输。这不能用许多接收器来完成，因为发送器无法知道有多少接收器，因此无法知道有多少 ACK，或者如果其中一个接收器在传输过程中消失该怎么办，等等。

将多播视为演讲厅中的演讲者。他们不知道应该有多少人在那里，也不关心是否有人迟到或离开。他们也不知道（或关心）大厅里的每个人是否都听到了他们所说的一切。

不可以。即使 TCP 由两个独立的发送方/接收方关系组成，通信也需要是一对一和双向的。

但是有一些协议通过多播实现可靠传输，但它们通常使用反向树（发布者变成消费者，反之亦然）来进行否定确认。它们与 TCP 非常不同。

是的。

如果“TCP 中的多播”意味着“多播 IP 上的 TCP”，那么答案是否定的，我可以在 5 年前 Ricky Beam 的出色回答下签字。

如果“TCP 中的多播”是指使用 TCP 的多播服务或应用程序，则是可能的。它将允许单个发送方（caster）使用多个 TCP 连接通过单播 IP 向多个接收方发送数据流。这可以在应用程序级别、新的传输层或什至在 TCP 级别通过可称为“多播 TCP 代理”的元素来完成。这些解决方案都不需要更改 TCP/IP 堆栈实现。

与您已经收到（并且可能会收到）的所有其他答案不同：

是（但以前没有人做过）

TCP 是一种面向流的协议，因此必须建立请求和响应之间的逻辑连接 - 在多播的情况下，至少缺少一个重要信息：接收者地址。没有它，相当多的算法（如果不是全部）将停止工作。

解决方案似乎非常复杂 - 人们需要在网络层的所有方面（奇怪的人称其为“互联网层”）的所有（！）数据包因此创建一个全新的协议，该协议实际上只是映射到真实的一。另外：您的多播流量不会被路由到您的本地网络边界之外，实际上所有 ISP 都会拒绝这些数据包。

另外：多播发送者将不得不处理这些传输中的每一个的n 个答案 - 这将显着降低带宽增益，实际上它肯定也会增加处理时间并且可能会使大多数 NIC 处理芯片过载。

不过，这可能是一个非常酷的实验——您将需要高级编程技能和大量有关计算机网络、操作系统和网络标准的知识:)