如何防御DDOS？网站平时应该怎么做？

只有了解了ddos原理 才能进行更好的防御  如果楼主比较小白 最好还是用百度云加速这类的cdn防御

参考：带你全面了解ddos攻击原理

DDos 攻击自打出现以后，就成为最难防御的攻击方式。仅仅在过去的一年里，DDoS 的数次爆发就让人大开眼界：

2016年4月，黑客组织对暴雪娱乐发动了 DDoS 攻击，魔兽世界、守望先锋多款游戏出现宕机的情况。 2016年5月，黑客组织针对全球银行机构发动 DDoS 攻击，导致约旦、韩国、摩纳哥等国的央行系统陷入瘫痪。 2016年9月，法国主机商 OVH 受到 DDoS 攻击，峰值达到1Tbps 2016年10月，DynDNS 受到 DDoS 攻击，北美众多网站无法访问，受影响的网站均排前列。

在你不经意之间，DDoS 可能已经在互联网上横行无忌了。

在谈攻防史之前，我们先来看看 DDoS 的攻击原理，知己知彼，百战不殆。

什么是 DDos 攻击？

DDoS 攻击是分布式拒绝服务攻击（Distributed Denial of Service）的缩写，核心是拒绝服务攻击，通过使目标电脑的网络或系统资源耗尽，使服务暂时中断或停止，导致其正常用户无法访问。而攻击的形式，又分为带宽消耗型和资源消耗型。带宽消耗型通过 UDP 洪水攻击、ICMP 洪水攻击以及其他攻击类型；资源消耗型包含 CC攻击、SYN 洪水攻击、僵尸网络攻击等。不同的攻击类型，我们的应对措施有所不同。不过在我们的日常工作中，我们所使用的 DDoS 攻击普遍是带宽消耗型攻击，也就是说，黑客会针对你的服务器发送海量 UDP 包、SYN 包，让你的服务器的带宽被攻击流量占满，无法对外提供服务。举个例子：用户通过网络来访问你的服务器就如同客人过桥来找你，但是由于你的钱只够建立一个双向四车道的桥，但是攻击者派了 100 辆大卡车，堵在你的桥门口，导致没有正常客人能够过桥来找你。

在这种情况下，你如果想要让你的客人能够继续访问，那就需要升级你的大桥，来让有空余的车道给你的客人来通过。但是，在中国的带宽由三大运营商移动联通电信提供接入，互联网带宽的成本是非常高的，而攻击者使用肉鸡攻击，攻击的成本要低很多，所以我们无法去无限制的升级我们的带宽。

在互联网的初期，人们如何抵抗 DDoS 攻击？

DDoS 并不是现在才出现的，在过去，黑洞没有出现的时候，人们如何抵抗 DDoS 攻击呢？ 在互联网初期，IDC 并没有提供防护的能力，也没有黑洞，所以攻击流量对服务器和交换机造成很大的压力，导致网内拥塞，回环，甚至是服务器无法正常工作，很多IDC往往采用拔网线之类简单粗暴的办法来应对。后来，一些 IDC 在入口加入了清洗的程序，能够对攻击流量进行简单的过滤，这样就大大的减轻了服务器和内网交换机的压力。但是机房的承载能力也是有上限的，如果攻击总量超出了机房的承载能力，那么会导致整个机房的入口被堵死，结果就是机房的所有服务器都因为网络堵塞而无法对外提供服务。

后来，黑洞出现了，但是那时候的黑洞也是在机房的入口配置，只是减轻了服务器的压力，如果攻击的总量超出了机房的承载能力，最终还是因入口被堵塞而导致整个机房的服务器无法对外提供服务。在这种情况下，宣告了攻击者的得手，没有必要再尽心攻击，但是如果攻击者并没有因为目标无法访问而停手，那么机房入口仍有拥塞的风险。

后来，黑洞进一步升级，在机房黑洞之上采用了运营商联动黑洞。在遇到大流量攻击时，DDoS防御系统调用运营商黑洞，在运营商侧丢弃流量，可以大大缓解DDoS攻击对机房带宽的压力。

云计算平台也广泛采用了此类黑洞技术隔离被攻击用户，保证机房和未受攻击用户不受DDoS攻击影响。 不仅如此，云计算平台的优势在于提供了灵活可扩展的计算资源和网络资源，通过整合这些资源，用户可以有效缓解DDoS带来的影响。

黑洞是如何抵挡 DDoS 攻击的

