WEBVTT 00:00.090 --> 00:01.020 جيسون: في هذا 00:01.020 --> 00:03.480 الدرس، سنناقش أنواع بروتوكولات 00:03.480 --> 00:05.637 IP، بما في ذلك TCP وUDP ومفاهيم 00:05.637 --> 00:07.650 الطرق غير المتصلة مقابل الأساليب 00:07.650 --> 00:10.020 الموجهة للاتصال. 00:10.020 --> 00:12.300 الآن، ما هو برنامج التعاون الفني؟ 00:12.300 --> 00:15.270 TCP هو بروتوكول التحكم في الإرسال. 00:15.270 --> 00:17.340 إنه بروتوكول موجه نحو الاتصال، 00:17.340 --> 00:18.990 مما يعني أنه وسيلة موثوقة 00:18.990 --> 00:22.080 لنقل القطاعات عبر شبكتنا. 00:22.080 --> 00:23.580 الآن، إذا تم إسقاط مقطع ما، 00:23.580 --> 00:25.770 فسيطلب البروتوكول بالفعل الإقرار 00:25.770 --> 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:36.960 يحتوي على هذا النوع من المعلومات ثنائي الاتجاه 00:36.960 --> 00:38.280 حيث أرسل لك المعلومات وأتحقق 00:38.280 --> 00:40.200 من أنك حصلت عليها بالفعل من خلال الاستماع 00:40.200 --> 00:43.170 إلى أنك حصلت عليها وتعطيني ردًا. 00:43.170 --> 00:44.640 الآن دعونا نلقي نظرة على هذا الرسم البياني 00:44.640 --> 00:46.230 الصغير هنا على الشاشة لثانية واحدة. 00:46.230 --> 00:48.210 سترى أن لدي عميلًا على اليسار 00:48.210 --> 00:49.800 وخادمًا على اليمين. 00:49.800 --> 00:52.860 الآن، سيقوم العميل بإرسال ما يسمى بحزمة المزامنة، 00:52.860 --> 00:54.510 أو حزمة المزامنة، إلى 00:54.510 --> 00:55.950 الخادم. 00:55.950 --> 00:57.240 الآن، عندما يحصل الخادم 00:57.240 --> 00:58.170 على ذلك، فإنه سيرسل 00:58.170 --> 01:00.720 إقرارًا بالمزامنة إلى العميل، يُعرف باسم 01:00.720 --> 01:02.580 إشعار المزامنة. 01:02.580 --> 01:04.740 الآن، عندما يحصل العميل على هذا الإقرار، 01:04.740 --> 01:07.380 فإنه سيرسل إقراره الخاص إلى الخادم. 01:07.380 --> 01:09.060 يُعرف هذا باسم ack. 01:09.060 --> 01:11.940 الآن، عندما نقوم بهذا المزامنة، المزامنة، 01:11.940 --> 01:15.030 ack، هذا ما نشير إليه بالمصافحة الثلاثية. 01:15.030 --> 01:16.807 في الأساس، يقول العميل، "مرحبًا أيها 01:16.807 --> 01:21.367 الخادم، هل أنت مستعد للحصول على بعض المعلومات؟ ثم يقول الخادم: "بالتأكيد. 01:21.367 --> 01:21.367 ولم لا؟ 01:21.367 --> 01:22.920 "أرسل لي بعض المعلومات. ويقول العميل: 01:22.920 --> 01:25.440 "حسنًا، ها هو يأتي. ومن ثم سيبدأ الإرسال لأننا 01:25.440 --> 01:27.630 أنشأنا تلك المصافحة الثلاثية 01:27.630 --> 01:29.940 ونعلم أن كلا الجانبين جاهزان 01:29.940 --> 01:32.737 للتواصل. 01:32.737 --> 01:35.107 "الآن، هل أنت مستعد؟ "نعم أنا. 01:35.107 --> 01:35.107 "هاهي 01:35.107 --> 01:36.810 آتية. الآن في كل مرة يتم فيها 01:36.810 --> 01:39.150 إرسال هذه البيانات، التي نسميها 01:39.150 --> 01:40.710 مقطعًا، عبر الشبكة، 01:40.710 --> 01:43.080 سيكون هناك إقرار تم استلامه ويخبرنا 01:43.080 --> 01:46.980 بوجود اتصال ناجح في الاتجاهين. 01:46.980 --> 01:48.600 الآن، إذا كان هذا الخادم 01:48.600 --> 01:50.370 يتوقع الحصول على 100 معلومة، 01:50.370 --> 01:52.500 لكنه حصل على 98 منها فقط، فسوف يقول 01:52.500 --> 01:53.587 للعميل، "مرحبًا، 01:53.587 --> 01:56.347 لقد أخبرتني أنك سترسل لي 100 شيء،" لكنك أرسلت 01:56.347 --> 01:58.177 لي فقط 98. 01:58.177 --> 02:00.450 "أرسلوني إلى هذين الشيئين اللذين أفتقدهما. وبعد ذلك، تحدث إعادة 02:00.450 --> 02:02.730 الإرسال. 02:02.730 --> 02:03.563 بهذه الطريقة، يمكن 02:03.563 --> 02:05.310 أن يستمر الاتصال بالنسبة لنا ويمكننا 02:05.310 --> 02:06.240 دائمًا التأكد من أننا 02:06.240 --> 02:07.470 نحصل على ما يفترض بنا أن 02:07.470 --> 02:09.450 نحصل عليه لأنه لدينا إعادة إرسال الحزم 02:09.450 --> 02:10.920 عبر الشبكة. 02:10.920 --> 02:13.170 الآن، يتم استخدام هذا لجميع بيانات الشبكة 02:13.170 --> 02:16.830 التي تحتاج إلى التأكد للوصول إلى وجهتها النهائية. 02:16.830 --> 02:19.470 أحب أن أفكر في هذا مثل البريد المعتمد. 02:19.470 --> 02:22.440 إذا كنت أرغب في إرسال رسالة إلى مصلحة الضرائب الأمريكية، على سبيل 02:22.440 --> 02:23.970 المثال، أريد التأكد من حصولهم عليها 02:23.970 --> 02:25.620 وأنها لن تضيع في البريد. 02:25.620 --> 02:27.630 لذلك قد أدفع القليل من المال الإضافي 02:27.630 --> 02:29.160 للحصول على إيصال معتمد، وعندما 02:29.160 --> 02:31.080 يصل هناك، يجب عليهم التوقيع عليه، ويتم 02:31.080 --> 02:32.820 إرساله إليّ بالبريد. 02:32.820 --> 02:33.653 بهذه الطريقة، عندما 02:33.653 --> 02:34.740 أستعيد هذا الإيصال، أعلم 02:34.740 --> 02:37.500 أن مصلحة الضرائب حصلت على طرد البريد الخاص بي. 02:37.500 --> 02:39.960 هذه هي الطريقة التي يعمل بها بروتوكول TCP. 02:39.960 --> 02:41.220 الآن، من ناحية أخرى، 02:41.220 --> 02:44.250 لدينا بروتوكول آخر يعرف باسم UDP. 02:44.250 --> 02:47.250 UDP هو ما نسميه بروتوكول بدون اتصال، مما يعني 02:47.250 --> 02:49.770 أنه لا يحتاج إلى انتظار الاتصالات. 02:49.770 --> 02:52.830 UDP يرمز إلى بروتوكول مخطط بيانات المستخدم. 02:52.830 --> 02:54.270 والسبب في أننا نطلق عليه مخطط 02:54.270 --> 02:56.160 البيانات هو أنه إذا كنت تستخدم UDP، فأنت 02:56.160 --> 02:57.750 تستخدم هذا النوع من البيانات. 02:57.750 --> 02:59.220 يطلق عليه مخطط البيانات. 02:59.220 --> 03:01.317 الآن، عندما نتحدث عن UDP، فإن 03:01.317 --> 03:03.060 UDP غير موثوق به ويقوم بنقل 03:03.060 --> 03:05.490 مقاطع تسمى مخططات البيانات. 03:05.490 --> 03:06.510 وإذا تم إسقاطها، 03:06.510 --> 03:09.000 فلن يعلم المرسل أبدًا بحدوث ذلك. 03:09.000 --> 03:10.830 الآن، لماذا أرغب في إرسال أشياء حيث 03:10.830 --> 03:12.300 لا يكون المرسل على علم بها ولا 03:12.300 --> 03:14.220 أحصل على أي نوع من الإيصال؟ 03:14.220 --> 03:17.850 حسنًا، يعد UDP جيدًا حقًا للبث الصوتي والمرئي لأنك 03:17.850 --> 03:19.920 ترسل الكثير من البيانات ويكون 03:19.920 --> 03:22.620 هناك حمل أقل بكثير عند استخدام UDP، لأننا 03:22.620 --> 03:24.810 لا نملك تلك المصافحة الثلاثية المستمرة 03:24.810 --> 03:25.950 لتأسيسها وليس لدينا 03:25.950 --> 03:27.840 جميع الضوابط والتوازنات المرتبطة 03:27.840 --> 03:30.840 باستخدام TCP. 03:30.840 --> 03:32.520 لذا، باستخدام UDP، يمكنك 03:32.520 --> 03:35.190 حقًا زيادة أداء شبكتك لأنه لن يكون 03:35.190 --> 03:37.800 لديك أي عمليات إعادة إرسال. 03:37.800 --> 03:39.870 سينتهي بك الأمر بإسقاط المعلومات. 03:39.870 --> 03:41.490 الآن، أليس هذا أمرا سيئا؟ 03:41.490 --> 03:43.530 لماذا نريد إسقاط المعلومات؟ 03:43.530 --> 03:45.300 حسنًا، بالنسبة لبعض التطبيقات، 03:45.300 --> 03:46.740 لا يهم حقًا. 03:46.740 --> 03:49.440 على سبيل المثال، أنت تقوم ببث هذا الفيديو الآن. 03:49.440 --> 03:52.110 وإذا تركت الدراسة لمدة 1/100 من الثانية، 03:52.110 --> 03:53.520 هل ستلاحظ ذلك؟ 03:53.520 --> 03:54.960 حسنًا، ربما لن تفعل ذلك، 03:54.960 --> 03:56.820 ولهذا السبب يعد UDP جيدًا جدًا 03:56.820 --> 03:59.520 لأنه يمكننا إسقاط 1/100 من الوقت هنا ولن 03:59.520 --> 04:01.320 تلاحظ ذلك أبدًا، ولن تكون هناك 04:01.320 --> 04:03.120 إعادة إرسال. 04:03.120 --> 04:04.740 لكن مع TCP، سيؤدي ذلك إلى المزيد 04:04.740 --> 04:06.300 من التخزين المؤقت لأنه يتعين 04:06.300 --> 04:07.440 عليك الانتظار، ثم إعادة 04:07.440 --> 04:08.670 إرساله إليك، ثم وضعه في 04:08.670 --> 04:09.810 المكان المناسب، ثم تشغيله 04:09.810 --> 04:11.250 مرة أخرى. 04:11.250 --> 04:13.770 وهكذا، بسبب هذا الاعتراف وهذه النفقات، 04:13.770 --> 04:15.870 لكل ثانية من هذا الفيديو، سينتهي 04:15.870 --> 04:17.880 الأمر بجعله أكبر بكثير واستخدام 04:17.880 --> 04:19.830 نطاق ترددي أكبر بكثير. 04:19.830 --> 04:21.150 وهذا أحد الأسباب الكبيرة 04:21.150 --> 04:24.660 وراء استخدامنا لـ UDP لبث الفيديو والصوت. 04:24.660 --> 04:28.740 الآن، لنقم بعمل ملخص سريع هنا حول TCP مقابل UDP. 04:28.740 --> 04:31.410 لأن هذا مفهوم مهم حقًا. 04:31.410 --> 04:33.600 في الواقع، إذا كانت لديك ملاحظاتك الآن، 04:33.600 --> 04:35.160 أود أن أكتب هذا المخطط الذي 04:35.160 --> 04:36.420 سأخبرك به الآن بينما 04:36.420 --> 04:38.520 نتحدث عن TCP مقابل UDP. 04:38.520 --> 04:40.770 لأنه حقا مهم. 04:40.770 --> 04:43.380 الآن، أولاً، TCP موثوق به، وله مصافحة 04:43.380 --> 04:44.820 ثلاثية، حيث لا يمكن الاعتماد 04:44.820 --> 04:47.040 على UDP بشكل كبير. 04:47.040 --> 04:48.540 إنه بروتوكول غير موثوق 04:48.540 --> 04:51.180 لأنه لا يوجد مصافحة ثلاثية. 04:51.180 --> 04:53.490 TCP هو ما نسميه بروتوكول موجه للاتصال 04:53.490 --> 04:55.560 أو بروتوكول اتصال كامل لأن لدينا 04:55.560 --> 04:57.960 مصافحة ثلاثية الاتجاهات في الإقرارات، 04:57.960 --> 05:00.660 ولكن UDP غير متصل. 05:00.660 --> 05:02.550 إنها طريقة النار والنسيان. 05:02.550 --> 05:04.200 لقد بدأت للتو في إرسال 05:04.200 --> 05:06.660 المعلومات وآمل أن تحصل عليها. 05:06.660 --> 05:10.170 يستخدم TCP إعادة إرسال المقطع والتحكم في التدفق الذي يتم 05:10.170 --> 05:12.030 التعامل معه من خلال النوافذ. 05:12.030 --> 05:13.230 UDP، من ناحية أخرى، 05:13.230 --> 05:16.230 لا يوجد إعادة إرسال ولا نافذة. 05:16.230 --> 05:17.160 باستخدام TCP، 05:17.160 --> 05:19.140 لدينا تجزئة لتسلسلنا لجميع 05:19.140 --> 05:20.820 قطاعاتنا المختلفة. 05:20.820 --> 05:23.370 مع UDP، لا يوجد تسلسل. 05:23.370 --> 05:25.530 الآن، ما يعنيه هذا هو أنني عندما أرسل 05:25.530 --> 05:27.570 كل شيء، سأرسله بالترتيب الصحيح، 05:27.570 --> 05:28.710 من واحد إلى 100. 05:28.710 --> 05:31.260 سأفعل هذا لكل من TCP وUDP. 05:31.260 --> 05:32.910 الآن، إذا فاتتك بعض هذه القطع، 05:32.910 --> 05:34.350 أو وصلت بترتيب مختلف لأنها 05:34.350 --> 05:36.480 تأخذ مسارًا مختلفًا عبر الشبكة، باستخدام 05:36.480 --> 05:37.500 TCP، فإنها تقوم بالتسلسل، 05:37.500 --> 05:38.520 لذلك يعرف أن لديك واحد 05:38.520 --> 05:40.137 إلى 1000 ويعيدها مرة أخرى إلى 05:40.137 --> 05:42.420 التسلسل الصحيح. 05:42.420 --> 05:43.440 مع UDP، مهما كان 05:43.440 --> 05:44.850 شكله، فهذه هي الطريقة 05:44.850 --> 05:46.650 التي سيتم بثه بها. 05:46.650 --> 05:48.030 ومن ثم، يمكن أن تأتي 05:48.030 --> 05:49.230 في واحد، 50، اثنان، 05:49.230 --> 05:50.910 500، ثلاثة، أربعة، 05:50.910 --> 05:55.230 خمسة، ستة، 20، بأي ترتيب عشوائي كهذا. 05:55.230 --> 05:56.580 وهذه هي الطريقة التي ستسمع بها. 05:56.580 --> 05:59.010 لذلك مع الفيديو، قد تسمع القليل من القفز، أو 05:59.010 --> 06:00.780 القليل من الصرير عالي النبرة، أو 06:00.780 --> 06:01.740 شيء من هذا القبيل، 06:01.740 --> 06:04.320 لأن أحد هذه الإطارات ربما خرج عن الترتيب. 06:04.320 --> 06:05.550 الآن، عندما نعود إلى 06:05.550 --> 06:08.010 TCP، سنتعرف على كل جزء من هذه الأجزاء. 06:08.010 --> 06:09.780 وهكذا لدينا الاعتراف. 06:09.780 --> 06:10.680 إذا لم أحصل عليه، 06:10.680 --> 06:11.513 فأنا أعلم أنني 06:11.513 --> 06:13.650 لم أفهمه ويمكنني إعادة إرساله إلي، ثم 06:13.650 --> 06:15.000 الحصول عليه مرة أخرى. 06:15.000 --> 06:17.190 مع UDP، لا يوجد اعتراف. 06:17.190 --> 06:20.220 مرة أخرى، UDP لديه حمل أقل بكثير لأنه 06:20.220 --> 06:21.540 لا يوجد اتصال، 06:21.540 --> 06:23.790 ولا نوافذ، ولا إعادة إرسال، 06:23.790 --> 06:26.610 ولا تسلسل، ولا إقرار. 06:26.610 --> 06:28.620 الآن، إذا كان عليك الحصول على 06:28.620 --> 06:30.870 شيء ما وتريد التأكد من حصول الشخص 06:30.870 --> 06:34.590 عليه، فعليك حقًا استخدام TCP كبروتوكول من اختيارك. 06:34.590 --> 06:36.930 ولهذا السبب سنستخدم بروتوكول TCP لأشياء مثل الخدمات 06:36.930 --> 06:39.510 المصرفية ومواقع الويب والتجارة الإلكترونية وأشياء 06:39.510 --> 06:40.770 من هذا القبيل. 06:40.770 --> 06:42.900 ولكن إذا كان لدينا شيء يحتوي على الكثير 06:42.900 --> 06:44.550 من البيانات مثل تدفق الصوت أو الفيديو، 06:44.550 --> 06:46.560 فإن UDP يعمل بشكل جيد مع ذلك لأننا لا نحتاج 06:46.560 --> 06:47.490 إلى الحصول على كل 06:47.490 --> 06:49.320 جزء من هذا الملف. 06:49.320 --> 06:50.880 يمكننا أن نتخطى قليلاً هنا 06:50.880 --> 06:52.510 وهناك، ولا بأس بذلك. 06:52.510 --> 06:54.570 -: [مدرس آخر] الآن، عندما يتعلق الأمر 06:54.570 --> 06:56.820 بـ TCP وUDP، تحدثنا عن حقيقة أن هذه بروتوكولات 06:56.820 --> 06:58.560 كاملة الاتصال أو موجهة للاتصال، 06:58.560 --> 07:00.510 وبروتوكولات غير متصلة. 07:00.510 --> 07:02.190 لذا اسمحوا لي أن أقدم لكم بعض الأمثلة 07:02.190 --> 07:05.340 على البروتوكولات التي تستخدم إما TCP أو UDP حتى تتمكن 07:05.340 --> 07:07.680 من فهم سبب استخدامنا لكل منهما. 07:07.680 --> 07:08.513 أولاً، دعونا نلقي 07:08.513 --> 07:09.420 نظرة على TCP وبروتوكولاتنا 07:09.420 --> 07:12.750 الموجهة للاتصال أو الاتصال الكامل. 07:12.750 --> 07:17.520 يتضمن ذلك أشياء مثل SSH وHTTP أو HTTPS. 07:17.520 --> 07:20.940 الآن، لماذا نحتاج إلى الاتصال الموجه في هذه الحالات؟ 07:20.940 --> 07:23.490 حسنًا، في حالة استخدام شيء مثل SSH، فأنا أقوم 07:23.490 --> 07:25.710 بإجراء اتصال ثنائي الاتجاه والتحكم في الخادم 07:25.710 --> 07:28.320 البعيد أو محطة العمل البعيدة، وسأكون قادرًا على 07:28.320 --> 07:30.390 القيام بذلك عبر المنفذ 22. 07:30.390 --> 07:31.830 أريد التأكد من أنني أفعل 07:31.830 --> 07:34.920 ذلك بطريقة موجهة نحو الاتصال أو اتصال كامل. 07:34.920 --> 07:37.110 بهذه الطريقة، عندما أرسل أمرًا وأقول، 07:37.110 --> 07:38.190 أعد تشغيل الخادم، 07:38.190 --> 07:40.080 أعلم أن الأمر وصل بالفعل وستتم 07:40.080 --> 07:42.060 إعادة تشغيل الخادم. 07:42.060 --> 07:44.820 وبالمثل، عندما نتعامل مع HTTPS، نريد التأكد 07:44.820 --> 07:46.680 من أن لدينا بروتوكول اتصال كامل 07:46.680 --> 07:50.040 أو بروتوكول موجه للاتصال باستخدام TCP. 07:50.040 --> 07:51.120 والسبب في ذلك هو، مرة 07:51.120 --> 07:52.440 أخرى، أننا نريد التأكد من 07:52.440 --> 07:54.690 أن ما نرسله يتم استلامه بالفعل هناك. 07:54.690 --> 07:56.790 وقد يتضمن ذلك أشياء مثل المصادقة عندما نحاول 07:56.790 --> 07:58.500 تسجيل الدخول إلى موقع ويب باستخدام 07:58.500 --> 08:00.090 اسم المستخدم وكلمة المرور الخاصين 08:00.090 --> 08:01.500 بنا، أو ربما المعلومات التي 08:01.500 --> 08:03.030 نستعيدها من موقع الويب هذا، مثل 08:03.030 --> 08:06.180 أرصدة حساباتنا ومعلوماتنا المصرفية. 08:06.180 --> 08:07.013 الآن، من ناحية 08:07.013 --> 08:08.970 أخرى، إذا كنا نستخدم UDP كبروتوكول 08:08.970 --> 08:11.400 خاص بنا، فإننا نتعامل بطريقة غير متصلة. 08:11.400 --> 08:12.390 لقد ذكرت بالفعل حقيقة 08:12.390 --> 08:13.470 أننا نستخدم هذا طوال 08:13.470 --> 08:15.600 الوقت لأشياء مثل بث الصوت والفيديو. 08:15.600 --> 08:16.680 ولكن بالإضافة إلى 08:16.680 --> 08:19.230 ذلك، فإننا نستخدمه أيضًا لأشياء مثل DHCP، 08:19.230 --> 08:23.130 وبروتوكول نقل الملفات البسيط، المعروف باسم TFTP. 08:23.130 --> 08:24.030 الآن، إذا كنت 08:24.030 --> 08:27.480 تتذكر، يتم استخدام DHCP كبروتوكول التحكم الديناميكي 08:27.480 --> 08:30.660 للمضيف ويعمل عبر المنفذ 67 و68. 08:30.660 --> 08:32.310 الآن، عندما تنضم إلى شبكة، 08:32.310 --> 08:33.690 سيقوم جهازك، إذا تم 08:33.690 --> 08:35.850 إعداده لتعيين ديناميكي لعنوان 08:35.850 --> 08:38.520 IP الخاص به، بإرسال رسالة بث على تلك الشبكة 08:38.520 --> 08:40.650 بحثًا عن خادم DHCP. 08:40.650 --> 08:43.860 ولهذا السبب نستخدمه كبروتوكول بدون اتصال. 08:43.860 --> 08:47.220 لأنه إذا تم إرسال تلك المعلومات ولم يستجب أحد، فسيقوم عميلك 08:47.220 --> 08:49.530 ببساطة بإرسال تلك المعلومات مرة أخرى على 08:49.530 --> 08:51.510 أمل أن يكون هناك شخص آخر هناك. 08:51.510 --> 08:53.070 هذه هي الطريقة التي يعمل بها DHCP. 08:53.070 --> 08:55.080 سيسمح بخروج رسالة البث، 08:55.080 --> 08:57.090 ثم ينتظر عودة الرد. 08:57.090 --> 08:58.170 إذا لم يحصل على هذا 08:58.170 --> 08:59.340 الرد خلال فترة زمنية 08:59.340 --> 09:01.560 معينة، فسوف يقوم ببساطة بإعادة بث رسالته، 09:01.560 --> 09:04.590 ومرة أخرى، يبحث عن خادم DHCP جديد. 09:04.590 --> 09:06.960 الآن، بالمثل، عندما يكون لدينا 09:06.960 --> 09:09.060 TFTP أو بروتوكول نقل الملفات 09:09.060 --> 09:11.250 البسيط، الذي يعمل عبر المنفذ 09:11.250 --> 09:13.380 69، فإنه سيعمل بطريقة غير متصلة 09:13.380 --> 09:15.690 باستخدام UDP كوسيلة نقل. 09:15.690 --> 09:16.680 والسبب في ذلك 09:16.680 --> 09:20.250 هو أن TFTP هو بروتوكول نقل الملفات البسيط، وبالتالي، 09:20.250 --> 09:22.740 لا نحتاج إلى ضمانات بأن كل حزمة تم إرسالها 09:22.740 --> 09:26.250 واستلامها مع تلك الإقرارات، وهذا يخلق الكثير من 09:26.250 --> 09:29.190 الحمل إذا استخدمنا TCP. 09:29.190 --> 09:30.600 لذا، باستخدام UDP، يمكننا 09:30.600 --> 09:32.430 الحصول على نقل أسرع للملفات 09:32.430 --> 09:34.500 عندما نستخدم شيئًا مثل TFTP، بدلاً 09:34.500 --> 09:38.163 من استخدام بروتوكول أكثر اتصالاً، مثل FTP.