دليل UDP (بروتوكول مخطط بيانات المستخدم)

يشبه بروتوكول مخطط بيانات المستخدم “هانجي كريستيان أندرسن” “البطة القبيحة”. بعد عقود من الإهمال والسخرية ، اجتذب هذا البروتوكول البسيط المعجبين فجأة كبروتوكول نقل لتطبيقات الوسائط المتعددة الجديدة والرائعة التي أصبحت ممكنة بفضل سرعات النطاق العريض. اليوم ، أي تطبيق يحتاج إلى تسليم البيانات يختار UDP بسرعة عبر بروتوكول TCP (بروتوكول التحكم في الإرسال)..

تاريخ UDP

UDP موجودة منذ ما يقرب من الإنترنت. ظهرت شبكة الإنترنت في مايو عام 1974 عندما نشر معهد مهندسي الكهرباء والإلكترونيات “برنامج لشبكة حزم الاتصالات” بواسطة فينت سيرف و بوب خان. يجب تطوير المفهوم واستمر كل من خان وسيرف في تحسين أفكارهما أثناء العمل لصالح حكومة الولايات المتحدة وكالة المشاريع البحثية الدفاعية المتقدمة, والذي يعرف أيضًا باسم DARPA. جون بوستيل التورط واقترح تقسيم الهيكل الفردي المقترح في فكرة سيرف وخان الأصلية. هذا خلق مفهوم الطبقات. تم تقسيم برنامج التحكم في الإرسال الأصلي المتضمن في مخطط عام 1974 إلى بروتوكول التحكم في الإرسال في طبقة أعلى وبروتوكول الإنترنت في طبقة أقل (وبالتالي TCP / IP).

لقد كان نهج Postel المعياري منطقيًا عندما بدأ الفريق في التفكير في تطبيق النظرية. كان هناك تقسيم واضح للعمل بين ما أصبح يعرف باسم طبقة النقل, وهو موقع بروتوكول التحكم في الإرسال طبقة الإنترنت, حيث يوجد بروتوكول الإنترنت. ومع ذلك ، تصور Cerf و Khan الحاجة إلى خيار التتبع السريع. لقد وضعوا رسم تخطيطي لكيفية إعداد البيانات للإرسال من خلال تمريرها من طبقة إلى أخرى. تم تمثيل مهام المعالجة كخط عمودي مستقيم ، تنازليًا من خلال مخطط المكدس الجديد الذي يوضح التقدم من تطبيق ل TCP وعلى IP.

عندما يتعلق الأمر بالرسم في المسار السريع ، لم يرغبوا في رسم خط تحويلي منحني تجنب المرور عبر TCP. بدلاً من ذلك ، فقد رسموا شكلًا مستطيلًا يمثل طبقة الإنترنت أوسع قليلاً من الكتلة التي تمثل طبقة النقل. من خلال هذا التعديل البصري ، يمكن أن ينحدر كل من المسار العادي ومسار المسار السريع عبر الرصة كخطوط متوازية. ومع ذلك ، تركت هذه الخدعة فجوة شعرت أن Postel بحاجة إلى سدها. هذا هو السبب في اختراع بروتوكول مخطط بيانات المستخدم. كان هناك فقط لجعل مخطط مكدس البروتوكول تبدو متوازنة.

فوائد TCP

يوفر بروتوكول التحكم في الإرسال خدمات أساسية للبيانات أثناء النقل. إنه يضمن وصول جميع الحزم في الدفق فعليًا والتحقق من وصولها بالترتيب. إجراءات الرقابة التي تضمن النقل المنظم غير ممكنة بدون إجراء التنسيق بين الجانبين. لذلك ، ينشئ TCP أولاً اتفاقًا بين الجهازين اللذين ينويان تبادل البيانات. هذا الاتفاق يسمى جلسة. إنه أيضًا تعريف “الإتصال.”لا يوجد لدى UDP إجراءات لتأسيس الجلسة وبالتالي يطلق عليها”بدون اتصال.”

