技术开发 频道

开发者,不要再沉迷于自我DDoS攻击了!

  【IT168 评论】软件工程师可以通过适当的容量规划和应用程序架构,避免遭遇分布式拒绝服务DDoS(Distributed Denial of Service)攻击。DDoS攻击主要指借助客户端/服务器技术,将多个计算机联合起来作为攻击平台,对一个或多个目标发动DDoS攻击,从而成倍地提高拒绝服务攻击的威力。

开发者,不要自我进行DDoS攻击了!

  每当我们讨论分布式拒绝服务攻击时,我们通常专注于物联网、僵尸网络和向网络和应用发送大量垃圾流量的黑客攻击。DDoS攻击通过大量的合法请求占用大量网络资源,以达到瘫痪网络的目的。然而,对于许多组织而言,自我影响的DDoS攻击更危险。

  糟糕的软件架构决策是应用程序宕机的最常见原因,Google客户可靠性工程总监Dave Rensin和网站可靠性工程师Adrian Hilton在Google云平台的博客上写道。错误往往不在代码中,而是在开发人员关于应用程序和用户交互的假设,特别是当它们与系统负载相关时。

  “我们认为是时候提醒广大开发者,应用程序的最大威胁往往不是来自第三方,而是来自你自己的代码!”Rensin和Hilton写道。

  软件开发人员通常假定负载平均分配给所有用户,这不是一个坏的假设,但如果开发人员没有应急计划来处理负载不均匀分布的情况,“事情就会开始走下坡路了,”工程师说。

  例如,一个移动应用开发人员编写代码,让程序每15分钟自动从后端服务器获取数据,但他可能没有想到,如果应用程序遇到错误,也可以每隔60秒重试一次该逻辑。从表面上看,这很合理,实际上也是一个常见的模式。许多开发人员没有考虑或计划,如果后端事件有一分钟不可用,会发生什么。

  在这一分钟内,有应用程序试图获取数据并且遇到了错误。当后端服务器再次在线显示时,通常会遇到在该时刻预计出现的数据请求和来自一分钟延迟后重试的应用程序流量。这是预期流量的两倍,并且负载不再均匀分布,因为“两个十五分之一的用户被锁定在同一个同步时间表”。

  对于给定的15分钟,服务器将经历13分钟的正常负载,一分钟的无负载和一分钟的双负载。

  服务中断的持续时间通常超过一分钟。为了正确处理15分钟的服务中断,软件工程师至少需要提供15倍的正常容量,以防止应用程序服务器恢复在线时崩溃。如果后端服务器对每个请求的响应变慢,由于负载平衡器上的负载增加,在此期间请求的总数可能超过正常流量的20倍。

  增加的负载可能会导致服务器耗尽内存和其他资源,并再次崩溃。

  避免自我DDoS攻击的技巧

  应用程序开发人员可以采用三种方法避免由于自身原因造成的DDoS攻击:指数回退,添加抖动和标记重试请求。这些方法可以有效减轻一分钟延迟带来的后果。

  指数回退是指增加延迟,每次失败的重试时间都加倍,以在失败的连接尝试之间建立更长的时间间隔。使用固定的重试间隔几乎可以确定重试请求将在负载均衡器上堆叠。在上述示例的情况下,第一个一分钟重试后,应用程序将等待两分钟,四分钟,八分钟和16分钟,然后返回到一分钟。指数回退将排队的整个请求数从15个降低到5个。

  抖动,将随机时间段添加或减少到下一个重试间隔以改变下一次尝试的时间,有助于防止应用程序被锁定到同一个同步周期。在该示例中,如果下一个回退时间间隔设置为四分钟,则添加抖动可能会导致应用程序在2.8分钟到5.2分钟之间的某个时间发送新的重试尝试,而不是等待四分钟。

  通常的模式是选择一个+/-固定百分比(例如30%)之间的随机数,并将其添加到下一个重试间隔。

  在现实世界,程序几乎从未均匀分布。几乎所有的系统都经历了与用户工作和睡眠模式相对应的峰值和谷值。用户可能在晚上关闭设备,流量会大幅降低,但也将导致用户醒来时的交通峰值。

  为此,除了重试之外,添加一点抖动(也许10%)到常规同步间隔也是一个好主意,这将对重启后的第一次同步有很大作用。

  最后,每次尝试都应该标记一个重试计数器,以便应用程序可以优先处理客户端连接。在服务中断的情况下,服务器不是全部同时返回在线,并且也会受到应用总容量的限制。可以集中于优先响应具有较高重试次数的请求,因为这些客户端已经等待很长时间了。

  值为零表示请求常规同步,值为1表示第一次重试,以此类推。

  导致系统中断和服务中断的原因有很多。假设在30天内,系统持续保持99.9%可用性的时间可能无法达到43.2分钟,因此15分钟的中断完全在可能的范围内。应用程序如何从这些事件中恢复,就取决于它处理这些突发流量的方式。

1
相关文章