WEBVTT

00:00.090 --> 00:01.020
Jason: ในบทนี้

00:01.020 --> 00:03.480
เราจะหารือเกี่ยวกับประเภทโปรโตคอล

00:03.480 --> 00:10.020
IP รวมถึง TCP, UDP และแนวคิดของวิธีการเชื่อมต่อแบบไร้การเชื่อมต่อและแบบเน้นการเชื่อมต่อ

00:10.020 --> 00:12.300
ทีนี้ TCP คืออะไร?

00:12.300 --> 00:15.270
TCP เป็นโปรโตคอลควบคุมการส่ง

00:15.270 --> 00:18.990
เป็นโปรโตคอลที่เน้นการเชื่อมต่อ ซึ่งหมายความว่าเป็นวิธีที่เชื่อถือได้ในการขนส่งส่วนต่างๆ

00:18.990 --> 00:22.080
ทั่วทั้งเครือข่ายของเรา

00:22.080 --> 00:23.580
ตอนนี้หากส่วนใดหลุดออกไป

00:23.580 --> 00:26.603
โปรโตคอลจะขอการยอมรับจริง ๆ ทุกครั้ง

00:26.603 --> 00:28.890
และหากไม่ได้รับการตอบรับ

00:28.890 --> 00:31.530
ก็จะส่งข้อมูลนั้นอีกครั้ง

00:31.530 --> 00:34.410
นั่นเป็นเหตุผลที่เราเรียกสิ่งนี้ว่าโปรโตคอลการเชื่อมต่อเต็มรูปแบบ

00:34.410 --> 00:43.170
เพราะมันมีข้อมูลประเภทสองทางที่ฉันส่งข้อมูลให้คุณและฉันกำลังยืนยันว่าคุณได้รับจริงโดยการฟังว่าคุณได้รับและคุณตอบกลับฉัน

00:43.170 --> 00:44.640
ทีนี้มาดูไดอะแกรมเล็กๆ

00:44.640 --> 00:46.230
บนหน้าจอกันสักครู่

00:46.230 --> 00:49.800
คุณจะเห็นว่าฉันมีไคลเอนต์ทางด้านซ้ายและเซิร์ฟเวอร์ทางด้านขวา

00:49.800 --> 00:55.950
ตอนนี้ไคลเอนต์จะส่งสิ่งที่เรียกว่าแพ็คเก็ตซินหรือแพ็กเก็ตการซิงโครไนซ์ไปยังเซิร์ฟเวอร์

00:55.950 --> 00:58.170
ตอนนี้ เมื่อเซิร์ฟเวอร์ได้รับข้อมูลนั้น

00:58.170 --> 01:00.720
ก็จะส่งการยืนยันการซิงโครไนซ์กลับไปยังไคลเอ็นต์

01:00.720 --> 01:02.580
ซึ่งเรียกว่า syn ack

01:02.580 --> 01:04.740
ตอนนี้ เมื่อไคลเอนต์ได้รับการตอบรับนั้น

01:04.740 --> 01:07.380
ก็จะส่งการตอบรับกลับไปยังเซิร์ฟเวอร์เอง

01:07.380 --> 01:09.060
สิ่งนี้เรียกว่า ack

01:09.060 --> 01:15.030
ทีนี้ เมื่อเราทำ syn นี้ syn ack, ack นี่คือสิ่งที่เราเรียกว่าการจับมือแบบสามทาง

01:15.030 --> 01:19.440
โดยพื้นฐานแล้วลูกค้าจะพูดว่า "เฮ้เซิร์ฟเวอร์คุณพร้อมที่จะรับข้อมูลหรือไม่?

01:19.440 --> 01:19.440
จากนั้นเซิร์ฟเวอร์ก็พูดว่า

01:19.440 --> 01:20.377
"แน่นอน ทำไมจะไม่ล่ะ?

01:20.377 --> 01:22.920
“ส่งข้อมูลให้ฉันหน่อย และลูกค้าก็พูดว่า "เอาล่ะ มาแล้ว จากนั้นการส่งสัญญาณก็จะเริ่มขึ้นเพราะเราได้จับมือกันแบบสามทางแล้ว

01:22.920 --> 01:25.440
และเรารู้ว่าทั้งสองฝ่ายพร้อมที่จะสื่อสารกัน