توفر الجلسة لكلا جانبي الاتصال رقمًا مرجعيًا يمكنهم وضع علامة عليه في التبادلات الإدارية الخاصة بهم. تتيح الجلسة أيضًا تقديم مفهوم المنافذ. معرف الجلسة هو في الواقع مزيج من المعرفات المضمنة في رأس TCP. باستخدام هذا المعرف ، تمكن مصممو إجراءات TCP من التوصل إلى فكرة “قابس كهرباء.”يتم تخصيص أرقام المنافذ أيضًا لـ UDP ، ومع ذلك ، لا يمكن لهذا البروتوكول استخدام عنوان IP المقصود وأرقام المنافذ كمعرف فريد. من شأن المعرف المستمد من هذه المجموعة أن يحظر جميع العمليات الأخرى التي تحاول الوصول إلى نفس المنفذ ، على الرغم من أنها كانت تعمل على أجهزة كمبيوتر مختلفة ، لذلك تم إنشاء UDP نظام تسليم فقط ، مع عدم وجود إجراءات لتمكين الحوار في اتجاهين.

تم تطوير جميع مفاهيم اتصال TCP إلى طريقة عالمية متطورة للغاية لضمان عدم خلط البيانات التي تمر بين أجهزة الكمبيوتر أو تشويشها. مكّن المقبس من فتح اتصالات متعددة بين نفس جهازي الكمبيوتر في وقت واحد. خلقت هذه الفكرة إمكانية تشغيل أكثر من قناة واحدة لتمرير البيانات. هذا إجراء شائع الاستخدام واستفادت منه العديد من تطبيقات الشبكة المبكرة. ال بروتوكول نقل الملفات, على سبيل المثال ، يستخدم قناتين: واحدة لتمرير البيانات وقناة منفصلة للاتصالات الإدارية. تخلق أرقام المنافذ المختلفة لقنوات البيانات والتحكم مآخذين متميزين.

يعني المعرف الفريد لكل جلسة أن TCP أضاف قيمة إلى الاتصال بين جهازي كمبيوتر. في أواخر السبعينيات وأوائل الثمانينيات ، كان لدى المؤسسات والمؤسسات الأكاديمية الكبرى أجهزة كمبيوتر وشبكات فقط. لذلك ، كان من المحتمل جدًا أن تحتاج منظمتان إلى حواسبها الكبيرة الكبيرة للاتصال ببعضها البعض في وقت واحد لأغراض مختلفة. بينما كان الأستاذ يرسل ملفًا إلى زميل في جامعة أخرى ، قد يرغب الباحث أيضًا في فتح جلسة Telnet على الكمبيوتر في الجامعة البعيدة نفسها. بفضل TCP ، يمكن لجهازي كمبيوتر الحفاظ على العديد من الاتصالات في وقت واحد ويمكن لكل من تلك الجلسات تشغيل عدة قنوات في نفس الوقت. لن تكون هذه الاتصالات المتزامنة ممكنة إذا كانت الاتصالات محكومة فقط ببروتوكول الإنترنت مع تخصيص عنوان IP واحد لكل كمبيوتر. UDP ، بدون أي آلية للجلسة ، كان غير قادر على إدارة التطبيقات التي تتطلب جهاز كمبيوتر تم الاتصال به لإرسال استجابة.

أمن البيانات

جعلت التركيبات الرائعة لبرنامج التعاون الفني الاتصالات بين الشبكات ممكنة وبدأ الإنترنت في التوسع إلى ما وراء الأوساط الأكاديمية إلى عالم الأعمال. إنشاء شبكة الانترنت, الذي أصبح عامًا عام 1991 كان ممكنًا فقط بسبب السهولة التي يمكن بها لصفحة الويب التي تحمل بروتوكول نقل النص التشعبي (HTTP) أن توضع فوق TCP.

كان الأكاديميون والفنيون الذين وضعوا الإنترنت معًا ثم قاموا بتطوير شبكة الويب العالمية المتاحة للجمهور سماء زرقاء مفكرين. لقد كانوا متحمسين للتكنولوجيا وإمكانياتها لتسريع البحث وتحسين التفاعل بين الناس في جميع أنحاء العالم. لقد فشلوا في تفسير حقيقة أن اختراعهم الرائع كان بمثابة هدية للسارقين والفنانين والإرهابيين الحضريين. لا الإنترنت ولا شبكة الويب العالمية لديها أي أمان على الإطلاق.

