任播如何与 tcp 一起工作？

Question

TCP 是有状态的，应该要求后续数据包到达同一服务器。（无状态）HTTP 在 TCP 之上运行，CDN 可以使用任播。

那么 TCP 是如何与任播一起工作的呢？如果 syn 和 ack 转到不同的服务器怎么办？我想我听说谷歌对此有一些解决方案，但我不确定。

如果有任何区别，请同时回答 IPv4 和 IPv6。

Answer 1

这是众多挑战之一，可以通过许多不同的方式来应对。最简单的方法是忽略它并希望最好。只要路由不改变中间连接，就可以了。但是当路由发生变化时，它会破坏所有受路由变化影响的连接。使用这种方法，其他答案已经更深入了。

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

在带宽消耗方面，开销不是很大，因为它只影响一个方向的数据包，而且往往是带宽占用最少的方向。

跟踪可以在连接级别或通过跟踪哪个是为每个单独的客户端 IP 地址提供服务的首选 POP 来完成。用于跟踪连接的最明显的数据结构是分布式哈希表。

如果客户端支持 MPTCP，则可以使用另一种解决方案。一旦建立连接，服务器将使用单播 IP 地址打开另一个子流。如果这样的子流成功建立，则连接可以通过在连接的剩余生命周期中简单地使用单播地址而在任播地址的路由改变后幸存下来。

原则上，上述所有方法对于 IPv4 和 IPv6 都是相同的。但在实践中，由于 IP 地址短缺，某些解决方案在 IPv4 上可能无法正常工作。

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

不知道CDN使用了以上哪种方式。

Answer 2

任播最恰当的描述是“一对一”路由方案，通常通过让 BGP（边界网关协议）宣布来自多个源的目标 IP 来工作，从而将数据包路由到列出的最近的目标 IP。

因此，从广义上讲，选播只是用于确定要连接到哪个服务器，并且没有任何内容使其不适合 TCP 或有状态网络。

选播的主要用例是在 CDN（内容交付网络）中，它通常具有短暂的和/或无状态的连接 - 正如您在交付大量小型静态网页内容时所期望的那样。在此用例中，考虑到典型会话长度较短，选播假设网络拓扑至少在会话长度内保持不变是一个相当安全的假设，并且该假设变为错误的最小后果 - 最坏情况，会话中途失败，用户重新加载网页。

对于较长的会话或不能容忍中断的使用，使用选播的缺点是网络拓扑更有可能在较长的时间范围内发生变化，如果发生这种情况，连接将悄然中断。（流行音乐切换。）正如您在问题中提到的，谷歌（和其他人）正在研究解决这个问题的专有方法，但目前，这都是专有和秘密的。

因此，关于任播如何与 TCP 一起工作的问题的答案实际上是它工作得很好，除非网络拓扑发生变化……如果拓扑发生变化，它[可能]会中断。

这里有一个有趣的演示（警告，pdf），其中包含有关选播使用的真实世界数据，包括一些长期存在的会话，并且似乎在现实世界中，“弹出切换”（网络拓扑在中间发生变化）会话并中断连接）是一种非常罕见的体验 - 在一个数据集中，有 683,204 个会话和 23,795 个会话时间超过 10 分钟，只有 4 个会话发生了弹出切换。