WEBVTT

00:00.660 --> 00:01.710
讲师：在这节课中,

00:01.710 --> 00:04.920
我们将讨论负载均衡器的重要性｡

00:04.920 --> 00:15.330
现在, 负载均衡器（也称为内容交换机）用于在服务器表单或云基础设施内的多个服务器上分发传入请求｡

00:15.330 --> 00:17.370
如果你正在运行一个大型网站或服务,

00:17.370 --> 00:20.040
你不能在一台服务器上完成所有这些工作｡

00:20.040 --> 00:22.680
例如, 我有几十万学生在这一点上,

00:22.680 --> 00:25.680
采取我的课程和观看我的视频｡

00:25.680 --> 00:29.100
一台服务器无法处理这么多负载｡ 

00:29.100 --> 00:33.810
所以我们必须把它分布在世界各地的许多不同的服务器上｡

00:33.810 --> 00:38.340
但是, 当一个学生想访问我的网站, 他们不必选择一个特定的服务器｡

00:38.340 --> 00:45.960
相反, 他们只是去迪昂训练｡  com, 我们的负载平衡器和内容交换机将该请求重定向到下一个可用的服务器,

00:45.960 --> 00:47.460
以便能够处理它｡

00:47.460 --> 00:53.100
事实上, 我们在世界各地有大量不同的服务器来处理所有这些不同的请求｡

00:53.100 --> 00:55.230
同样的事情也发生在Netflix､

00:55.230 --> 00:57.480
Hulu､ Facebook或亚马逊上,

00:57.480 --> 00:59.280
但规模要大得多｡

00:59.280 --> 01:01.920
所有这些大型网站都必须使用负载均衡器,

01:01.920 --> 01:03.570
否则单个服务器将在负载下崩溃,

01:03.570 --> 01:10.650
并且由于其网站的受欢迎程度, 他们将遭受自我强加的拒绝服务攻击｡

01:10.650 --> 01:13.500
现在, 负载均衡器基本上充当了交通警察的角色,

01:13.500 --> 01:20.970
它坐在服务器前面, 将客户端的请求路由到在任何给定时间最有可能满足这些请求的服务器｡

01:20.970 --> 01:23.940
这样可以最大限度地提高响应用户的速度,

01:23.940 --> 01:30.060
并且可以更有效地使用服务器的所有现有容量来处理所有用户请求｡

01:30.060 --> 01:32.220
负载均衡器如此重要的原因是,

01:32.220 --> 01:39.270
它是我们可以帮助防御拒绝服务攻击或分布式拒绝服务攻击的关键之一｡

01:39.270 --> 01:41.730
什么是拒绝服务攻击？

01:41.730 --> 01:46.410
拒绝服务攻击是指不断向受害者系统发送大量服务请求,

01:46.410 --> 01:51.570
导致系统内存不足并最终崩溃｡

01:51.570 --> 01:55.230
然而, 现在大多数现代系统都不能被一台机器摧毁｡

01:55.230 --> 02:00.540
因此, 攻击者使用DDoS或分布式拒绝服务攻击｡

02:00.540 --> 02:02.490
在分布式拒绝服务攻击中,

02:02.490 --> 02:04.920
不是单个攻击者针对服务器,

02:04.920 --> 02:11.670
而是数百甚至数千台机器同时对服务器发起攻击, 以迫使其脱机｡

02:11.670 --> 02:16.410
例如, 在2018年3月, GitHub受到了迄今为止最大的DDoS攻击,

02:16.410 --> 02:25.620
成千上万的独特端点进行了协调攻击, 以1的流量峰值攻击该服务器｡

02:25.620 --> 02:25.620
每秒35太比特｡ 

02:25.620 --> 02:28.980
这迫使该网站离线了整整五分钟｡ 

02:28.980 --> 02:32.670
但真正的问题是, 我们如何才能在这些攻击中幸存下来,

02:32.670 --> 02:35.760
并防止它摧毁我们组织的服务器？

02:35.760 --> 02:39.330
好吧, 我们只需要看看亚马逊的一些最佳实践｡

02:39.330 --> 02:41.520
在2020年2月, 亚马逊遭受了迄今为止最大的DDoS攻击,

02:41.520 --> 02:45.630
甚至比GitHub还大｡

02:45.630 --> 02:49.230
有一个协同攻击击中了该服务器的流量峰值,

02:49.230 --> 02:55.470
测量2｡ 每秒3TB, 但由于他们拥有良好的安全架构,

02:55.470 --> 02:57.480
并且能够扩展资源以维持攻击,

02:57.480 --> 03:05.880
他们在攻击期间没有遭受停机时间, 尽管它比GitHub大70%｡

03:05.880 --> 03:09.750
他们使用的第一种技术被称为黑洞或天坑｡

03:09.750 --> 03:17.160
这是一种识别任何攻击IP地址并通过空接口将其所有流量路由到不存在的服务器的技术,

03:17.160 --> 03:19.410
有效地阻止了攻击｡

03:19.410 --> 03:23.760
不幸的是, 攻击者总是可以移动到一个新的IP并重新开始攻击｡

03:23.760 --> 03:25.950
因此, 它不会永远阻止DDoS攻击,

03:25.950 --> 03:29.640
但它会为您在其他缓解措施上争取一些时间｡

03:29.640 --> 03:35.730
IPS或入侵防御系统也可用于识别和响应拒绝服务攻击｡

03:35.730 --> 03:38.520
这可能适用于针对您的网络的小规模攻击,

03:38.520 --> 03:40.920
但它没有足够的处理能力来处理真正的大规模攻击,

03:40.920 --> 03:45.060
例如Amazon针对的攻击｡

03:45.060 --> 03:46.920
现在最有效的方法之一是使用弹性云基础设施,

03:46.920 --> 03:49.140
因为它允许您根据需要进行扩展,

03:49.140 --> 03:54.300
因此您可以安然度过攻击｡

03:54.300 --> 03:55.770
然而, 这种策略的问题是,

03:55.770 --> 04:00.510
大多数服务提供商将根据您使用的容量和资源向您收费｡

04:00.510 --> 04:02.190
因此, 随着规模的扩大,

04:02.190 --> 04:05.940
这会导致我们从云服务提供商那里收到更大的账单,

04:05.940 --> 04:13.110
而这可能是我们无法获得任何投资回报的事情, 因为所有这些流量都没有为我们的组织产生任何收入,

04:13.110 --> 04:15.090
这只是攻击的一部分｡

04:15.090 --> 04:18.750
也就是说, 至少你仍然在线为你的付费客户服务｡

04:18.750 --> 04:20.400
因此, 这只是一个问题,

04:20.400 --> 04:24.213
如果你能承受持续时间比DDoS攻击可以继续下去｡