استغرق الأمر بقيادة المستهلك شركة نتسكيب لاكتشاف هذه المشكلة. أنتج Netscape متصفح الويب الرائد في العالم وأبعده مجانًا للتشجيع على استيعاب الإنترنت بين عامة الناس. تم تنفيذ الخطة وتبادل المعلومات وقنوات الاتصال ، مما شجع المزيد من أفراد الجمهور على الاشتراك في خدمات الإنترنت. ومع ذلك ، فإن يمثل الافتقار إلى الأمن عائقًا أمام تسويق الويب. بدون القدرة على تحفيز الأفراد على الدفع مقابل الخدمات عبر الإنترنت ، لم يكن هناك حافز للشركات للاستثمار في تطوير تطبيقات جديدة أو مواقع ويب أو خدمات عبر الإنترنت.

كان العائق الرئيسي أمام تحصيل المدفوعات عبر الويب هو افتقارها إلى الأمان. أغلقت بعض العناوين الرئيسية حول سرقة البيانات على عمليات نقل الإنترنت إمكانية جعل الإنترنت قابلاً للتطبيق من الناحية التجارية. ومع ذلك, جاء نتسكيب مع HTTPS – نسخة آمنة من HTTP التي تحمي الإرسال. كان الموقع المثالي في مكدس TCP / IP لإجراءات الأمان هذه أثناء عمليات إنشاء جلسة TCP. وبالتالي, أصبح TCP أكثر أهمية لعمليات الإنترنت وبدا أنه من المحتمل ألا يتم استخدام UDP.

UDP تقلع

على الرغم من وجودها منذ عام 1980, تم تجاهل UDP بالكامل حتى أصبحت خدمات الإنترنت ذات النطاق العريض متاحة في بداية هذا القرن. تم تجاهل بروتوكول مخطط بيانات المستخدم إلى حد كبير بينما توسعت تطبيقات الويب وتطبيقات الإنترنت الأخرى على وظائف TCP.

ومع ذلك, إن القدرة على إجراء محادثات صوتية وعقد مؤتمرات فيديو عبر الإنترنت لطالما جذبت الشركات. كانت هذه التطبيقات موجودة قبل النطاق العريض ، ولكن فقط للاستخدام على شبكات خاصة أسرع. مع تكنولوجيا تمرير الصوت والفيديو عبر الشبكات المعمول بها, أتاحت سرعات النطاق العريض الأسرع إمكانية إتاحة هذه التطبيقات لعامة الناس أصبحت فكرة مجدية. ومع ذلك ، فإن السرعات المتاحة عبر الإنترنت لم تكن جيدة بما فيه الكفاية.

كان الحل الفوري للضغط على سرعة إضافية كافية من الإنترنت هو التخلص من جميع الإجراءات الإدارية لبرنامج التعاون الفني و أنتقل إلى UDP طي النسيان.

مشاكل مع TCP

تفضل التطبيقات التفاعلية التعامل مع بعض المشكلات التي واجهتها أثناء الإرسال. إحدى الميزات الرئيسية لبرنامج التعاون الفني التي لا تريدها هذه التطبيقات حقًا هي التخزين المؤقت.

يتأكد TCP من وصول الحزم بالتسلسل. إذا كانت الحزمة مفقودة من الدفق, سيرسل تطبيق TCP المتلقي طلبًا إلى برنامج TCP المرسل لإعادة إرسال هذه الحزمة المحددة. في غضون ذلك ، قد تصل هذه الحزمة متأخرة. يستخدم TCP نظام إطار انزلاقي لمعالجة الحزم القادمة وإذا كانت شريحة متأخرة أو مفقودة ، فإن هذه الشريحة تتكدس. التخزين المؤقت لعدد من الإطارات في الذاكرة هو ما يعرف التخزين المؤقت. ينتظر TCP حتى يتمكن من ملء الفتحة الفارغة مع الحزمة التي تحمل رقم التسلسل المفقود. في حالة الاتصال الهاتفي عبر الإنترنت ، فإن مثل هذا الإجراء من شأنه أن يجعل الخط يصمت. في دفق الفيديو ، يؤدي الانتظار لحزم مفقودة إلى تجميد مشغل الفيديو.