01:25.440 --> 01:27.630
“เอาล่ะ พร้อมหรือยัง? "ใช่ฉันเป็น “มันมาแล้ว.. ตอนนี้ ทุกครั้งที่ข้อมูลนี้ ซึ่งเราเรียกว่าเซกเมนต์ ถูกส่งไปทั่วเครือข่าย จะมีการรับทราบที่ได้รับ

01:27.630 --> 01:35.107
และนั่นบอกเราว่ามีการสื่อสารสองทางที่ประสบความสำเร็จเกิดขึ้น

01:35.107 --> 01:36.810
ทีนี้ ถ้าเซิร์ฟเวอร์นี้คาดว่าจะได้รับข้อมูล

01:36.810 --> 01:40.710
100 ชิ้น แต่ได้รับเพียง 98 ชิ้น มันจะพูดกับลูกค้าว่า "เฮ้

01:40.710 --> 01:43.080
คุณบอกฉันว่าจะส่งของให้ฉัน 100 ชิ้น"

01:43.080 --> 01:46.980
แต่คุณส่งมาให้ฉันเท่านั้น 98.

01:46.980 --> 01:48.600
“ส่งสองสิ่งที่ฉันขาดหายไปให้ฉัน จากนั้นจึงเกิดการส่งสัญญาณซ้ำ

01:48.600 --> 01:50.370
ด้วยวิธีนี้ การสื่อสารสามารถส่งถึงเราได้

01:50.370 --> 02:00.450
และเราแน่ใจได้เสมอว่าเราได้รับสิ่งที่เราควรจะได้รับ เนื่องจากเรามีการส่งแพ็กเก็ตซ้ำผ่านเครือข่าย

02:00.450 --> 02:03.563
ตอนนี้ใช้สำหรับข้อมูลเครือข่ายทั้งหมดที่ต้องมั่นใจว่าจะไปถึงปลายทางได้

02:03.563 --> 02:05.310
ฉันชอบคิดเรื่องนี้เหมือนจดหมายรับรอง

02:05.310 --> 02:06.240
ตัวอย่างเช่น ถ้าฉันต้องการส่งข้อความถึง

02:06.240 --> 02:09.450
IRS ฉันต้องการให้แน่ใจว่าพวกเขาได้รับข้อความนั้นและไม่สูญหายไปในจดหมาย

02:09.450 --> 02:19.470
ดังนั้นฉันอาจจ่ายเงินเพิ่มเล็กน้อยเพื่อรับใบเสร็จรับเงินที่ได้รับการรับรองซึ่งเมื่อได้รับแล้วพวกเขาต้องเซ็นชื่อและส่งกลับมาให้ฉัน

02:19.470 --> 02:22.440
ด้วยวิธีนี้ เมื่อฉันได้รับใบเสร็จรับเงินคืน

02:22.440 --> 02:25.620
ฉันรู้ว่า IRS ได้รับพัสดุไปรษณีย์ของฉันแล้ว

02:25.620 --> 02:27.630
นั่นคือวิธีการทำงานของ TCP

02:27.630 --> 02:29.160
ในทางกลับกัน เรามีโปรโตคอลอื่นที่เรียกว่า

02:29.160 --> 02:31.080
UDP

02:31.080 --> 02:33.653
UDP คือสิ่งที่เราเรียกว่าโปรโตคอลไร้การเชื่อมต่อ หมายความว่าไม่ต้องรอการเชื่อมต่อ

02:33.653 --> 02:34.740
UDP ย่อมาจาก User Datagram Protocol

02:34.740 --> 02:37.500
และเหตุผลที่เราเรียกมันว่าดาตาแกรมก็เพราะถ้าคุณใช้

02:37.500 --> 02:41.220
UDP คุณกำลังใช้ข้อมูลประเภทนี้

02:41.220 --> 02:44.250
เรียกว่าดาตาแกรม

02:44.250 --> 02:52.830
เมื่อเราพูดถึง UDP UDP นั้นไม่น่าเชื่อถือและจะส่งส่วนที่เรียกว่าดาตาแกรม

02:52.830 --> 02:56.160
และหากตกหล่น ผู้ส่งจะไม่รู้ด้วยซ้ำว่าเกิดขึ้น

02:56.160 --> 02:59.220
ทีนี้ ทำไมฉันถึงต้องการส่งของโดยที่ผู้ส่งไม่รู้จัก

02:59.220 --> 03:01.317
และฉันไม่ได้รับใบเสร็จใดๆ?

03:01.317 --> 03:03.060
UDP นั้นดีจริงๆ สำหรับการสตรีมเสียงและภาพ