目前最常用的黑洞防御手段的流程图如上图所示。攻击时，黑客会从全球汇集攻击流量，攻击流量汇集进入运营商的骨干网络，再由骨干网络进入下一级运营商，通过运营商的线路进入云计算机房，直到抵达云主机。 而我们的防御策略刚好是逆向的，云服务商与运营商签订协议，运营商支持云服务厂商发布的黑洞路由，并将黑洞路由扩散到全网，就近丢弃指定IP的流量。当云服务商监测到被攻击，且超出了免费防御的限度后，为了防止攻击流量到达机房的阈值，云计算系统会向上级运营商发送特殊的路由，丢弃这个 IP 的流量，使得流量被就近丢弃在运营商的黑洞中。

为什么托管服务商不会替你无限制承担攻击？

一般来说，服务商会帮你承担少量的攻击，因为很多时候可能是探测流量等，并非真实的攻击，如果每次都丢入黑洞，用户体验极差。 DDoS攻击是我们共同的敌人，大多数云计算平台已经尽力为客户免费防御了大多数的DDoS，也和客户共同承担DDoS的风险。当你受到了大规模 DDoS 攻击后，你不是唯一一个受害者，整个机房、集群都会受到严重的影响，所有的服务的稳定性都无法保障。 除此之外，在上面我们说到，目前 DDoS 都是带宽消耗型攻击，带宽消耗攻击型想要解决就需要提升带宽，但是，机房本身最大的成本便是带宽费用。而带宽是机房向电信、联通、移动等通信运营商购买的，运营商的计费是按照带宽进行计费的，而运营商在计费时，是不会将 DDoS 的攻击流量清洗掉的，而是也算入计费中，就导致机房需要承担高昂的费用。如果你不承担相应的费用，机房的无奈之下的选择自然便是将你的服务器丢入黑洞。

当你的主机被攻击后，服务商如何处理？

目前随着大家都在普遍的上云，我们在这里整理了市场上的几家云计算服务提供商的黑洞策略，来供你选择。

AWS

AWS 的 AWS Sheild 服务为用户提供了 DDoS 防御服务。该服务分为免费的标准版和收费的高级班，免费的标准版不承诺防护效果，存在屏蔽公网 IP 的可能。付费版只需要每月交 3000 美元，则可以享受防护服务。

Azure

Azure 为用户提供了免费的抗 DDoS 攻击的服务，但是不承诺防护的效果。如果攻击的强度过大，影响到了云平台本身，则存在屏蔽公网 IP 的可能。

阿里云

阿里云的云盾服务为用户提供 DDoS 攻击的防护能力，在控制成本的情况下，会为用户免费抵御 DDoS 攻击，当攻击超出阈值后，阿里云就会对被攻击 IP 实行屏蔽操作。 阿里云免费为用户提供最高 5Gbps 的恶意流量的攻击防护，你可以在各个产品（ECS、SLB、EIP等）的产品售卖页面看到相关的说明和条款。在其帮助文档也说明了相关的服务的限制。

腾讯云

腾讯云也为用户提供了免费的 DDoS 攻击防护服务，其免费提供的防御服务的标准如下：外网 IP 被攻击峰值超过 2Gbps 会执行 IP 封堵操作（丢入黑洞），一般黑洞的时长为2小时，大流量攻击时，封堵的时长从24小时到72小时不等。

普通 IDC

普通的 IDC 大多不提供防御能力，如果受到攻击，会存在被拔网线的可能。

如何合理的借助云计算的能力来抵抗 DDoS 攻击

合理的借助云计算的能力，可以让我们尽可能的减少被攻击时的损失： 1，充分利用云平台的弹性可扩展资源。设计可以横向扩展的系统架构，避免IP资源或者CPU资源耗尽，不仅可以有效缓解DDoS攻击的影响，而且可以提升系统可靠性。 2，缩小攻击半径。在设计系统时分离应用层和数据层，分离网络访问层和系统服务层，充分利用云服务提供商提供的云数据库、云存储、负载均衡、云网络等产品，可以有效缓解DDoS攻击的危害。 3，考虑选择合适的DDoS防护方案，主动抵御可能出现的DDoS攻击。 4，准备应对DDoS预案，第一时间响应并实施应对方案。

2021 年十个重大宕机事件

互联网技术发展到了 2022 年，理论上来说是可以做到“永不宕机”的。但过去的 2021 年，宕机事故看起来一点也没有减少。

随着“国民级应用”增多，大家对技术的依赖程度越来越高，面临的风险比以往任何时候都多。宕机影响的不仅是内部用户，连带还会影响到客户和合作伙伴的收入、信誉和生产力等各个方面。