لا تحتوي التطبيقات التفاعلية على إجراءات للتغلب على التخزين المؤقت لـ TCP. السبب الأساسي وراء طبقات الرصة هو أن الطبقات العليا تطلب خدمة وتتركها للطبقة السفلية لتوفيرها. لا توجد إشارة “متابعة” يمكن أن يرسلها التطبيق إلى طبقة النقل.

في حالة فقد حزمة في محادثة هاتفية رقمية ، فإن المتصلين سوف يواجهون صمتًا قصيرًا ، ولكن التطبيق على كلا الجانبين سوف يستمر فقط ويستمر في إرسال واستقبال الحزم التالية. بحلول الوقت الذي يمكن فيه استرداد حزمة مفقودة ، كانت المحادثة التفاعلية قد انتقلت بالفعل ، لذلك لا جدوى من محاولة ضخها مرة أخرى في البث. من الأفضل شطب الخسارة والاستمرار في ذلك. وبالمثل ، فإن الرزمة المفقودة تعني مجرد تخطي قصير في دفق فيديو مباشر وأن المشاهدين يفضلون أن يظل الفيديو يتحرك للأمام بدلاً من الضغط على قطعة الأرض لملي ثانية واحدة من الإطارات.

ربما تكون قد شاهدت مشغل فيديو مؤقتًا وتراكب الرسالة “التخزين المؤقت“فوق الصورة. عادة ما يكون هناك أيضًا عداد يوضح نسبة التخزين المؤقت التي تم إكمالها. يحدث هذا التخزين المؤقت إذا كانت سرعة نقل الاتصال أبطأ من معدل الإطارات لتشغيل الفيديو. لكن النقطة الأساسية في تلك الرسالة هي أنها توضح أن التخزين المؤقت تتم إدارته بواسطة المشغل وليس بواسطة بروتوكول النقل.

بروتوكولات الشراكة

على الرغم من أن التطبيق التفاعلي لا يريد التأخير الناجم عن TCP ، إلا أنه يريد بعض وظائف ذلك البروتوكول. أرادوا أكثر من UDP يمكن أن توفر. لذا اخترعت بروتوكولات أخرى لملء أجزاء من قدرات TCP.

بروتوكول بدء الجلسة

تم اختراع بروتوكول بدء الجلسة (SIP) لتطبيقات الصوت عبر بروتوكول الإنترنت (VoIP). لم تكن المهاتفة عبر الإنترنت تريد التخزين المؤقت لـ TCP ، لكنها كانت بحاجة إلى محاكاة إجراءات إنشاء المكالمات التقليدية للهواتف – الاتصال الهاتفي ، رنين ، مشغول ، التقاط ، وإنهاء المكالمة. ومع ذلك ، لا تدير SIP الجلسة بأكملها ، ولكنها تهتم فقط بوظائف إنشاء الاتصال و teardown لبروتوكول TCP. كل مكالمة يتم تشغيلها عبر الإنترنت تستخدم SIP. لدرجة أن “SIP” أصبح تقريبًا عبارة قابلة للتبديل مع “الصوت عبر بروتوكول الإنترنت.”

تشغيل حركة الصوت عبر الاتصالات الرقمية عالية السرعة بكميات كبيرة يُعرف باسم “SIP الكابلات.”تحويل مكالمة من الإنترنت إلى هاتف أرضي منتظم يسمى”إنهاء SIP.تستخدم صناعة الاتصالات الهاتفية الرقمية SIP لتحديد تكنولوجيتها ، ولكن الأساس لجميع أنشطتها هو UDP.

بروتوكول النقل في الوقت الحقيقي

على الرغم من القرار الذي مفاده أن TCP كان أكثر من اللازم على الحمل التفاعلي ويجب التخلص منه, استمر مهندسو الاتصالات في العودة إلى المرافق التي يوفرها برنامج التعاون الفني وتمنوا أن يتمكنوا من الحصول عليها مع UDP. يعوض بروتوكول النقل في الوقت الحقيقي (RTP) الكثير من النقص في الوظائف التي تحدث عند استخدام UDP.

