DDOS 是目前安全领域最难解决的问题，中文叫分布式拒绝服务，这里用几个亲身经验来体会一下攻击的影响。

案例一：
2017「双十一」，某商家使用了第三方积分系统，「双十一」当天商家进行大促并且使用积分系统开展兑换，全路径为：用户进入天猫店铺 -> 点击 banner 积分商城 -> 填写个人信息 -> 积分兑换。由于瞬间大量用户进入，并且有用户发现第三方系统漏洞，直接导致天猫店铺积分商城 banner 点击白屏。

案例二：
自己开发过一个投票系统，投票接口没有做任何限制，只是「完成」投票需求。在活动结束之前最后几个小时，有用户开始利用机器刷票，直接导致 6 台服务器CPU直接飙升 100%，服务接近不可用。

以上场景归纳一下，DDOS 其实就是利用合理的资源，导致资源过载，最后服务不可用的情况。DDOS 可以根据产生在网络结构的不同层级分为网络层 DDOS 和应用层 DDOS。网络层 DDOS 其中一种是利用 TCP 三次握手原理，造成服务的不可用。



上图是 TCP 三次握手协议，其中如果客户端是伪造的 ip 地址，那么服务器收到客户端的 SYN 包之后要向客户端发送第二次「握手」，但是客户端是伪造的 ip，所以第三次「握手」永远不会成功，服务器还会重试 3 – 5 次每次等待 30 s- 2 min，一旦伪造 ip 的客户端多了，就会耗尽服务器的 CPU 资源，导致服务不可用。

之前的两个案例都可以理解成应用层的 DDOS，虽然 DDOS 可能是一种恶意攻击，但是如果应用功能设计的缺陷，正常大流量进来对服务来说，也是一种攻击，会导致服务不可用。

举个例子就是天猫商家的第三方积分系统，首先「黑帽子」有很明确的目的性、突然的流量可能会导致系统的不可用，针对突然的流量第一秒想到的可能是限流,可以根据用户的 ip、ua 等同人识别，但是针对 DDOS 的攻击或者以上的场景，用户可以伪造 ip、ua 进行访问。

token 和验证码的出现似乎给了一定的缓解，但是 token 设计的合理性会很大程度的影响到防御效果。其实真正意义上面的防御，是要让服务不被恶意攻击，而不是要被所谓自己设计的复杂 token 逻辑反坑自己的系统。

对于验证码来说，很大程度影响到了用户的体验，如果一个产品能潜移默化的改变用户习惯，那他是成功的。但是验证码很明显会让用户感到不适，当然针对这一个缺陷，人工智能领域可能会得到突破，比如腾讯的一款安全产品，它能够检测到用户当前的环境来判断是否需要弹出验证码。验证码不仅会影响到用户体验，「黑帽子」还能够使用彩虹表进行遍历。



淘宝秒杀的答题系统，就有一个「字典库」，所以还是有一定的风险的。我们可以看到淘宝秒杀的答题，它不仅是识别图片里面的文字，他是一种需要人进行大脑思考，做出判断的。



市场上的验证码还有像淘宝账户在非经常登陆环境，并且有风险时候，会让你识别你购买过的商品。其实，针对验证码这种防御方式也不要放弃，还是有解决办法的。

针对 DDOS 攻击，我们能做什么

第一进行限流，之前说限流有一定的局限性。 Yahoo 申请的一个专利里面，由于应用层的 DDOS 攻击都是真实的 ip，所以可以根据「黑帽子」的 ip、cookie 等信息来计算客户端的请求频率。

其次，我们在框架选型的时候，要单独对 DDOS 等攻击手段进行考虑。

最后，我们在业务开发的时候，在业务逻辑不出问题、技术方案和设计无缺陷下，一定要有安全防范的意识。