WEBVTT

00:00.660 --> 00:01.710
المحاضر: سنتحدث

00:01.710 --> 00:04.920
في هذا الدرس عن أهمية موازنات الأحمال.

00:04.920 --> 00:06.120
يتم الآن استخدام موازنات

00:06.120 --> 00:08.340
التحميل، والتي تُعرف أيضًا باسم تبديل

00:08.340 --> 00:10.410
المحتوى، لتوزيع الطلبات الواردة

00:10.410 --> 00:11.910
عبر عدد من الخوادم داخل نموذج

00:11.910 --> 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:23.513
يحضرون دوراتي ويشاهدون

00:23.513 --> 00:25.680
مقاطع الفيديو الخاصة بي.

00:25.680 --> 00:29.100
لا توجد طريقة يستطيع بها خادم واحد التعامل مع هذا القدر من الحمل.

00:29.100 --> 00:30.630
لذلك يتعين علينا توزيعها عبر

00:30.630 --> 00:32.460
العديد من الخوادم المختلفة في جميع

00:32.460 --> 00:33.810
أنحاء العالم.

00:33.810 --> 00:36.300
ولكن عندما يريد أحد الطلاب زيارة موقع الويب الخاص

00:36.300 --> 00:38.340
بي، فلا يتعين عليه اختيار خادم معين.

00:38.340 --> 00:41.070
بدلا من ذلك، يذهبون فقط إلى التدريب على الديون. com ويقوم موازن التحميل

00:41.070 --> 00:43.230
ومحول المحتوى الخاص بنا بإعادة توجيه

00:43.230 --> 00:45.960
هذا الطلب إلى الخادم التالي المتاح حتى يتمكن

00:45.960 --> 00:47.460
من معالجته.

00:47.460 --> 00:49.590
في الواقع، لدينا الكثير من الخوادم المختلفة

00:49.590 --> 00:50.880
الموجودة في جميع أنحاء العالم

00:50.880 --> 00:53.100
للتعامل مع كل تلك الطلبات المختلفة.

00:53.100 --> 00:55.230
يحدث نفس الشيء تمامًا مع Netflix

00:55.230 --> 00:57.480
أو Hulu أو Facebook أو Amazon، ولكن

00:57.480 --> 00:59.280
على نطاق أوسع بكثير.

00:59.280 --> 01:01.920
يتعين على جميع مواقع الويب الكبيرة هذه استخدام

01:01.920 --> 01:03.570
موازن التحميل، وإلا فسيتعطل

01:03.570 --> 01:06.263
خادم واحد ببساطة تحت الحمل وسيعاني من هجوم

01:06.263 --> 01:08.400
رفض الخدمة المفروض ذاتيًا بسبب شعبية

01:08.400 --> 01:10.650
موقع الويب الخاص به.

01:10.650 --> 01:12.510
يعمل الآن موازن التحميل بشكل

01:12.510 --> 01:13.500
أساسي كشرطي مرور

01:13.500 --> 01:15.120
من خلال الجلوس أمام خوادمك

01:15.120 --> 01:17.310
وتوجيه طلب العميل إلى الخوادم الأكثر

01:17.310 --> 01:19.410
توفرًا لتلبية هذه الطلبات في أي

01:19.410 --> 01:20.970
وقت محدد.

01:20.970 --> 01:23.940
يؤدي ذلك إلى زيادة سرعة الاستجابة للمستخدم

01:23.940 --> 01:25.530
واستخدام كل السعة الحالية

01:25.530 --> 01:28.170
لخوادمك بشكل أكثر كفاءة لجميع طلبات المستخدم

01:28.170 --> 01:30.060
الخاصة بك.

01:30.060 --> 01:32.220
السبب وراء أهمية موازن التحميل هو أنه

01:32.220 --> 01:34.230
أحد الأشياء الأساسية التي يمكننا

01:34.230 --> 01:36.750
القيام بها للمساعدة في الدفاع ضد هجوم رفض

01:36.750 --> 01:39.270
الخدمة أو هجوم رفض الخدمة الموزع.

01:39.270 --> 01:41.730
والآن، ما هو هجوم رفض الخدمة؟

01:41.730 --> 01:43.560
حسنًا، يتضمن هجوم رفض الخدمة

01:43.560 --> 01:46.410
غمرًا مستمرًا للأنظمة الضحية بطلبات

01:46.410 --> 01:48.090
الخدمات، مما يتسبب في

01:48.090 --> 01:50.070
نفاد ذاكرة النظام وتعطله

01:50.070 --> 01:51.570
في النهاية.

01:51.570 --> 01:52.830
الآن لا يمكن إزالة معظم

01:52.830 --> 01:55.230
الأنظمة الحديثة بواسطة جهاز واحد.

01:55.230 --> 01:58.230
لذا بدلاً من ذلك، يستخدم المهاجمون هجوم DDoS

01:58.230 --> 02:00.540
أو هجوم رفض الخدمة الموزع.

02:00.540 --> 02:02.490
في هجوم رفض الخدمة الموزعة، بدلاً

02:02.490 --> 02:04.920
من مهاجم واحد يستهدف الخادم، هناك مئات

02:04.920 --> 02:07.200
أو حتى آلاف الأجهزة التي تطلق هذا الهجوم

02:07.200 --> 02:10.050
في وقت واحد على الخادم، لإجباره على عدم الاتصال

02:10.050 --> 02:11.670
بالإنترنت.

02:11.670 --> 02:14.040
في مارس من عام 2018، على سبيل المثال،

02:14.040 --> 02:16.410
تعرض GitHub لأكبر هجوم DDoS حتى الآن،

02:16.410 --> 02:18.570
حيث نفذت عشرات الآلاف من نقاط النهاية

