TCP 兼容性：为什么 TCP 不兼容数据包广播和组播操作？
** http://en.wikipedia.org/wiki/User_Datagram_Protocol：**
“与 TCP 不同，UDP 与数据包广播（发送给本地网络上的所有用户）和多播（发送给所有订阅者）兼容。”
** http://en.wikipedia.org/wiki/User_Datagram_Protocol: **
"Unlike TCP, UDP is compatible with packet broadcast (sending to all on local network) and multicasting (send to all subscribers)."
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
“兼容”在这里是一个非常糟糕的词选择。 “支持”才是真正被描述的。 TCP 在设计上是一种点对点协议。时期。 TCP 多播是一个矛盾的术语。
编辑：我更新了维基百科页面以反映此评论。
编辑2：令人难以置信的是，自从这个问题发布以来，有人已经从维基百科UDP页面中删除了所有对多播的提及。我修好了。再次。
'Compatible' is a very poor choice of words here. 'Supports' is what is really being described. TCP is a point to point protocol, by design. Period. TCP multicast is a contradiction in terms.
EDIT: I updated the Wikipedia page to reflect this comment.
EDIT 2: Incredibly enough, somebody has removed all mention of multicast from the Wikipedia UDP page since this question was posted. I fixed it. Again.
TCP 在发送方和接收方之间建立连接。发送方发送一个数据包，然后等待接收方的确认，然后再发送另一个1。如果数据包持续时间太长而没有得到确认，它将重新发送数据包，直到收到确认（这就是它获得可靠性的方式）。
在多播和广播的情况下，发送者甚至不知道可能有多少个接收者，更不用说他们是谁了。如果有人没有正确确认数据包，那么它几乎不可能等待确认并重新发送数据包。
1从技术上讲，有一个“窗口”允许它在收到确认之前发送五个数据包，但你明白了——它仍然需要知道谁在接收，并获得数据包的确认它发送的数据包，如果未确认则重新发送数据包。
TCP establishes a connection between the sender and the receiver. The sender sends a packet, then waits for acknowledgement from the receiver before sending another1. If a packet goes too long without being acknowledged, it resends the packet until it does receive an acknowledgement (that's how it gets its reliability).
In the case of multicast and broadcast, the sender doesn't even know how many receivers there might be, not to mention who they are. That makes it pretty much impossible for it to wait for confirmation and re-send packets if somebody doesn't acknowledge a packet correctly.
1Technically, there's a "window" that allows it to send, say, five packets before it receives acknowledgement, but you get the idea -- it still needs to know who's receiving, and get acknowledgement of packets that it sent, and re-send packets if they're not acknowledged.
TCP 结合了基于数据接收者确认的流量控制和可靠性。广播或多播发射机不知道哪些或有多少其他节点正在监听；即使它通过某种类似于 TCP 点对点同步的多点同步算法来实现，流量控制也会成为一个问题，因为在最坏的条件下接收器会限制整个流量的速度。
TCP incorporates both flow control and reliability based on acknowledgment from the recipient of the data. A broadcast or multicast transmitter has no idea which or how many other nodes are listening; even if it did by some sort of multipoint synchronization algorithm similar to TCP's point-to-point synchronization, flow control would be an issue because the receiver under the worst conditions would limit the speed of the entire flow.
简短的回答是因为广播 TCP 很复杂。
长的答案是，TCP 协议的重要部分，即移植到广播语义时的可靠性和拥塞控制，很容易被滥用，扩展性不好，而多播只是 IPv4 标准的可选组件，要么没有实现或在大多数核心路由器上禁用。
已经发表了许多研究新协议以提高可扩展性的论文； IPv6 将组播提升为核心协议要求，并与源特定组播一起显着提高了核心路由支持和安全性；留下仍然严重的滥用领域。
滥用涵盖了协议的许多方面，从中间人攻击到网络基础设施超载，导致上游流量出现网络风暴。
如今，在 Windows 计算机上，您可以使用支持流的 PGM 协议，该协议的运行方式与广播 TCP 非常相似。它被微软的消息系统MSMQ使用。
http://msdn.microsoft.com/en-我们/library/ms740125(v=vs.85).aspx
The short answer is because broadcast TCP is complicated.
The long answer is that the important parts of the TCP protocol, namely reliability and congestion control when ported to broadcast semantics are easily subject to abuse, don't scale well, and multicast is simply and optional component of the IPv4 standard and either not implemented or disabled at most core routers.
Many papers have been published investigating new protocols to improve scalability; IPv6 promotes multicast to a core protocol requirement and alongside source-specific-multicast significantly improves core routing support and security; leaving the still significant area of abuse.
Abuse covers many aspects of the protocol, from man-in-the-middle attacks, to overloading network infrastructure, causing network storms of traffic upstream to the source.
With a Windows machine today you can use the PGM protocol with streams support which operates pretty much as broadcast TCP. It is used by Microsoft's messaging system MSMQ.
http://msdn.microsoft.com/en-us/library/ms740125(v=vs.85).aspx