03:03.060 --> 03:06.510
เพราะคุณส่งข้อมูลจำนวนมาก และมีค่าใช้จ่ายน้อยลงมากเมื่อคุณใช้

03:06.510 --> 03:09.000
UDP เพราะเราไม่มีการจับมือกันสามทางอย่างต่อเนื่องเพื่อสร้างมันขึ้นมา

03:09.000 --> 03:14.220
และเราไม่มี การตรวจสอบและถ่วงดุลทั้งหมดที่เกี่ยวข้องโดยใช้ TCP

03:14.220 --> 03:17.850
ดังนั้น เมื่อใช้ UDP คุณสามารถเพิ่มประสิทธิภาพของเครือข่ายได้อย่างแท้จริง

03:17.850 --> 03:22.620
เนื่องจากคุณจะไม่มีการส่งข้อมูลซ้ำ

03:22.620 --> 03:24.810
คุณกำลังจะจบลงด้วยการทิ้งข้อมูล

03:24.810 --> 03:25.950
ตอนนี้ไม่ใช่เรื่องเลวร้ายเหรอ?

03:25.950 --> 03:27.840
ทำไมเราถึงต้องการทิ้งข้อมูล?

03:27.840 --> 03:32.520
สำหรับการใช้งานบางอย่าง มันไม่สำคัญจริงๆ

03:32.520 --> 03:35.190
ตัวอย่างเช่น คุณกำลังสตรีมวิดีโอนี้อยู่ในขณะนี้

03:35.190 --> 03:37.800
และถ้าฉันหลุดออกไป 1/100 วินาที

03:37.800 --> 03:39.870
คุณจะสังเกตเห็นไหม

03:39.870 --> 03:41.490
คุณอาจจะไม่ทำ และนั่นคือเหตุผลที่

03:41.490 --> 03:43.530
UDP นั้นดีมาก เพราะเราสามารถลดลง

03:43.530 --> 03:46.740
1/100 ของเวลาที่นี่ และคุณจะไม่สังเกตเห็นเลยด้วยซ้ำ

03:46.740 --> 03:49.440
และจะไม่มีการส่งสัญญาณซ้ำ

03:49.440 --> 03:53.520
แต่ด้วย TCP มันจะนำไปสู่การบัฟเฟอร์ที่มากขึ้น

03:53.520 --> 03:54.960
เพราะคุณต้องรอ

03:54.960 --> 04:01.320
แล้วจึงส่งไปที่ตำแหน่งที่ถูกต้อง แล้วจึงเล่นกลับ

04:01.320 --> 04:03.120
และด้วยเหตุนี้ เนื่องจากการรับทราบและโอเวอร์เฮดนั้น

04:03.120 --> 04:07.440
สำหรับทุกๆ วินาทีของวิดีโอนี้ มันจะทำให้วิดีโอนี้มีขนาดใหญ่ขึ้นมาก และใช้แบนด์วิธมากขึ้น

04:07.440 --> 04:08.670
และนั่นเป็นหนึ่งในเหตุผลสำคัญว่าทำไมเราจึงใช้

04:08.670 --> 04:09.810
UDP สำหรับการสตรีมวิดีโอและการสตรีมเสียง

04:09.810 --> 04:11.250
ตอนนี้เรามาสรุปสั้น ๆ กันที่นี่เกี่ยวกับ TCP กับ UDP

04:11.250 --> 04:13.770
เพราะนี่เป็นแนวคิดที่สำคัญจริงๆ

04:13.770 --> 04:15.870
อันที่จริง ถ้าคุณมีบันทึกย่อของคุณตอนนี้

04:15.870 --> 04:19.830
ฉันจะเขียนแผนภูมินี้ซึ่งฉันจะบอกคุณทันทีเมื่อเราพูดถึง TCP

04:19.830 --> 04:21.150
กับ UDP

04:21.150 --> 04:24.660
เพราะมันสำคัญมากจริงๆ

04:24.660 --> 04:28.740
ประการแรก TCP มีความน่าเชื่อถือ มีการจับมือกันสามทาง

04:28.740 --> 04:33.600
โดยที่ UDP ไม่น่าเชื่อถือมากนัก

04:33.600 --> 04:36.420
เป็นโปรโตคอลที่ไม่น่าเชื่อถือเพราะไม่มีการจับมือกันสามทาง