02:18.570 --> 02:20.160
الفريدة هجومًا منسقًا لضرب

02:20.160 --> 02:22.230
ذلك الخادم مع ارتفاع كبير في حركة

02:22.230 --> 02:25.620
المرور بلغ 1. 35 تيرابايت في الثانية.

02:25.620 --> 02:28.980
أدى هذا إلى إجبار الموقع على عدم الاتصال بالإنترنت لمدة خمس دقائق.

02:28.980 --> 02:30.750
لكن السؤال الحقيقي هو كيف

02:30.750 --> 02:32.670
يمكننا النجاة من إحدى هذه الهجمات

02:32.670 --> 02:35.760
ومنعها من تدمير خوادم مؤسستنا؟

02:35.760 --> 02:37.620
حسنًا، نحتاج فقط إلى إلقاء نظرة على أمازون

02:37.620 --> 02:39.330
للتعرف على بعض أفضل الممارسات.

02:39.330 --> 02:41.520
كما ترى، في فبراير من عام 2020، تعرضت

02:41.520 --> 02:44.130
أمازون لأكبر هجوم DDoS حتى الآن، حتى أكبر

02:44.130 --> 02:45.630
من GitHub.

02:45.630 --> 02:47.130
وكان هناك هجوم منسق

02:47.130 --> 02:49.230
لضرب ذلك الخادم مع زيادة في

02:49.230 --> 02:52.410
حركة المرور بلغت 2. 3 تيرابايت في الثانية،

02:52.410 --> 02:55.470
ولكن نظرًا للبنية الأمنية الجيدة التي يتمتعون

02:55.470 --> 02:57.480
بها وقدرتهم على زيادة الموارد

02:57.480 --> 02:58.950
لدعم هذا الهجوم، لم يتعرضوا

02:58.950 --> 03:01.650
لأي توقف أثناء الهجوم، على الرغم من أنه

03:01.650 --> 03:03.900
كان أكبر بنسبة 70٪ من الهجوم الذي

03:03.900 --> 03:05.880
أسقط GitHub.

03:05.880 --> 03:07.410
الآن، تُعرف التقنية الأولى

03:07.410 --> 03:09.750
التي استخدموها بالثقب الأسود أو الغرق.

03:09.750 --> 03:10.800
هذه تقنية تحدد أي

03:10.800 --> 03:13.020
عناوين IP مهاجمة وتوجه كل حركة المرور

03:13.020 --> 03:14.400
الخاصة بها إلى خادم غير

03:14.400 --> 03:17.160
موجود من خلال واجهة فارغة، مما يؤدي إلى إيقاف

03:17.160 --> 03:19.410
الهجوم بشكل فعال.

03:19.410 --> 03:22.050
لسوء الحظ، يمكن للمهاجمين دائمًا الانتقال إلى عنوان

03:22.050 --> 03:23.760
IP جديد وبدء الهجوم مرة أخرى.

03:23.760 --> 03:25.950
لذلك، لن يمنع ذلك هجمات DDoS إلى الأبد،

03:25.950 --> 03:27.480
ولكنه سيوفر لك بعض الوقت أثناء

03:27.480 --> 03:29.640
العمل على إجراءات تخفيف أخرى.

03:29.640 --> 03:32.070
يمكن أيضًا استخدام أنظمة IPS، أو أنظمة

03:32.070 --> 03:33.510
منع التطفل، لتحديد هجمات

03:33.510 --> 03:35.730
رفض الخدمة والرد عليها.

03:35.730 --> 03:37.560
قد يعمل هذا بشكل جيد مع الهجمات

03:37.560 --> 03:38.520
صغيرة النطاق ضد شبكتك،

03:38.520 --> 03:40.920
لكنه لن يتمتع بقدرة معالجة كافية للتعامل

03:40.920 --> 03:42.780
مع هجوم واسع النطاق حقًا، مثل الهجوم

03:42.780 --> 03:45.060
الذي استهدفته أمازون.

03:45.060 --> 03:46.920
الآن، إحدى أكثر الطرق فعالية هي

03:46.920 --> 03:49.140
استخدام البنية التحتية السحابية المرنة،

03:49.140 --> 03:52.290
لأنها تسمح لك بتوسيع نطاق الطلب حسب الحاجة، حتى تتمكن

03:52.290 --> 03:54.300
من التغلب على الهجوم.

03:54.300 --> 03:55.770
لكن المشكلة في هذه الإستراتيجية

03:55.770 --> 03:57.090
هي أن معظم مقدمي الخدمة سيفرضون

03:57.090 --> 03:58.920
عليك رسومًا بناءً على القدرات والموارد

03:58.920 --> 04:00.510
التي تستخدمها.

04:00.510 --> 04:02.190
لذلك، مع توسعك، يؤدي ذلك إلى

04:02.190 --> 04:04.380
تلقينا فاتورة أكبر بكثير من مزود

04:04.380 --> 04:05.940
الخدمة السحابية لدينا،

04:05.940 --> 04:07.320
وقد يكون هذا شيئًا لا

04:07.320 --> 04:09.390
نحصل على أي عائد على الاستثمار فيه،

04:09.390 --> 04:13.110
لأن كل تلك الحركة لم تكن تدر أي إيرادات لمؤسستنا كان كل ذلك

04:13.110 --> 04:15.090
مجرد جزء من الهجوم.

04:15.090 --> 04:17.280
ومع ذلك، على الأقل ستظل متصلاً بالإنترنت لخدمة

04:17.280 --> 04:18.750
عملائك الذين يدفعون.

04:18.750 --> 04:20.400
لذلك يصبح الأمر مجرد مسألة ما

04:20.400 --> 04:22.140
إذا كان بإمكانك الاستمرار لفترة

04:22.140 --> 04:24.213
أطول من استمرار هجوم DDoS.