我想为我的网络服务进行任播，但我找不到任何关于如何实现这一目标的信息或任何可以提供帮助的公司。
我发现有很多公司提供任播 DNS，但这不是我需要的。
我有一个无状态的 Web 服务，我想在地理上分发它，使用任播来平衡负载并增加正常运行时间。公司是否有任何技术原因不能只为我在多个数据中心宣传 IP 地址？
为了评估现有产品并帮助我找到可以帮助我的公司，我需要了解有关任播的哪些技术方面的知识？我需要注意哪些陷阱？
kas*_*erd 15
为了满足您的特定请求，需要了解任播的两个不同方面。第一部分是如何通告和路由任播地址。第二个是 TCP 中对任播地址的挑战，以及如何解决这些挑战。
发布和路由
为了使 BGP 表保持可接受的大小，如果前缀太长，大多数 AS 将过滤传入的公告。对于 IPv4，阈值往往是 /24 前缀，这意味着 256 个地址。这意味着为了在公共互联网上进行任播，您至少需要 256 个地址。
如果您已经拥有自己的 /24 前缀，那么托管服务提供商代表您宣布它并没有什么阻止。如果是这种情况，任播对您来说就像找到一堆愿意以合适的价格提供此服务的不同托管服务提供商一样简单。然后，您只需让他们所有人代表您宣布前缀。
您可以查看有关广告路线的公开可用信息，以查找已经代表其客户宣布前缀的提供商，以便将您引导至可能提供此类服务的提供商。在路由表中查找的一种工具是bgp.he.net。
如果您没有自己的前缀并希望从提供商那里获得前缀，那么了解上述限制对该提供商意味着什么很重要。
提供商拥有足够的 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，您很可能会遇到路由在连接中途更改的问题，结果用户将遇到重置。
Anycast 可能对可用性、延迟和负载平衡有一些好处。然而，它不是灵丹妙药。Anycast 确实平衡了负载，您可以通过添加更多节点来扩展负载。但是不要指望任播到达的节点之间的负载接近完美平衡。在上面描述的带有分布式负载平衡层的设置中，负载平衡器本身可能无法获得均匀的负载，但它们可以在后端之间均匀地分配负载。
不要依赖单个任播 IP 来保证可用性。如果您的节点之一出现故障，路由可能不会自动恢复。它不会影响所有客户端，但一部分客户端可能会将其数据包路由到已关闭的节点。因此，对于这些客户端，您的任播 IP 地址已关闭。如果您想要冗余，则需要多个任播 IP 地址。
只要路由在连接过程中不发生变化，延迟就可以很好。但是一旦 TCP 握手完成，您就承诺在 TCP 连接期间使用特定的后端。数据包必须从客户端到负载均衡器再到后端和客户端。这种三角形路由会增加延迟。任播减少了延迟，并且能够选择最近的后端，但是在往返中使用三个而不是两个会增加延迟。只有收集大量真实世界的测量结果才能告诉您这两个因素中哪一个更重要。