服务器 Gind.cn
  1. 服务器 Gind.cn
  3. 选播是否允许尝试替代路线？
Intereting Posts
改变去往源主机的第二networking别名的去往的stream量的源地址 Apache – 如何findSSLMutex的价值 mysql批量插入数据 数据库触发器是否对整体数据库function有性能影响？ 在Linuxnetworking中设置IP地址 通过openvpn（UDP）的NFS4（TCP） – mount可以被浏览，但是D / L会杀死它 反向查找不与我自己的域名服务器的任何互联网地址 将Windows XP计算机上的时钟同步到外部（非域，非工作组）Windows Server 2008 R2计算机 面向公众的Active Directory有哪些问题和缺陷？ CLOSE_WAIT保持进程在Windows上活着 大型驱动器的重新分区工具 私人MSMQ队列可以重命名吗？ 有主机故障切换页面的免费服务吗？ 远程桌面scheme – Server 2012 R2 Hyper-V RDS / VDI或带有Win7 guest虚拟机的VMware ESXi？ 我如何在端口80上安装并运行Tomcat作为我唯一的Web服务器？ （扎根Ubuntu框）

选播是否允许尝试替代路线？

有一点让人难以置信的标题，但我不知道这个问题是否足以提出一个更合适的标题。

我已经一次又一次地读到，Anycast是一个很好的负载均衡解决scheme，并且是DNS负载均衡的首选解决scheme。 但是，我想知道，选播只是似乎有一个负载平衡的优势，并没有提供冗余的帮助。 而没有负载平衡（即只有多个Alogging）的普通DNS解决scheme不提供任何负载平衡，但似乎提供更好的冗余。

我一直在仔细研究DNS服务，并注意到在2016年，Dyn遇到了停机问题： https ： //en.wikipedia.org/wiki/2016_Dyn_cyberattack 。 但是有两件事情：

1）如果特定的任播广播后面的服务器出现问题，是否会自动尝试其他路由？ 如果是这样，为什么Dyn遭受这样的中断 – 或者这是由于在UDP上运行的DNS？

例如，如果我们试图连接到一个蓝色节点，并按照1-2-6的路线，并发现路由6中断（无法连接到服务器或一些错误），将路由1-2-5或1- 3-4自动尝试？

在这里输入图像说明

2）客户可以做些什么来缓解这个问题？

3）在我看来，选播更有可能牺牲一个特定的地区来保持其他地区的在线，而不是更多的DNS轮stream事件，不会提供相同的性能，但会提供更好的缓冲这种攻击。 那么，为什么它（假设我的想法是正确的）似乎有一个大的推动任播，而不是推动更多的循环赛DNS服务，将返回服务器的顺序相关的用户。

我知道这个问题多个数据中心和HTTPstream量：DNS循环是确保即时故障转移的唯一方法？ 虽然我不认为这是重复的，因为我感兴趣的原因为什么选播可以失败，因为它的确如此。

因此，首先让我们简单回顾一下使用Anycast进行DNS的暗示：

  1. 给定的IP地址a是我们希望提供更多可用的parsing器。 主机是A / 24子网的成员。 任播可以通过特定的主机路由（即/ 32）完成，但通常只能在私有networking中看到，而不能在普通的互联网上看到。

  2. 有一些机制可以使A子网只在相应的DNS服务运行时dynamic地通告。 请注意（这真的很重要）广告本身可能来自运行parsing器的站点内的单个主机，从包含所述parsing器的多个实例的整个物理站点（即，运行parsing器的许多主机，作为整个共享一条路线）。

  3. 同一条路线（ A ）将在公共互联网上从多个点进行广告。 这可能采取大型提供商（阅读：分散在全球各地的点数）的forms，在与外部networking互连的每个点呈现相同的路线，或者来自多个运营商内托pipe点的相同路线。

所以 – 当一个任意的客户端向anycast IP发送数据包时，所述数据包将倾向于发现自己到达“最接近”的广告点。 我把吓人的引号放在最近的地方，因为从路由拓扑结构的布局以及路由器的路由策略来看，这只是一个接近的事情。 最接近的任播地址实际上可能实际上是最远的。

如果反过来，这条路由的发布点失败（可能是由于主机上的服务失败，路由收缩或更传统的networking可达性问题），那么绑定到任播地址的数据包将是路由到路由的下一个最近的（再次 – 在路由协议术语中）实例。 在networking重新聚合过程中，客户端的parsing可能会失败并被重新尝试，现在重新尝试重新尝试更长的path，以达到显然是相同的地址。 这对于客户端进程和用户来说都是透明的，并且从networkingangular度来看，最好将其视为一个给定networking的替代path。

将任播networking看作一个逻辑结构是有帮助的。 这是一个包含您感兴趣的服务的虚拟子网。该虚拟子网可通过networking中的许多path到达。

这就是说，这里是选播devise的主要注意事项：

  1. 由于不能保证给定任何IP的分组将到达相同的物理主机，所以这种方法实际上只映射到无连接的协议。

  2. 解决scheme的可靠性只与将服务的正确运行与路线广告相结合的逻辑一样好。 如果服务死亡，路线继续被宣传，那么将会有潜在的重大黑洞。

  3. 通过公共互联网获得选播路线广告并不是微不足道的。 创build热点非常容易：一个选播路线的特定实例比大多数客户更可取。 这仍然是一个潜在的体面的高可用性解决scheme（对于更容易的故障types），但它不说负载平衡。

现在 – 最后 – 所有这些都已经列出来了，你的问题更容易回答：

Anycast没有任何内在的东西可以使其更能抵御DDoS。 DDoSstream​​量的潜在数百万stream量中的每一个都将find到最近的实例的path，可能使其不能被其他路由到这些点的任何其他合法客户端访问。

现在，如果使用的僵尸networking中的绝大多数主机恰好位于东欧，而且其中一条任播路线恰好发生在附近的一个PoP（就路由拓扑而言又是“附近”），那么这个交通将沉没到一个点，而世界其他地方的许多人继续解决到同样的路线，这也是在其他大陆的方便点。 在这种特殊情况下，选播可以说是减lessDDoS攻击的最佳机制之一。 这在很大程度上取决于如何分配任播路线以及如何configuration策略（见上面＃3 – 不是一个小问题）。

显然这种用例在真正分布式的DDoS攻击的情况下并不那么令人信服。 然而，如果devise得当，任播路线的本地化意味着攻击负荷现在可以分散在任意数量的地理上分散的物理主机上。 这往往会淡化攻击对目标的影响，并可能将影响传播到更大的networking中。 再次 – 数量巨大取决于如何devise和configuration。

为什么这被认为是循环赛的胜利？ 简单地说，因为可以部署任意数量的主机，而不需要各个IP上的单独负载均衡器，并且也不会依赖于特定客户端的超时值，因此决定转移到另一个parsing器。 人们可以在一个具有相同IP的单一数据中心内真正地部署千台主机，并相应地平衡stream量（基于ECMP表的大小显然是巨大的实际限制等），或者部署千个不同地点的千位主机。 所有这些都可以在不改变客户端configuration的情况下完成，没有负载均衡器的（通常是集群式的）失败点等等。简而言之 – 当正确devise时，它可以像整个Internet一样扩展。