如何为我的服务器获取任播？

Question 1

为了满足您的特定请求，您需要了解有关任播的两个不同方面。第一部分是如何通告和路由任播地址。第二部分是 TCP 到任播地址的挑战是什么，以及如何解决这些挑战。

通告和路由

为了使 BGP 表保持可接受的大小，如果前缀太长，大多数 AS 都会过滤传入的公告。对于 IPv4，阈值往往是 /24 前缀，这意味着 256 个地址。这意味着为了在公共互联网上进行任播，您至少需要 256 个地址。

如果您已经拥有自己的 /24 前缀，那么就没有什么可以阻止托管服务提供商代表您宣布该前缀了。如果是这种情况，那么对您来说，任播可能很简单，只需找到一群愿意以合适的价格提供此服务的不同托管服务提供商即可。然后，您只需让他们都代表您宣布前缀即可。

您可以查看已公布路线的公开信息，以查找已代表客户公布前缀的提供商，从而引导您找到可能提供此类服务的提供商。在路由表中查找此信息的一个工具是河北省地质调查局。

如果您没有自己的前缀并想从提供商处获得一个，那么了解上述限制对该提供商意味着什么就很重要。

提供商拥有足够的 IP 地址，因此他们可以配置任播前缀。但是，一旦他们这样做，他们就必须将所有 256 个地址用作任播。并且所有 256 个地址都必须托管在同一组位置中。

因此，您有时会看到分配了 256 个地址，以便只使用其中一个地址进行任播服务。这可能是您的第一次机会。已经进行过前缀任播的提供商实际上可能有 250 个未使用的任播地址。如果您的服务对提供商来说足够“有趣”，他们可能愿意将其中一个剩余地址作为主机托管租给您。一个重要的警告是，您必须托管在与他们的主要任播服务完全相同的位置。并且可能需要一种安排，让他们根据自己的意愿移动您的服务，因为他们的主要任播服务决定了需要托管的位置。

上述大部分内容都假设提供商托管服务的位置和他们宣布前缀的位置之间存在大致 1:1 的对应关系。

如果托管提供商拥有自己的冗余主干网和自己的数据中心，那么他们可以在与托管位置不同的一组位置发布前缀。此外，在内部，他们可以将较长的前缀路由为单播或任播。

例如，如果提供商在四个不同的 POP 中宣布 /22，并且它们之间有一个冗余网络（例如四个链路的环），那么他们可以内部将 /24 或 /25 路由到每个 POP，并可能留出 /28 以任意广播到所有 POP（这实际上意味着由数据包首次进入其网络的 POP 提供服务）。

如果您能找到一个同时拥有冗余主干和数据中心的提供商，那么这样的提供商可以更轻松地为您的服务任意广播他们自己的 IP 地址之一。但请记住，这样做会占用他们每个主干路由器中的一个 CAM 表条目。而且您必须为此付费。

TCP 和任播

正如一些评论所指出的那样，TCP 是一种有状态协议。因此，即使您认为您的 Web 服务是无状态的，它在 TCP 层仍然具有状态。其结果是，单纯地对基于 TCP 的服务进行任播将导致用户非常频繁地遇到连接重置。

通过在实际 Web 服务器前面添加另一层，可以解决该问题。需要一层节点，可以将收到的 TCP 数据包转发到正确的 Web 服务器，并在连接中始终如一地执行此操作。到目前为止，这几乎描述了基于标准 DSR 的负载均衡器。

但是由于此负载均衡器有多个实例，它们需要共享状态。分布式哈希表是一种可用于此层的数据结构。

此外，来自负载平衡层的数据包需要原封不动地转发到后端。基于原始数据包目标 IP 的 IP 路由无法解决该问题，因为该目标地址仍然是任播地址，因此数据包永远不会到达后端，而只是反弹回负载平衡器并循环，直到 TTL 过期。

典型的负载均衡器通过修改目标 MAC 地址并转发来解决此问题，从而绕过 IP 路由。这仅当您的负载均衡器和后端都位于一个位置并且它们之间的网络完全切换且负载均衡器和后端之间没有任何路由器时才有效。

但是，还有一种不同的方法可以解决这个问题。数据包可以通过 IP 隧道从负载均衡器发送到后端。外部 IP 报头携带目标地址，该地址是指向后端的单播地址。内部 IP 报头未经修改，携带客户端 IP 作为源，携带任播 IP 作为目标。

在此设置中，外部标头的源 IP 几乎未使用。原则上，它应该是接收数据包的负载均衡器的单播地址。但是，某些服务（例如 Facebook）将内部标头中的客户端 IP 复制为外部标头上的源 IP。Facebook 的这个错误可以从外部检测到，因为有时隧道数据包会触发 ICMP 错误，该错误会直接发送回客户端。

内部和外部标头无需使用相同的 IP 版本。因此，负载均衡器和后端所需的单播地址都可以是 IPv6，这样负载均衡器和后端的数量就不受 IPv4 地址可用性的限制。

使用如上所示的设计还有一个额外的优势，即负载均衡器通常只需要此设置中的一小部分硬件，并且只需要通过任播地址访问负载均衡器。这意味着，如果您的任播地址由于搭载了主要为不同服务分配的任播前缀而需要在短时间内重新定位，那么问题就不那么大了。

陷阱

显然，上面概述的设置比简单地部署一堆独立的 Web 服务器要复杂得多。复杂的设置往往是导致不可用的原因。因此，必须对这种方案进行一些工作，使其足够强大，比替代方案更可靠。这意味着这更有可能是应该作为 CDN 服务的一部分进行部署，而不是为单个 Web 服务部署。

如果您尝试使用比上述设置更简单的任何方式执行任播 TCP，则很可能会遇到路由在连接中途发生变化的问题，结果用户将遇到重置。

任播可能对可用性、延迟和负载平衡有一定帮助。然而，它并不是灵丹妙药。任播确实会平衡负载，您可以通过添加更多节点来扩展负载。但不要指望任播所覆盖的节点之间的负载接近完美平衡。在上述具有分布式负载平衡层的设置中，负载平衡器本身可能无法获得均匀的负载，但它们可以将负载均匀地分布在后端之间。

不要依赖单个任播 IP 来实现可用性。如果您的某个节点发生故障，路由可能不会自动将其拾起。它不会影响所有客户端，但部分客户端可能会将其数据包路由到发生故障的节点。因此，对于这些客户端，您的任播 IP 地址已发生故障。如果您想要冗余，则需要多个任播 IP 地址。

只要路由在连接过程中不发生变化，延迟就没问题。但是，一旦 TCP 握手完成，您就必须在 TCP 连接期间使用特定的后端。数据包必须从客户端到负载均衡器，再到后端，再到客户端。这种三角路由可能会增加延迟。任播和能够选择最近的后端可以减少延迟，但往返中有三段而不是两段可能会增加延迟。只有收集大量现实世界的测量数据才能告诉您这两个因素中哪一个更重要。

Answer