04:36.420 --> 04:44.820
TCP คือสิ่งที่เราเรียกว่าโปรโตคอลที่เน้นการเชื่อมต่อหรือโปรโตคอลเต็มรูปแบบเนื่องจากเรามีแฮนด์เชคสามทางในการรับทราบ

04:44.820 --> 04:47.040
แต่ UDP นั้นไม่มีการเชื่อมต่อ

04:47.040 --> 04:48.540
เป็นวิธีการจุดไฟและลืม

04:48.540 --> 04:53.490
ฉันเพิ่งเริ่มส่งข้อมูลและหวังว่าคุณจะได้รับมัน

04:53.490 --> 04:56.880
TCP ใช้การส่งสัญญาณซ้ำของเซ็กเมนต์และการควบคุมโฟลว์ซึ่งถูกจัดการผ่านหน้าต่าง

04:56.880 --> 05:00.660
ในทางกลับกัน UDP ไม่มีการส่งสัญญาณซ้ำและไม่มีการปิดหน้าต่าง

05:00.660 --> 05:06.660
ด้วย TCP เรามีการแบ่งส่วนการจัดลำดับของส่วนที่แตกต่างกันทั้งหมดของเรา

05:06.660 --> 05:10.170
ด้วย UDP ไม่มีการเรียงลำดับ

05:10.170 --> 05:12.030
ทีนี้ ความหมายก็คือ เมื่อฉันส่งทุกอย่างออกไป

05:12.030 --> 05:13.230
ฉันจะส่งออกตามลำดับที่เหมาะสม

05:13.230 --> 05:16.230
ตั้งแต่หนึ่งถึง 100

05:16.230 --> 05:17.160
ฉันจะทำสิ่งนี้กับทั้ง TCP และ UDP

05:17.160 --> 05:19.140
ตอนนี้ หากคุณพลาดชิ้นส่วนเหล่านั้นบางส่วน

05:19.140 --> 05:20.820
หรือมาถึงลำดับที่แตกต่างกัน

05:20.820 --> 05:23.370
เนื่องจากใช้เส้นทางที่แตกต่างกันบนเครือข่าย

05:23.370 --> 05:28.710
ด้วย TCP พวกมันกำลังจัดลำดับ ดังนั้นมันจึงรู้ว่าคุณมี 1 ถึง 1,000 และนำพวกมันกลับมาอยู่ใน

05:28.710 --> 05:31.260
ลำดับที่ถูกต้อง

05:31.260 --> 05:34.350
ด้วย UDP ไม่ว่าพวกเขาจะมาในรูปแบบใด

05:34.350 --> 05:36.480
นั่นคือวิธีการถ่ายทอด

05:36.480 --> 05:38.520
ดังนั้น มันอาจจะมาในหนึ่ง 50 สอง 500

05:38.520 --> 05:43.440
สาม สี่ ห้า หก 20 ตามลำดับแบบสุ่มแบบนั้น

05:43.440 --> 05:44.850
และนั่นคือวิธีที่คุณจะได้ยิน

05:44.850 --> 05:46.650
ดังนั้นสำหรับวิดีโอ คุณอาจได้ยินเสียงกระโดดเล็กน้อย

05:46.650 --> 05:48.030
หรือเสียงแหลมสูงเล็กน้อย หรืออะไรทำนองนั้น

05:48.030 --> 05:50.910
เพราะหนึ่งในเฟรมเหล่านั้นอาจไม่เป็นระเบียบ

05:50.910 --> 05:55.230
ตอนนี้ เมื่อเรากลับไปที่ TCP มันจะรับทราบแต่ละส่วนเหล่านั้น

05:55.230 --> 05:56.580
ดังนั้นเราจึงได้รับการยอมรับ

05:56.580 --> 05:59.010
ถ้าฉันไม่เข้าใจ ฉันรู้ว่าฉันไม่เข้าใจ

05:59.010 --> 06:04.320
และฉันสามารถส่งซ้ำให้ฉันได้ แล้วจึงรับอีกครั้ง

06:04.320 --> 06:05.550
ด้วย UDP ไม่มีการรับทราบ

06:05.550 --> 06:08.010
อีกครั้ง UDP มีค่าใช้จ่ายน้อยกว่ามาก เนื่องจากไม่มีการเชื่อมต่อ

06:08.010 --> 06:09.780
ไม่มีหน้าต่าง ไม่มีการส่งซ้ำ ไม่มีการจัดลำดับ

06:09.780 --> 06:11.513
และไม่มีการตอบรับ

