前端原发性 DDoS

来源

内容来源于公司内部技术分享< 前端原发性DDos防御与应对方案 >

DDos

要知道DDos是什么？首先得了解Dos，拒绝服务攻击（ denial-of-service attack ）亦称洪水攻击，是一种网络攻击手法，其目的在于使目标计算机的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。那么什么又是DDos呢？当黑客使用网络上两个或以上被攻陷的计算机作为“僵尸”向特定的目标发动“拒绝服务”式攻击时，称为分布式拒绝服务攻击（ distributed denial-of-service attack ）

前端原发性

那什么又是前端原发性DDos呢？ 由前端逻辑漏洞产生的DDos。现在服务基本都是基于C/S，简单的逻辑一般通过客户端调用服务端接口，也可以将数据通过消息系统推到客户端即可满足。但是有些需求，为了更好的用户体验，实时性，在实现上有推拉结合，错误重试等方式。在复杂的实现下，往往会引发漏洞。再者客户端与服务端数据同步必须有一次交互，网站流量比较大时，自己的客户端便成了“僵尸”，疯狂攻击自家服务器。

典型场景

长链接消息触发并发请求

接口请求失败，触发重试的并发请求

所有秒杀型，发生大量并发的应用场景

DDos导致结果

1. 服务器

CPU 负载高

资源无法释放，如 TCP 连接数

进程堆积，如 PHP，

资源耗尽

可能引起雪崩：大流量下，若一个内部服务出现性能瓶颈，直接会导致上游服务阻塞，短时间内故障扩散

2. 客户端

刚开始是一部分用户能打开，一部分打不开。随着时间越长，越来越多用户打不开，最后所有服务都不可用。

请求 pending ，响应极慢，等待时间长

最后页面完全打不开或接口不通

遇到的事故

事故1: 某次活动中，客户端收到长链会回调服务端接口，结果消息触发次数多，再加上直播间用户量比较大，形成一个n*m量级访问，单位时间内有8kw请求，最后异常流量原来来自自己。

事故2: 之前开发的一个功能，客户端收到长链消息会自动下载应用包。游戏首发日运营同事为了效果，加快长链消息下发速度，导致机房短时间流量跑满。

防御与应对方案

1. 前端防御

• 没有并发就是限制并发最好的方法

• 避免失败重试，设置重试上限，松散重试

• 优化业务逻辑，可以将部分计算放到客户端，减少客户端请求接口的次数

• 静态缓存， CDN 、 CMS

• 长链下发数据，前提要符合长链的技术应用标准

• 松散请求，均匀分布在 0~15s 之内处理完。15s是一个经验值，考虑到实时性这个可以动态调整，比如在直播间可以根据直播间人数，还有服务可承受的qps来计算。

• 如果 15s 还处理不完，应该优化接口性能或扩容。比如收到长链之后发请求，要充分评估服务的承载能力

• 轮询不是恶魔，合理使用轮询替代长链请求，能获得更好的性能

2. 接入层防御

• 重大活动，流量预估，提前扩容

• 请求频率限制， nginx limit

• 设置后端服务接口超时，一般是 1~2 秒

• 使用高性能代理， nginx 、 lua

• 避免代理 80 端口的应用

• 增加缓存， fastcgi-cache 、 varnish

• 小心缓存穿透

• 避免接口臃肿，一个接口请求多个后端服务

• 接口臃肿的坏处：容易引起雪崩效应

• 按需调用资源，最小权限原则

3. 架构层防御

• 流量控制、熔断机制

• 快速扩容，自动扩容

原则

追求经济性，设计合理。提前预防，从容应对。

总结

前端原生性DDos是在完成业务功能中常常被忽略的问题，危害又很严重。是客户端，服务端两方面的问题，但是等到客户端发版了，那就只能靠服务器端扩容(web页面的话可以直接上线)。因为可能大量的逻辑在客户端。所以在业务遇到类似情况时，首先，必须意识到潜在隐患。再者，就是一起优化技术实现逻辑。最后再考虑机器扩容。