من السمات الرئيسية لهذه البروتوكولات الإضافية التي تجعل UDP ذات صلة ببث الوسائط هي أنها تسمح ببعض العمليات التي تتم إدارتها تقليديًا بواسطة TCP لرفعها إلى التطبيق. يعالج RTP بعض وظائف إدارة حركة المرور الخاصة بـ TCP ، ولكن ليس جميعها.

RTP قادر على إعادة ترتيب خارج حزم التسلسل ولاحظ الحزم المفقودة. ومع ذلك ، لا يلزم تنفيذ وظيفة التسلسل ومن المستحيل تنفيذها دون تخزين مؤقت في طبقة النقل.

بروتوكول التحكم RTP

شركاء RTP دائمًا مع RTCP, وهو بروتوكول التحكم RTP. يحاكي RTPC بعض وظائف إدارة جلسة TCP ، باستثناء المبدأ التوجيهي للبروتوكول وهو عدم التدخل في البث وعدم إبطاء إرسال الوسائط ؛ لذلك أنشطتها نادرة. سيقوم البروتوكول بجمع بيانات الأداء ، بما في ذلك فقدان الحزمة, ونقل معدل المعلومات. يمكن لمشغل الاستقبال استخدام هذه المعلومات لتحديد ما إذا كان يجب التبديل إلى دقة فيديو منخفضة أو معيار ترميز فيديو مختلف.

إذا كنت تستخدم تطبيق فيديو وصوت ، فمن شبه المؤكد أن كلا من RTP و RTCP مشتركان. هناك “التداخل“خيار في تعريف RTSP (انظر أدناه) والذي من شأنه أن ينقل إرسالات RTP على TCP. ومع ذلك ، هذا اقتراح غير عادي لم يتم تنفيذه مطلقًا خارج المعمل. بدون هذا المواصفات ، يتم تنفيذ جميع أنشطة RTP و RTCP بواسطة UDP.

في الوقت الحقيقي بروتوكول التدفق

إن بروتوكول Real Time Streaming Protocol (RTSP) يشارك دائمًا في تطبيقات تشغيل الفيديو والصوت أو التسجيل. يوفر هذا البروتوكول أزرار التحكم في المشغل والمسجل. هذه هي الإيقاف المؤقت ، التسجيل / التشغيل ، التقديم السريع ، الترجيع. الغريب ، على الرغم من أن RTSP يمكن تشغيله عبر UDP ، إلا أنه يتم نقله عادة عبر TCP ، على الرغم من أنه شراكة مع دفق الفيديو أو الصوت المدعوم من UDP.

تطبيقات UDP فقط

يستخدم عدد من التطبيقات التي تدعم الشبكات خفيفة الوزن UDP دون أي بروتوكولات أخرى تشكل محاكاة لوظائف TCP. هذه الوظائف مخصصة تقريبًا للاستخدام فقط على الشبكات الخاصة لأنها لا تشمل أي إجراءات المصادقة أو تشفير الإرسال.

إذا كنت تدير شبكة ، فستكون على دراية بـ بروتوكول وقت الشبكة (NTP), ال نظام اسم المجال (DNS), ال بروتوكول تكوين المضيف الحيوي (DHCP), و ال بروتوكول نقل الملفات التافهة (TFTP). جميع هذه الخدمات الإدارية تعمل على UDP. خارج تطبيقات الشبكة الخاصة هذه ، من الصعب جدًا العثور على أي تطبيق يتم تشغيله فقط عبر UDP.

UDP مقابل TCP

توضح لك مقارنة بنية رأس UDP وهيكل رأس TCP حدود UDP.

يحتوي رأس UDP على أربعة حقول فقط. من هؤلاء الأربعة ، و منفذ المصدر الحقل اختياري ويمكن تركه فارغًا. في IPv4 ، اختباري الحقل اختياري أيضًا ، على الرغم من أنه إلزامي لتطبيقات IPv6. هذا يعني أنه في حالة إرسال IPv4 ، لا يحتاج رأس UDP إلا إلى جزأين من المعلومات فيه.

