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: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:32.460
ดังนั้นเราจึงต้องแจกจ่ายไปยังเซิร์ฟเวอร์ต่างๆ

00:32.460 --> 00:33.810
มากมายทั่วโลก

00:33.810 --> 00:38.340
แต่เมื่อนักเรียนต้องการเข้าชมเว็บไซต์ของฉัน พวกเขาไม่จำเป็นต้องเลือกเซิร์ฟเวอร์เฉพาะ

00:38.340 --> 00:47.460
พวกเขาแค่ไปฝึกไดออนแทน com และโหลดบาลานเซอร์และสวิตช์เนื้อหาของเราเปลี่ยนเส้นทางที่ร้องขอไปยังเซิร์ฟเวอร์ที่มีอยู่ถัดไปเพื่อให้สามารถดำเนินการได้

00:47.460 --> 00:53.100
อันที่จริง เรามีเซิร์ฟเวอร์ที่แตกต่างกันมากมายทั่วโลกเพื่อรองรับคำขอที่แตกต่างกันทั้งหมด

00:53.100 --> 00:55.230
สิ่งเดียวกันนี้เกิดขึ้นกับ Netflix

00:55.230 --> 00:59.280
หรือ Hulu หรือ Facebook หรือ Amazon แต่ในระดับที่ใหญ่กว่ามาก

00:59.280 --> 01:01.920
เว็บไซต์ขนาดใหญ่ทั้งหมดเหล่านี้ต้องใช้โหลดบาลานเซอร์

01:01.920 --> 01:10.650
มิฉะนั้นเซิร์ฟเวอร์เดียวอาจล่มภายใต้การโหลด และพวกเขาอาจประสบกับการโจมตีแบบปฏิเสธการให้บริการเนื่องจากความนิยมของเว็บไซต์

01:10.650 --> 01:20.970
ตอนนี้โหลดบาลานเซอร์ทำหน้าที่เป็นตำรวจจราจรโดยนั่งอยู่หน้าเซิร์ฟเวอร์ของคุณและกำหนดเส้นทางคำขอของลูกค้าไปยังเซิร์ฟเวอร์ที่พร้อมที่สุดในการดำเนินการตามคำขอเหล่านั้นในเวลาใดก็ตาม

01:20.970 --> 01:30.060
สิ่งนี้จะเพิ่มความเร็วในการตอบสนองต่อผู้ใช้และใช้ความสามารถที่มีอยู่ทั้งหมดของคุณสำหรับเซิร์ฟเวอร์ของคุณอย่างมีประสิทธิภาพมากขึ้นสำหรับคำขอของผู้ใช้ทั้งหมดของคุณ

01:30.060 --> 01:39.270
เหตุผลที่โหลดบาลานเซอร์มีความสำคัญมาก ก็คือเป็นหนึ่งในสิ่งสำคัญที่เราสามารถทำได้เพื่อช่วยป้องกันการโจมตีแบบปฏิเสธการให้บริการหรือการโจมตีแบบปฏิเสธการให้บริการแบบกระจาย

01:39.270 --> 01:41.730
ทีนี้ การโจมตีแบบ Denial of Service คืออะไร?

01:41.730 --> 01:43.560
การโจมตีแบบ Denial of Service

01:43.560 --> 01:48.090
เกี่ยวข้องกับการที่ระบบของเหยื่อท่วมอย่างต่อเนื่องพร้อมคำขอบริการ

01:48.090 --> 01:51.570
ทำให้ระบบมีหน่วยความจำไม่เพียงพอและล่มในที่สุด

01:51.570 --> 01:55.230
ตอนนี้ระบบที่ทันสมัยส่วนใหญ่ไม่สามารถทำลายได้ด้วยเครื่องจักรเครื่องเดียว

01:55.230 --> 01:58.230
ดังนั้น ผู้โจมตีจึงใช้ DDoS หรือการโจมตีแบบ

01:58.230 --> 02:00.540
Distributed Denial of Service แทน

02:00.540 --> 02:02.490
ในการโจมตีแบบ Distributed Denial of Service

02:02.490 --> 02:04.920
แทนที่จะเป็นผู้โจมตีรายเดียวที่กำหนดเป้าหมายไปที่เซิร์ฟเวอร์

02:04.920 --> 02:07.200
มีเครื่องหลายร้อยหรือหลายพันเครื่องเปิดการโจมตีนั้นบนเซิร์ฟเวอร์พร้อมๆ

02:07.200 --> 02:11.670
กัน เพื่อบังคับให้เซิร์ฟเวอร์ออฟไลน์

02:11.670 --> 02:14.040
ตัวอย่างเช่น ในเดือนมีนาคมปี 2018 GitHub ถูกโจมตีโดย

02:14.040 --> 02:22.230
DDoS ที่ใหญ่ที่สุดในปัจจุบัน โดยที่จุดสิ้นสุดที่ไม่ซ้ำกันหลายหมื่นจุดได้ทำการโจมตีแบบประสานกันเพื่อโจมตีเซิร์ฟเวอร์นั้นด้วยปริมาณการรับส่งข้อมูลที่เพิ่มขึ้นอย่างรวดเร็วที่วัดได้

02:22.230 --> 02:25.620
1 35 เทราบิตต่อวินาที

02:25.620 --> 02:28.980
สิ่งนี้บังคับให้ไซต์ออฟไลน์เป็นเวลาห้านาที