宕机事故不可预测，因此它也被称为系统中的“黑天鹅”。当前大型互联网系统架构日趋复杂，稳定性风险也在升高，系统中一定会有一些黑天鹅潜伏着，只是还没被发现。然而墨菲定律告诉我们“该出错的终究会出错”。我们整理了 2021 年发生的十个重大宕机事件，并总结了故障原因。这些故障大部分是人为造成的，并且依然是我们在系统建设中需要特别注意的地方。

7 月 13 日晚间，视频网站哔哩哔哩（B 站）出现服务器宕机事故，无法登陆的用户涌向其它站点，连锁导致了一系列宕机事故。“B 站崩了”、“豆瓣崩了”、“A 站也崩了”、“晋江崩了”等接连冲上了热搜。

据数据显示，当时 B 站月活用户为 2.23 亿，其中 35 岁及以下的用户比重超过 86%。显然这些年轻人非常能熬夜，虽然宕机发生在深夜，但是大家吵吵闹闹地分析原因甚至还惊动了消防局。有网友认为“B 站崩了是因为有火情发生”，上海消防回复说：“经了解，位于上海市政立路 485 号国正中心内的哔哩哔哩弹幕网 B 站（总部）未出现火情，未接到相关报警。具体情况以站方公布为准。”

半夜 2 点之后，B 站终于发了一个非常简短的说明：“部分服务器机房发生故障，造成无法访问。”

只是 B 站这个解释，像是什么都说了，又像是什么都没说。

10 月 9 日凌晨，互联网券商富途证券 App 出现故障，用户无法登录进行交易。到了下午，富途证券发布了相关说明并致歉。富途证券表示，事故原因为“运营商机房电力闪断导致的多机房网络故障”，公司已于第一时间联系运营商进行修复，并在 2 小时内陆续恢复核心服务。

这次宕机本来并未引起证券行业之外的关注，但是随后富途创始人李华（叶子哥）的文章却让这次宕机事件火出了圈。11 日中午，技术出身的李华发布了一篇 2000 字长文，向用户致歉，文章里更多的篇幅却是从技术角度解释为什么会“宕机”。

虽然和 B 站一样是因为服务器机房故障，李华却从容灾设计的各个环节给了大家详细的说明。

李华表示，富途的证券系统中从行情到交易、从服务器到交易网关到网络传输都有做双路或多路的冗余设计。不同的子系统设计会有所不同。以行情为例，单向传输为主、对时延的敏感度也不是那么高，富途很早就作了多区域多 IDC 的容灾设计；尤其像美股行情，涉及到越洋传输，为避免中断，富途选择了全球顶级的两家行情供应商分别提供行情源，分别从美国、香港多地多点接入，当这些都不可用时，富途还保留了富途美国 IDC 直传的能力。不考虑其他的冗余设计，光是因为行情源的冗余，富途一年增加的成本过千万港元。

李华指出，在实时热备的多路冗余交易系统的设计上会面临着两种选择。一是较差的交易性能更大的订单延时但更好容灾能力的跨 IDC 多路冗余方案，二是更好的交易性能较小的订单提交延时单一 IDC 的多路冗余方案，但 IDC 本身会成为故障的单点。这也间接导致了一定要做出选择。在李华看来，考虑到 IDC 的建设标准，IDC 的大级别事故是罕见的，尤其是在电力故障方面。经过综合推演之后，富途选择了更好性能的方案二，也因此留下了 IDC 的单点故障隐患。这次事故恰恰就是 IDC 出了问题，而且是最不应该出现问题的电力系统出了问题，不间断电源和柴油发电机都没能发挥应有的作用。

李华的硬核文章也得到了很多富途证券用户的支持和鼓励。

2021 年 12 月 20 日，西安“一码通”因访问量过大导致系统崩溃。当时西安市大数据资源管理局称，“一码通”注册用户已达 4695.2 万人，日均扫码量超 800 万人次。由于在各公共场所加大了扫码查验，同时开展多轮全员核酸检测，“一码通”每秒访问量达到以往峰值的 10 倍以上，并建议市民非必要不展码、亮码。

2022 年 1 月 4 日上午 9 时，西安“一码通”第二次崩溃。西安市开启新一轮核酸筛查，许多西安网友反应，“西安一码通”系统再次崩溃，无法显示疫情防控码。话题 # 西安一码通 # 一度冲上微博热搜第一。西安市相关部门公开回应称，因访问量太大，全市“一码通”均出现无法正常显示的问题。当天下午西安“一码通”已经逐步恢复正常使用。

