什么是ddos攻击？node ssr服务如何防范和处理ddos攻击？下面本篇文章带大家了解一下ddos攻击，并介绍一下node ssr服务防范和处理ddos攻击的方法，希望对大家有所帮助！
防范和处理DDos攻击是稳定性建设中比较重要的一环，如果没有提前防范好，一但被攻击后，服务就会陷入不可用状态，可能会为业务带来很大的损失
此文会偏向node ssr服务视角，前端开发的同学要多重视这一块。【相关教程推荐：nodejs视频教程】
DDos攻击是什么？
举一个常见的例子，我们的网站，比作一家银行，正常情况下，银行最多可以同时处理100个人的业务，正常你直接走进银行，取个号，就能被服务了
突然有个流氓组织想收保护费，银行不肯给，于是流氓派出3000个人甚至3万个人同时去取号。过了号继续取号。结果就是导致服务器处理不过来，大量正常客户一直在等待
这就是 DDOS 攻击，它在短时间内发起大量请求，耗尽服务器的资源，无法响应正常的访问，造成网站实质下线。
DDOS 不是一种攻击，而是一大类攻击的总称。它有几十种类型，新的攻击方法还在不断发明出来。网站运行的各个环节，都可以是攻击目标。只要把一个环节攻破，使得整个流程跑不起来，就达到了瘫痪服务的目的。
其中，比较常见的一种攻击是 cc 攻击。CC攻击就是针对网页来攻击的，CC攻击本身是正常请求，网站动态页面的正常请求也会和数据库进行交互的，当这种"正常请求"达到一种程度的时候，服务器就会响应不过来，从而崩溃。baike.baidu.com/item/cc%E6%…
本文以下的内容都是针对 cc 攻击。
如何防范？
先了解一个请求打进来到我们服务之间的路径
业务服务集群作为服务链路的底层和核心资产，完备的上层防护是非常重要的
- 将恶意流量拦截在外层后，业务集群就不用频繁运维（扩缩容，限流等），降低运维成本
- 业务集群也无需额外准备过多的资源应该攻击流量，节约成本
- 具备很好的通用性，容易移植到其他服务，带来稳定性收益
防范的手段也按这个顺序介绍
接入CDN层
nginx限流
接入WAF防火墙
其他防护层
-
提高源站的处理能力。
针对SSR服务，有2个建议让ssr服务只处理根HTML的返回，其他的所有资源都要放到CDN上去
当攻击来临时，临时把SSR的降级到CSR
1. 接入CDN层
CDN层会在最外层，方便紧急时刻，开启CDN缓存，或开启CDN付费项目来保护内部其他服务的安全。举个例：
比如百万，千万级别或更大的瞬时流量打进来，有可能把负载均衡层给打挂了，这样会影响整个公司的业务，就不仅仅是被攻击的那个服务了
CDN的防护能力有：CDN缓存，Robot检测，ip信誉库，构建自定义防护规则集（结合历史的攻击特征和业务形态） 等 （按付费等级开启）
另外提一嘴（个人观点），CDN厂商在全球有数不清的服务器，大的CDN厂商几乎能低于一切攻击，而且还会按保护等级收费（保护费）。我个人觉得，一些攻击很可能就是CDN厂商勾结黑产做的，相当于流氓收保护费，不交保护费，就砸店（攻击），让你知道痛了，然后乖乖买CDN保护服务。而且能发动千万级别以上的QPS，除了CDN厂商（本身就有超多服务器），普通人应该很难
2. nginx限流
3. 接入WAF防火墙
这两个放在一块讲吧，也是偏向于运维层面，是公司级别的基建，具体的接入方式 和 具体配置 公司之间各有差异。也就不展开讲了
nginx限流是什么？
- 可以自行搜索
WAF防火墙是什么？
- 可以看这篇文章 www.huaweicloud.com/zhishi/waf0…
总结一下WAF层，会通过预置丰富的信誉库，对恶意扫描器、IP、网马等威胁进行检测和拦截
全面的攻击防护：支持SQL注入、XSS跨站脚本、文件包含、目录遍历、敏感文件访问、命令\代码注入、网页木马上传、第三方漏洞攻击等威胁检测和拦截。
人机识别
接口限速，WAF可以根据IP或cookie设置灵活的限速策略
-
基于丰富的字段和逻辑条件组合，精准控制
- 支持丰富的字段条件：基于IP、URL、Referer、User-Agent、Params等HTTP常见参数和字段的条件组合。
- 支持多种条件逻辑：支持包含、不包含、等于、不等于、前缀等于、前缀不等于等逻辑条件，设置阻断或放行策略。
4. 其他防护层
不同的公司，对应不同的业务及自身的特点，可能还会有其他的防护层，比如针对单实例还有过载保护（判断当前服务状况是否过载，然后根据流量的优先级会动态的丢弃掉一些低优先级的请求，尽可能保证服务的正常运转）
此处还有很多种防护层，有兴趣可以额外再去了解
5. 提高源站的处理能力
打铁还需自身硬 
这个很好理解，提高服务的处理能力，自然能承接更多的流量
针对SSR服务，有以下几个建议
建议一：让ssr服务只处理根HTML的返回，其他的所有资源都要放到CDN上去
对于ssr服务，这里给一个很重要的建议
让ssr服务只处理根HTML的返回，其他的所有资源都要放到CDN上去
这里直接以juejin举例子就很好理解了，我们可以从下图看到，juejin本身也是SSR服务，源站只处理了根HTML，其他所有资源（js，css，图片，字体等）都是放在CDN上的。 这样做的目的也是为了提高源站的处理能力，让CDN承担了很多压力
建议二：当攻击来临时，临时把SSR的降级到CSR
SSR渲染时，是比较耗费CPU计算的（需要编译和解析生成HTML），所以ssr服务的QPS能力都不高。面对攻击时很容易被打挂
解决办法：临时把SSR的降级到CSR
怎么做SSR的降级？
-
降级为CSR（客户端渲染），这样就不用再服务端生成复杂的HTML了，只需返回简单的HTML。
CSR 就是单页应用，举个最简的例子就是 ui组件库，下图也可以看到，这个HTML十分简单，是静态的，返回这个静态的HTML不用怎么消耗服务端资源
并且还可以将根HTML文件，缓存在内存中，这样可以让服务端的处理能力提升几十甚至上百倍
具体如何实现SSR降级，我会在后面的文章里写一下
6. 其他
例如可能还有弹性扩缩容能力，这个只能抵御小流量攻击
被攻击后如何紧急处理？
都已经被攻击，服务开始很缓慢了，甚至直接被打挂了，这时候做代码层的优化已经来不及了，只能做一些运维层的配置
我这边主要列以下3点，欢迎补充
扩容
升级防护策略
开启CDN缓存
1. 扩容
只能应对小流量的攻击
2. 升级防护策略
这个有点涉及商业秘密... 不太敢写，有兴趣的朋友可以自行搜索，或问一下公司运维
反正有一点，是我猜的。一般乖乖给CDN交钱后，后面可能就没攻击进来了，即使有，也可能只是些小流量，且好防护的攻击
3. 开启CDN缓存
ssr服务，如果平常访问的时候，没有开启CDN缓存的话，被攻击时，可以临时打开CDN缓存。
总结
防范措施要越早做越好，别被攻击后，才开始做，因为可能已经造成很多损失了
只有前面的该做的做了，该接的接了，等到真正被攻击的时候，才有操作配置的空间，否则只能向上帝祈祷攻击快点停止... 或者只能被动接受敲诈勒索
安全无小事，愿世界和平
更多node相关知识，请访问：nodejs 教程！
