我如何获得我的服务器选播？

有关选播的两个独立方面需要理解，以满足您的特定要求。 第一部分是选播地址是如何通告和路由的。 第二个是TCP对于任播地址的挑战，以及如何解决这个问题。

宣布和路由

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

如果您已经有了自己的/ 24前缀，那么停止托pipe服务提供商以您的名义宣布它是不会有太多的事情发生的。 如果是这样的话，那么选播就像寻找一群愿意以合适的价格提供这项服务的不同托pipe服务提供商一样简单。 那么你只是让他们都代表你公布前缀。

您可以查看公开提供的有关广告路线的信息，以查找已经为其客户宣布前缀的提供商，以便指导您提供可能提供此类服务的提供商。 在路由表中查找这个工具是bgp.he.net 。

如果您没有自己的前缀，并且需要提供者的前缀，那么了解上面提到的限制对提供者意味着什么是很重要的。

该提供商具有足够的IP地址，可以configuration任播前缀。 然而，一旦他们这样做，他们承诺使用全部256地址作为任播。 而且所有的256个地址都必须在同一组地点进行托pipe。

由于这个原因，你有时会看到分配了256个地址，以便仅仅使用其中的一个地址进行anycasted服务。 这可能是你的第一个机会。 一个已经提供任意前缀的提供者实际上可能有250个未使用的任播地址。 如果你的服务对于提供商来说足够“有趣”，他们可能愿意租用你在其中一个地址上的主机。 一个重要的警告是，你将不得不作为主要的选播服务在同一地点举行。 如果他们认为合适的话，他们可能需要安排他们的服务，因为这是他们主要的任何服务，决定哪里需要托pipe。

上面的大部分假定提供者托pipe服务的地方与他们宣布前缀的位置之间的大致1：1对应关系。

如果托pipe服务提供商拥有自己的冗余骨干网和他们自己的数据中心，那么他们可以在他们托pipe的位置的不同位置公布一个前缀。 而且在内部，他们可以路由更长的前缀作为单播或任播。

例如，如果供应商在四种不同的持久性有机污染物中宣布一个/ 22，并且它们之间有一个冗余的networking（例如四环链接），他们可以在内部路由一个/ 24或/ 25到每个持久性有机污染物， / 28被发送给所有POP（这实际上意味着通过POP首先进入其networking的POP服务）。

如果你能find一个既有冗余骨干网也有数据中心的提供商，那么这样一个提供商就可以更方便地为你的服务select一个自己的IP地址。 但请记住，在这样做时，您的服务会在每个骨干路由器中使用一个CAM表项。 而你必须为此付费。

TCP和任播

正如一些评论指出的那样，TCP是一种有状态的协议。 所以即使你认为你的Web服务是无状态的，它仍然在TCP层有状态。 这样做的结果是天真地选播基于TCP的服务将会是用户将经历非常频繁的连接重置。

这个问题可以通过在实际的Web服务器前面添加另一个层来解决。 所需要的是一层节点，它可以将接收到的TCP数据包转发到适当的Web服务器，并在连接中一致地执行。 到目前为止，这很像一个标准的基于DSR的负载平衡器。

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

此外，来自负载平衡层的数据包需要不经修改地转发到后端。 基于原始数据包的目的地IP的IP路由将不能解决这个问题，因为目的地址仍然是任何地址，所以数据包将永远不会到达后端，而是简单地反弹回负载均衡器，直到TTL已过期。

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

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

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

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

使用上面描述的devise具有额外的优点，即负载平衡器通常只需要这个设置中的一小部分硬件，并且只有通过任播地址才能到达的负载平衡器。 这意味着，如果您的任播地址需要重新定位，并且由于主要为不同的服务分配的任播前缀上的捎带而发出短时间警告，那么这个问题就不会那么严重了。

陷阱

显然，上面简单介绍的设置比简单地部署一大堆独立的Web服务器要复杂得多。 复杂的设置往往是不可用的来源。 所以，一定数量的工作将不得不放在这样一个scheme中，使其足够强大，比替代scheme更可靠。 这意味着这更可能是应该作为CDN服务的一部分进行部署，而不是为单个Web服务部署的东西。

如果您尝试使用任何比上述设置更简单的方法进行任意TCP，您可能会遇到路由发生中断连接的问题，因此用户将遇到重置问题。

任播可能对可用性，延迟和负载平衡有所帮助。 然而这不是银弹。 任播能够平衡负载，并且可以通过添加更多节点来加载负载。 但是不要指望anycast接近达到完全平衡的负载。 在上述使用分布式负载平衡层的设置中，负载平衡器本身可能无法获得均匀负载，但是它们可以在后端均匀分配负载。

不要依赖单个任播IP来提供可用性。 如果其中一个节点出现故障，则路由可能不会自动启动。 它不会影响所有客户端，但客户端的一个子集可能会将其数据包路由到某个已closures的节点。 因此，对于这些客户端，您的任播IP地址已closures。 如果你想要冗余，你需要多个任播IP地址。

只要路由在连接中间不变，延迟就可以很好。 但是，只要TCP握手完成，您就承诺在TCP连接期间使用特定的后端。 数据包必须从客户端到负载均衡器到后端和客户端。 这个三angular路由可以增加延迟。 从任意播可以减less延迟，并且能够select最接近的后端，但是在双向传输中有三条腿而不是两条腿会增加延迟。 只有收集大量现实世界的测量数据，才能了解到这两个因素中的哪一个更重要。

这个现实的文章可能也有助于https://engineering.linkedin.com/network-performance/tcp-over-ip-anycast-pipe-dream-or-reality

linkedin使用真实用户监控来评估全球选播是否比区域选播有更好的performance。 最后，他们意识到并实际上实施了不同的任播地址用于不同地区的区域任播。 他们正在使用基于DNS的负载均衡和基于区域任播的混合。

上面提到的解决scheme是一个很好的解决scheme，因为它提供了位置和服务器身份之间的分离，但是基于隧道。 我相信更好的方法是使用相同的分离方法而不需要隧道，但是这次的实现非常有限。 正在积极的研究，虽然通过ILNP（标识定位器networking协议）的stream量工程提供了这些纠缠的问题的答案。 干杯

您需要为可以为您执行任播的networking提供商着色物理networking服务器硬件。

如果你走这条路线，你可能还需要build立一个通往pipe理（隧道等）卡的隧道，所以你不需要在现场访问它们。

我们为我们的网站做这个。