据了解，西安“一码通”是 2020 年 2 月西安市针对疫情防控牵头开发的大数据平台，业主单位是西安市大数据资源管理局。据工信部官网 1 月 4 日的报道，12 月 30 日 -31 日，工信部曾对陕西省通信管理局展开疫情防控工作调研，并要求西安“一码通”加强技术改进和网络扩容，确保不拥塞宕机。

碰巧的是，2022 年 1 月 10 日上午 8:30 左右，不少用户反映“粤康码”打不开了。上午 10:00 之后，情况逐渐得到缓解。随后，“粤康码”App 发布了一个很专业的官方说明。

10 月 4 日，美国社交媒体 Facebook、Instagram 和即时通讯软件 WhatsApp 出现大规模宕机，此次宕机长达近 7 个小时，刷新了 Facebook 自 2008 年以来的最长宕机时长。

WhatsApp 和 Facebook Messenger 两款“微信”类即时通信产品，分别在全球范围拥有 20 亿用户和 13 亿用户，社交平台 Instagram 用户数也达到了 10 亿用户，也就是说这次宕机影响了超 30 亿用户。宕机期间，绝望的用户涌向了 Twitter、Discord、Signal 和 Telegram，又导致这些应用程序的服务器纷纷崩溃。

Facebook 事后发表了故障报告，表示在一项日常维护工作中，工程师们发出一条用于评估全球骨干网容量可用性的指令，但意外切断了骨干网络中的所有连接，这实质上就是断开了 Facebook 全球数据中心之间的连接。服务中断之后，Facebook 的工程师们因无法通过正常方式访问 Facebook 数据中心进行修复，导致故障持续了 7 个小时之久。

据悉，这次事故让脸书一夜之间市值蒸发约 473 亿美元 (约合 3049 亿元人民币)。

10 月 28 日，Roblox 发生了一次长达 73 小时的宕机事故。Roblox 是目前在全球范围内备受欢迎的在线游戏平台，日活跃用户超过 5000 万，其中许多人的年龄在 13 岁或以下。值得一提的是，Roblox 还被认为是“元宇宙”（metaverse）的关键参与者。

Roblox 随后发布了非常详细的故障报告。在报告中，Roblox 的技术人员解释到，Roblox 程序运行在他们自己的数据中心中。为了管理自己众多的服务器，Roblox 使用了开源 Consul 进行服务发现、健康检查。Roblox 表示宕机主要是因启用了 Consul 里的流式传输功能代替长轮询机制，但流式传输功能存在 bug，最终导致性能下降而引起系统崩溃。宕机 54 个小时后才排查出故障原因，通过禁止流式传输功能，逐渐恢复了系统的服务能力。

在这样的服务中断之后，很多人很自然地询问 Roblox 是否会考虑迁移到公共云，让第三方管理 Roblox 的基础计算、存储和网络服务。

Roblox 技术人员表示，与使用公有云相比，自建数据中心能够显着控制成本。此外，拥有自己的硬件并构建自己的边缘基础设施能使 Roblox 最大限度地减少性能变化并管理全球玩家的延时。但也并不拘泥于任何特定的方法：“我们将公共云用于对我们的玩家和开发人员最有意义的用例，例如突发容量、大部分 DevOps 工作流程以及大部分内部分析。但对于对性能和延迟至关重要的工作负载，我们选择在本地构建和管理自己的基础架构。这样才能使我们能够建立一个更好的平台。”

Salesforce 是目前最受欢迎的云软件应用程序之一。据报道该软件应用程序已被全球大约 150,000 个组织中的数百万名员工使用。Salesforce 提供的服务涉及客户关系管理的各个方面，从普通的联系人管理、产品目录到订单管理、机会管理、销售管理等。用户无需花费大量资金和人力用于记录的维护、储存和管理，所有的记录和数据都储存在 Salesforce.com 上面。

5 月 11 日，Salesforce 的服务开始不可用，宕机持续了 5 个小时。事后，Salesforce 公司组织了一次客户简报会，完整披露了事件情况与相关工程师的操作流程。虽然 Salesforce 向来以高度自动化的内部业务流程为傲，但其中不少环节仍然只能手动操作完成——DNS 正是其中之一。工程师使用的配置脚本执行一项配置变更，变更后需要重启服务器生效，不幸的是，脚本更新发生超时失败。随后更新又在 Salesforce 各数据中心内不断部署，超时点也被不断引爆...... 对这位决心绕开既有管理政策、意外肇事的工程师本人，Salesforce 表示“我们已经对这位员工做出了适当处理。”

3 月份，欧洲云计算巨头 OVH 位于法国斯特拉斯堡的机房近日发生严重火灾，该区域总共有 4 个数据中心 (Strasbourg Data Center)，发生起火的 SBG2 数据中心被完全烧毁，另有一个数据中心 SBG1 的建筑物部分受损。当地报纸称 115 位消防员投入 6 个小时才将其扑灭。经过长达 6 个小时的持续燃烧，SBG2 内的数据应该会损失惨重。