رأس TCP قادر على حمل الكثير من المعلومات.

كما ترون من الرسم التوضيحي ، يحتوي رأس حزمة TCP على سلسلة من تسعة أعلام تتكيف مع معنى الرأس. يحتوي الحدث على حقل “عاجل”. هذا يمنح نظام TCP مرونة أكبر بكثير من UDP ويظهر أنه تم استثمار الكثير من الوقت في إجراءات TCP وهيكل رأس الحزمة الخاص به أكثر مما تم إنفاقه على تطوير UDP.

حقيقة أن رأس TCP يجب أن يتضمن المنفذ المصدر يجعل من الممكن إنشاء مقبس فريد أكثر ، وإنشاء معرف جلسة من عناوين IP للمصدر والوجهة وأرقام منافذ المصدر والوجهة. باستخدام UDP ، لأنه لا يوجد لديه إجراءات لإنشاء جلسة, يتم التعامل مع كل رسالة كمهمة مكتملة, ولا يحاول البروتوكول تجميع الحزم معًا. لذلك ، يجب أن تقوم التطبيقات التي تستخدم USP بإدارة تلك الاستمرارية نفسها.

الأمن ل UDP

تجعل أساليب TCP الموجهة للتوصيل الأمن أسهل بكثير في تنفيذ ذلك البروتوكول في UDP. ومع ذلك ، هناك معايير التشفير المتاحة ل UDP. الخيار الرئيسي الذي يهدف مباشرة إلى الأمن UDP هو بروتوكول أمن طبقة النقل Datagram أو DTLS.

لحسن الحظ, DTLS متاح في عدد من المكتبات المجانية مفتوحة المصدر, لذلك لا تحتاج إلى التمشيط من خلال تعريف البروتوكول وكتابة البرنامج المفتوح الخاص بك من أجل تنفيذه. بينسل, وهي مكتبة ذات شفرة مفتوحة المصدر ، وهي المصدر الأكثر شيوعًا لتطبيق Security Layer Security ، وهو نظام الأمن الأكثر تطبيقًا على نطاق واسع لبرنامج التعاون الفني. هذه المكتبة أيضا يتضمن تنفيذ DTLS, لذلك يجب أن تكون قادرًا على مواجهة خيارات UDP الآمنة في نفس التطبيقات التي توفر اتصالات TCP آمنة.

هناك خيار آخر لمستخدمي UDP وهو الاعتماد على نظام أمان تم تصميمه للعمل في Internet Layer. هذا هو أمن بروتوكول الإنترنت, أو أمان بروتوكول الإنترنت. نظرًا لأن IPSec يعمل أسفل طبقة النقل ، فإنه غير قادر على العمل مع المنافذ وبالتالي فإن حقيقة أن UDP غير قادر على الاحتفاظ بجلسة لا يهم عندما يتم تشغيل IPSec – لا يمكن لبروتوكولات طبقة IP إنشاء جلسات أيضًا. كنظام الطبقة السفلى, IPSec قادر على دعم أي بروتوكول لطبقة النقل ، بما في ذلك UDP.

يتضمن IPSec أساليب المصادقة ويقوم أيضًا بتشفير الحزم لحمايتها من المتلصصين التنصت على المكالمات الهاتفية. يوفر تكنولوجيا المعلومات نفس القدر من الأمان الذي توفره طبقة TLS الشائعة ، ولكن لا يتم تطبيقه على نطاق واسع. يستخدم IPSec نظام تبادل مفتاح الإنترنت (IKEv2) لإعداد المصادقة ، وفي كثير من الأحيان ، تتم محاسبة IPSec على أنه IKEv2. تستخدم منهجية IKEv2 ديفي هيلمان إجراءات الصرف الرئيسية, وهو نفس النظام الذي تستخدمه TLS لمنهجية جلسة صفحة الويب الآمنة HTTPS.