06:11.513 --> 06:15.000
ตอนนี้ ถ้าคุณต้องได้รับบางสิ่งที่นั่น และคุณต้องการให้แน่ใจว่าบุคคลนั้นได้รับ

06:15.000 --> 06:17.190
คุณต้องใช้ TCP เป็นโปรโตคอลที่คุณเลือก

06:17.190 --> 06:20.220
และนั่นคือเหตุผลที่เราจะใช้ TCP สำหรับสิ่งต่าง ๆ เช่น

06:20.220 --> 06:21.540
การธนาคารและเว็บไซต์

06:21.540 --> 06:23.790
และอีคอมเมิร์ซ และอื่น ๆ เช่นนั้น

06:23.790 --> 06:26.610
แต่ถ้าเรามีบางอย่างที่มีข้อมูลจำนวนมาก เช่น

06:26.610 --> 06:36.930
การสตรีมเสียงหรือวิดีโอ UDP ก็ทำได้ดีเพราะเราไม่จำเป็นต้องได้รับไฟล์ทุกส่วน

06:36.930 --> 06:40.770
เราข้ามตรงนี้ไปตรงนั้นได้นิดหน่อยก็ไม่เป็นไร

06:40.770 --> 06:44.550
-: [ผู้สอนอีกคน] ตอนนี้ เมื่อพูดถึง TCP และ UDP เราได้พูดถึงความจริงที่ว่าสิ่งเหล่านี้คือโปรโตคอลที่เน้นการเชื่อมต่อเต็มรูปแบบหรือที่เน้นการเชื่อมต่อ

06:44.550 --> 06:47.490
และโปรโตคอลที่ไม่มีการเชื่อมต่อ

06:47.490 --> 06:49.320
ผมขอยกตัวอย่างโปรโตคอลที่ใช้ TCP หรือ

06:49.320 --> 06:52.510
UDP เพื่อให้คุณเข้าใจว่าเหตุใดเราจึงใช้แต่ละโปรโตคอล

06:52.510 --> 06:58.560
ก่อนอื่น มาดู TCP และโปรโตคอลที่เน้นการเชื่อมต่อหรือการเชื่อมต่อแบบเต็ม

06:58.560 --> 07:00.510
ซึ่งรวมถึงสิ่งต่างๆ เช่น SSH และ HTTP หรือ HTTPS

07:00.510 --> 07:02.190
เหตุใดเราจึงต้องการการเชื่อมต่อที่มุ่งเน้นในกรณีเหล่านี้

07:02.190 --> 07:07.680
ในกรณีของการใช้บางอย่างเช่น SSH ฉันกำลังทำการสื่อสารสองทางและควบคุมเซิร์ฟเวอร์ระยะไกลหรือเวิร์กสเตชันระยะไกล

07:07.680 --> 07:08.513
และสามารถทำได้ผ่านพอร์ต

07:08.513 --> 07:09.420
22

07:09.420 --> 07:17.520
ฉันต้องการให้แน่ใจว่าฉันกำลังทำอย่างนั้นในลักษณะที่มุ่งเน้นการเชื่อมต่อหรือการเชื่อมต่อเต็มรูปแบบ

07:17.520 --> 07:20.940
ด้วยวิธีนี้ เมื่อฉันส่งคำสั่งและพูดว่า รีบูตเซิร์ฟเวอร์

07:20.940 --> 07:23.490
ฉันรู้ว่าคำสั่งนั้นไปถึงที่นั่นจริง

07:23.490 --> 07:28.320
ๆ และการรีบูตเซิร์ฟเวอร์จะเกิดขึ้น

07:28.320 --> 07:31.830
ในทำนองเดียวกัน เมื่อเราจัดการกับ HTTPS เราต้องการให้แน่ใจว่าเรากำลังมีโปรโตคอลการเชื่อมต่อแบบเต็มหรือเน้นการเชื่อมต่อโดยใช้

07:31.830 --> 07:34.920
TCP

07:34.920 --> 07:40.080
เหตุผลก็คือเราต้องการให้แน่ใจว่าสิ่งที่เราส่งไปนั้นได้รับจริง

07:40.080 --> 07:42.060
และนั่นอาจรวมถึงสิ่งต่างๆ เช่น การพิสูจน์ตัวตน