02:28.980 --> 02:35.760
แต่คำถามที่แท้จริงคือ เราจะเอาตัวรอดจากการโจมตีเหล่านี้และป้องกันไม่ให้เซิร์ฟเวอร์ขององค์กรล่มได้อย่างไร

02:35.760 --> 02:37.620
เราแค่ต้องดูแนวทางปฏิบัติที่ดีที่สุดบางอย่างที่

02:37.620 --> 02:39.330
Amazon

02:39.330 --> 02:41.520
คุณคงเห็นแล้วว่าในเดือนกุมภาพันธ์ปี 2020

02:41.520 --> 02:44.130
Amazon ถูกโจมตีโดย DDoS ที่ใหญ่ที่สุดจนถึงปัจจุบัน

02:44.130 --> 02:45.630
ใหญ่กว่า GitHub เสียอีก

02:45.630 --> 02:49.230
และมีการโจมตีที่ประสานกันเพื่อโจมตีเซิร์ฟเวอร์นั้นด้วยปริมาณการรับส่งข้อมูลที่วัดได้

02:49.230 --> 02:58.950
2 3 เทราบิตต่อวินาที แต่เนื่องจากสถาปัตยกรรมการรักษาความปลอดภัยที่ดีและความสามารถในการปรับขนาดทรัพยากรเพื่อรองรับการโจมตีนั้น

02:58.950 --> 03:01.650
พวกเขาจึงไม่ต้องหยุดทำงานระหว่างการโจมตี แม้ว่ามันจะใหญ่กว่า

03:01.650 --> 03:05.880
70% ที่ใหญ่กว่าที่ทำลาย GitHub ก็ตาม

03:05.880 --> 03:07.410
ตอนนี้ เทคนิคแรกที่พวกเขาใช้เรียกว่า

03:07.410 --> 03:09.750
blackholing หรือ sinkholing

03:09.750 --> 03:10.800
นี่เป็นเทคนิคที่ระบุที่อยู่

03:10.800 --> 03:19.410
IP ใด ๆ ที่ถูกโจมตีและกำหนดเส้นทางการรับส่งข้อมูลทั้งหมดไปยังเซิร์ฟเวอร์ที่ไม่มีอยู่จริงผ่านอินเทอร์เฟซว่าง ซึ่งหยุดการโจมตีได้อย่างมีประสิทธิภาพ

03:19.410 --> 03:23.760
น่าเสียดายที่ผู้โจมตีสามารถย้ายไปยัง IP ใหม่ได้ตลอดเวลาและเริ่มการโจมตีใหม่อีกครั้ง

03:23.760 --> 03:29.640
ดังนั้นมันจะไม่ป้องกัน DDoS ตลอดไป แต่มันจะซื้อเวลาให้คุณในขณะที่คุณทำงานเพื่อบรรเทาผลกระทบอื่นๆ

03:29.640 --> 03:35.730
นอกจากนี้ยังสามารถใช้ IPS หรือระบบป้องกันการบุกรุกเพื่อระบุและตอบสนองต่อการโจมตีแบบปฏิเสธการให้บริการ

03:35.730 --> 03:38.520
วิธีนี้อาจใช้ได้ดีสำหรับการโจมตีเครือข่ายขนาดเล็ก

03:38.520 --> 03:42.780
แต่จะไม่มีพลังการประมวลผลเพียงพอที่จะรับมือกับการโจมตีขนาดใหญ่อย่างแท้จริง

03:42.780 --> 03:45.060
เช่นเดียวกับที่ Amazon ตกเป็นเป้าหมาย

03:45.060 --> 03:49.140
ตอนนี้หนึ่งในวิธีที่มีประสิทธิภาพที่สุดคือการใช้โครงสร้างพื้นฐานระบบคลาวด์ที่ยืดหยุ่น

03:49.140 --> 03:54.300
เพราะจะช่วยให้คุณขยายขนาดตามความต้องการได้ตามต้องการ ดังนั้นคุณจึงรอดพ้นจากการโจมตีได้

03:54.300 --> 04:00.510
ปัญหาของกลยุทธ์นี้คือผู้ให้บริการส่วนใหญ่จะเรียกเก็บเงินจากคุณตามความสามารถและทรัพยากรที่คุณใช้

04:00.510 --> 04:05.940
เมื่อคุณขยายขนาดขึ้น สิ่งนี้ทำให้เราได้รับใบเรียกเก็บเงินที่มากขึ้นจากผู้ให้บริการระบบคลาวด์ของเรา

04:05.940 --> 04:07.320
และนี่อาจเป็นสิ่งที่เราไม่ได้รับผลตอบแทนจากการลงทุน

04:07.320 --> 04:15.090
เพราะการรับส่งข้อมูลทั้งหมดนั้นไม่ได้สร้างรายได้ให้กับองค์กรของเรา ทั้งหมดเป็นเพียงส่วนหนึ่งของการโจมตี

04:15.090 --> 04:18.750
ที่กล่าวว่า อย่างน้อยคุณก็ยังออนไลน์อยู่เพื่อให้บริการลูกค้าที่ชำระเงินของคุณ

04:18.750 --> 04:22.140
ดังนั้นมันจึงกลายเป็นประเด็นว่าคุณสามารถทนได้นานกว่าที่การโจมตี

04:22.140 --> 04:24.213
DDoS จะดำเนินต่อไปได้หรือไม่