يعد Kerberos و Kerberized Internet Negotiation of Keys (KINK) عنصرين من عناصر نظام الأمان الذي يسمى عادة Kerberos. تستخدم إجراءات تأسيس جلسة Kerberos نظامًا من “التذاكر” يشبه طريقة TLS المتمثلة في استخدام “الشهادات”. في الجزء السفلي للغاية من الحزمة ، يعتمد Kerberos على IPSec. تقع طبقة Kerberos التي تحمل اسمًا أعلى UDP وتستخدم مآخذ UDP لتسهيل الاتصال. لذلك هذا هو نظام الأمن ودية UDP. إحدى الميزات المثيرة لـ Kerberos هي أنها تتيح لك خيار استخدام تشفير AES لحماية عمليات نقل UDP. من المحتمل أن يكون AES هو أكثر الشفرات أمانًا في الاستخدام الشائع اليوم وهو طريقة الأمان الموصى بها لأفضل أنظمة حماية خصوصية VPN في العالم.

على الرغم من الصعوبات الظاهرة للتفاوض على مفاتيح التشفير في بيئة لا توفر أي إدارة اتصال ، فإن UDP تقدم خيارات أمان. لذلك ، عند تطبيق تطبيق يستند إلى UDP ، لا تتخلى عن مهمة تأمين عمليات الإرسال الخاصة بك.

مستقبل UDP

تعتبر التطبيقات المستندة إلى UDP الخالصة والتي لا تتضمن بروتوكولات جانبية لتقليد TCP أمرًا نادرًا ومن المحتمل أن تصبح أكثر ندرة. أدوات الشبكة خفيفة الوزن التي تستخدم UDP تزدهر على الشبكات المحلية الآمنة. ومع ذلك ، مع تزايد تهديدات الأمان من هجمات يوم الصفر الجديدة كل أسبوع ، يبدو أن مفهوم وجود بروتوكولات غير آمنة تدير الخدمات الأساسية لإدارة التهيئة والعنونة يرضي بحماقة.

عندما تنقل الشبكات خدماتها إلى الشبكة السحابية ، سيبدأ استبدال خدمات TFTP و DHCP القائمة على UDP ببدائل أكثر أمانًا. إن الحل السهل لتصفح التطبيقات عبر HTTPS لمنحهم الأمان دون بذل جهد إضافي في البرمجة يمحو المستقبل نحو TCP ، الذي يحمل HTTPS ويجرد الفرص من قائمة UDP الخاصة بالكفاءات.

من المرجح أن يدوم مكانة UDP الداعمة لعمليات نقل الوسائط. كان هناك بالفعل العديد من أنظمة النقل المتنافسة المقترحة لدعم التطبيقات التفاعلية ، لكن أيا منها لم يطرد UDP من موقعه كخيار أول لنقل الصوت عبر بروتوكول الإنترنت والفيديو. تشمل قائمة المنافسين هذه:

بروتوكول مخطط بيانات المستخدم الموثوق (RUDP), التي لديها تطبيقات سيسكو ومايكروسوفت.

بروتوكول نقل التحكم في التدفق (SCTP), الذي تم اقتراحه دون جدوى كبديل لمجموعة التحرير والسرد UDP / RTP / RTCP ، ولكن لم يسبق له مثيل.

تم اكتشاف هذه البطة القبيحة المسماة UDP لتكون بجعة ، وذلك بفضل القوى التحويلية السحرية للتطبيقات واسعة النطاق والتفاعلية. سوف يستمر هذا النجم الذي تم إحيائه في الانزلاق بدون عناء عبر مياه الإنترنت.

ما هي وسائل النقل التي تستخدمها؟ هل ترى البطة القبيحة على شكل بجعة؟ اكتب عن تجاربك في قسم التعليقات أدناه.

ذات صلة:
الدليل النهائي ل TCP / IP
ما هو TCPdump?
SolarWinds TFTP خادم مراجعة
TFTPD32 استعراض خادم TFTP

الصور:
رأس UDP من Devarshi في الإنجليزية Wikibooks المرخصة بموجب CC BY-SA 2.5
تخطيط حزمة TCP مع مقياس بت بواسطة Quliyevferman عبر ويكيميديا ​​كومنز. مرخص بموجب CC BY-SA 4.0