这场大火对欧洲范围内的众多网站造成严重影响。据悉，总共有跨 464000 个域的多达 360 万个网站下线。

受到此次大火影响的客户包括欧洲航天局的数据与信息访问服务 ONDA 项目，此项目负责为用户托管地理空间数据并在云端构建应用程序。Rust 旗下的游戏工作室 Facepunch Studios 证实，有 25 台服务器被烧毁，他们的数据已在这场大火中全部丢失。即使数据中心重新上线后，也无法恢复任何数据。其他客户还包括法国政府，其 data.gouv.Fr 网站也被迫下线。另外还有加密货币交易所 Deribit，以及负责跟踪 DDoS 僵尸网络与其他网络滥用问题的信息安全威胁情报厂商 Bad Packets......

其中还有些人很不走运：“不！！！我靠！！！我的服务器在机架 70C09 上，我就是个普通客户，我没有任何灾难恢复计划……”

6 月 8 日，当全球各地数以亿计的互联网用户登陆自己平日经常登陆的网站时，发现页面无法打开，并出现了“503 Errors”的错误提示，包括亚马逊、Twitter、Reddit、Twitch、HBO Max、Hulu、PayPal、Pinterest 以及包括纽约时报、CNN 等在内的各种类型的网站均悉数中招。

大约持续了一个小时之后，人们才发现这场大规模故障是由 CDN 服务公司 Fastly 引起的。Fastly 通过其官方推特和博客称，“我们发现一个服务配置的更改引发了全球服务的短暂中断，目前已将这一配置关闭，我们全球服务网络已恢复正常。”

于 2011 年成立的 Fastly 是全球为数不多的大型 CDN 供应商之一，可加快用户浏览速度和体验。有意思的是，出问题之后 Fastly 的股价在当天出现大涨，因为通过这起事件，投资者意识到，这家总部位于旧金山，员工数不到 1000 人的小公司，对互联网世界有着举足轻重的影响力。

11 月 16 日，据国外媒体报道，全球最大的云服务提供商之一谷歌云（Google Cloud）出现了宕机，导致许多依赖于谷歌云的大型公司网站中断服务。

中断持续约 2 个小时，其中包括家得宝、Spotify 等公司都接到用户关于服务中断的反馈，另外 Etsy 和 Snap 的服务也发生网络故障。此外本次宕机对谷歌自家服务影响颇深，YouTube、Gmail、Google Search 均停止了工作。

据悉此事件是谷歌云用户错误配置外部代理负载平衡 (GCLB) 所导致，算是一个漏洞，在 6 个月前被引入，极少数情况下，该漏洞允许损坏的配置文件被推送到 GCLB。11 月 12 日，一位 Google 工程师就发现此漏洞。谷歌原计划于 11 月 15 日推出补丁，但是不巧的是还没修复完，服务中断就发生了。

在 2021 年的最后一个月，AWS 发生了 3 次宕机。第一次宕机发生美国东部时间 7 日，从上午 10 点 45 分持续到下午 2 点 22 分，包括迪斯尼、奈飞、Robinhood、Roku 等大量热门网站和应用都发生了网络中断。同时，亚马逊的 Alexa AI 助理、Kindle 电子书、亚马逊音乐、Ring 安全摄像头等业务也受到影响。

12 月 10 日，AWS 公布了本次宕机的原因：某内部客户端的意外行为导致连接活动激增，使内部网络和主 AWS 网络之间的联网设备不堪重负，从而导致这些网络之间的通信延迟。这些延迟增加了在网络之间通信的服务延迟和错误，从而导致更多的连接尝试和重试，最终引发持续的堵塞和性能问题。

12 月第二次宕机发生在 16 日上午 7 点 43 分左右，包括 Twitch、Zoom、PSN、Xbox Live、Doordash、Quickbooks Online 和 Hulu 等在线服务均受到影响。AWS 随后公布了故障原因：由于主网络中某自动化软件原因，错误得将一些流量转移到主干网，结果影响了一些互联网应用的连接。

12 月第三次宕机发生在 23 日美国东部时间 7 点 30 分左右，包括 Slack、Epic Games、加密货币交易所 Coinbase Global、游戏公司 Fortnite 、约会应用程序 Grindr 和交付公司 Instacart。对于此次中断，AWS 初步调查称是数据中心供电的问题。

最后，希望 2022 年大家都不会经历宕机～

---