07:42.060 --> 07:46.680
เมื่อเราพยายามเข้าสู่ระบบเว็บไซต์โดยใช้ชื่อผู้ใช้และรหัสผ่านของเรา หรืออาจเป็นข้อมูลที่เราได้รับกลับมาจากเว็บไซต์นั้น

07:46.680 --> 07:52.440
เช่น ยอดคงเหลือในบัญชีและข้อมูลธนาคารของเรา

07:52.440 --> 07:54.690
ในทางกลับกัน หากเราใช้ UDP เป็นโปรโตคอล

07:54.690 --> 07:58.500
เรากำลังติดต่อในลักษณะที่ไร้การเชื่อมต่อ

07:58.500 --> 08:01.500
ตอนนี้ ฉันได้พูดถึงข้อเท็จจริงที่ว่าเราใช้สิ่งนี้ตลอดเวลาสำหรับสิ่งต่างๆ

08:01.500 --> 08:03.030
เช่น การสตรีมเสียงและวิดีโอ

08:03.030 --> 08:07.013
แต่นอกเหนือจากนั้น เรายังใช้มันสำหรับ DHCP และโปรโตคอลการถ่ายโอนไฟล์เล็กน้อยที่เรียกว่า

08:07.013 --> 08:08.970
TFTP

08:08.970 --> 08:11.400
ตอนนี้ หากคุณจำได้ DHCP ถูกใช้เป็น Dynamic Host Control

08:11.400 --> 08:12.390
Protocol และทำงานผ่านพอร์ต

08:12.390 --> 08:13.470
67 และ 68

08:13.470 --> 08:16.680
ตอนนี้ เมื่อคุณเข้าร่วมเครือข่าย

08:16.680 --> 08:19.230
หากอุปกรณ์ของคุณได้รับการตั้งค่าสำหรับการกำหนดที่อยู่

08:19.230 --> 08:23.130
IP แบบไดนามิก ก็จะส่งข้อความออกอากาศบนเครือข่ายนั้นเพื่อค้นหาเซิร์ฟเวอร์

08:23.130 --> 08:24.030
DHCP

08:24.030 --> 08:27.480
และนี่คือเหตุผลที่เราใช้มันเป็นโปรโตคอลไร้การเชื่อมต่อ

08:27.480 --> 08:33.690
เพราะหากข้อมูลนั้นถูกส่งออกไปและไม่มีใครตอบกลับ ลูกค้าของคุณก็จะส่งข้อมูลนั้นออกไปอีกครั้งโดยหวังว่าจะมีคนอื่นอยู่ที่นั่น

08:33.690 --> 08:35.850
นั่นคือวิธีการทำงานของ DHCP

08:35.850 --> 08:38.520
มันจะอนุญาตให้ข้อความออกอากาศออกไป

08:38.520 --> 08:40.650
จากนั้นรอการตอบกลับกลับมา

08:40.650 --> 08:43.860
หากไม่ได้รับการตอบกลับภายในระยะเวลาหนึ่ง

08:43.860 --> 08:51.510
ก็จะออกอากาศข้อความซ้ำ และค้นหาเซิร์ฟเวอร์ DHCP ใหม่อีกครั้ง

08:51.510 --> 08:53.070
ในทำนองเดียวกัน เมื่อเรามี TFTP หรือ Trivial File

08:53.070 --> 08:58.170
Transfer Protocol ซึ่งทำงานผ่านพอร์ต 69 ก็จะทำงานในลักษณะที่ไม่มีการเชื่อมต่อโดยใช้

08:58.170 --> 08:59.340
UDP เป็นการขนส่ง

08:59.340 --> 09:01.560
เหตุผลนี้เป็นเพราะ TFTP เป็นโปรโตคอลการถ่ายโอนไฟล์เล็กน้อย

09:01.560 --> 09:09.060
ดังนั้นเราจึงไม่จำเป็นต้องมีการรับรองว่าทุกแพ็กเก็ตถูกส่งและรับด้วยการตอบรับเหล่านั้น

09:09.060 --> 09:11.250
และนั่นจะสร้างโอเวอร์เฮดมากขึ้นหากเราใช้

09:11.250 --> 09:13.380
TCP

09:13.380 --> 09:16.680
ดังนั้น เมื่อใช้ UDP เราสามารถถ่ายโอนไฟล์ได้เร็วขึ้นเมื่อเราใช้บางอย่าง

09:16.680 --> 09:22.740
เช่น TFTP แทนที่จะใช้โปรโตคอลที่มีการเชื่อมต่อเต็มรูปแบบ เช่น FTP