如何使用TCP的任播？

这是许多挑战中的一个，可以通过许多不同的方式来解决。 最简单的方法是忽略它，并希望最好的。 只要路由不改变中间连接，就可以了。 但是当路由改变时，它将打破所有受路由改变影响的连接。 其他答案已经深入这个方法。

另一种方法是跟踪连接的路由。 如果数据包路由到错误的POP，CDN可以将数据包隧道传送到正确的POP进行进一步处理。 这确实会带来额外的开销，一旦发生，客户端会遇到延迟增加。 这种增加的延迟将在连接的整个生命周期中持续存在。 但是，对于用户体验而言，可能比断开的连接更好。

就带宽消耗而言，开销并不是很大，因为它只影响一个方向上的数据包，往往是带宽使用量最小的方向。

跟踪可以在连接级别完成，也可以跟踪哪个首选POP服务于每个客户端IP地址。 跟踪连接的最明显的数据结构是分布式散列表。

如果客户端支持MPTCP，则可以使用另一种解决scheme。 一旦build立连接，服务器将使用单播IP地址打开另一个子stream。 如果这样的子stream成功build立，那么连接可以在单播地址的路由改变的情况下通过简单地使用单播地址来保留连接的剩余生存期。

原则上，所有上述方法对IPv4和IPv6都是一样的。 但实际上，由于IP地址不足，某些解决scheme可能无法在IPv4上运行。

例如，MPTCP方法确实要求每个服务器都有一个公共IP地址才能正常工作。 一个大的负载均衡设置可能会有太多的服务器为每个分配一个公有IP地址。 另外，如果客户端在NAT之后（这在IPv4中常常是这种情况），则不能由服务器发起build立新的子stream。 这意味着服务器将不得不通过初始子stream发送单播IP地址作为选项，并让客户端启动额外的子stream。

我不知道以上哪种方法已被CDN使用。

它比你期望的更好，特别是对于通常很短的TCP会话，比如HTTP客户端生成的会话。

Anycast认为networking拓扑结构在会话持续时间内不会改变，如果发生改变，则另一个端点不可能突然比谈判会话的端点更近。 应用程序协议应该处理这种断开/重新连接活动。

CDN在Anycast上运行得非常好，因为它们的整个业务模型都是短暂的TCP会话，并且在networking之外有明显的单向networking传输。 如果ACKstream最终转到了最初协商的端点以外的其他地方，则该连接将为该资产挂起。

Anycast最好被描述为“一个到最近的”路由scheme，并且通常通过使BGP（边界网关协议）从多个源公告目的地IP来实现，从而导致数据包被路由到最近的列出的目的地IP。

所以从广义上讲，Anycast只是用来确定要连接哪个服务器，而没有任何关于它使TCP不适合或有状态的networking。

选播的主要用例是CDN（内容分发networking），它通常具有短暂的和/或无状态的连接 – 正如您在交付大量小型静态网页内容时所期待的那样。 在这种使用情况下，由于典型会话的长度很短，Anycast认为networking拓扑结构至less在会话期间保持不变的假设是一个相当安全的假设，假设的假设的最小后果是最坏的情况，会话中间失败，用户重新加载网页。

在较长的会话中使用Anycast的缺点，或者在不能容忍中断的情况下使用Anycast的缺点是，networking拓扑结构在更长的时间段内更可能发生变化，如果发生这种情况，连接将自动中断。 （stream行音乐切换）当你提到你的问题时，Google（和其他人）正在研究解决这个问题的专有方法，但是现在，它是专有的和秘密的。

所以对于你的问题，如何selectTCP的问题的答案是真的，它工作得很好，除非networking拓扑改变…如果拓扑改变，它[潜在地]中断。

在这里有一个有趣的演示（警告，pdf） ，其中包含有关使用任播的真实世界的数据，包括一些长期的会话，看起来在现实世界中，“stream行切换”（networking拓扑变化的中间的会话并断开连接）是非常罕见的体验 – 在一个数据集中，有683,204个会话，23,795个会话超过10分钟，只有4个会话被切换。