بروتوكول بيانات المستخدم، ويُختصر UDP، هو بروتوكول في طبقة النقل يرسل البيانات عبر شبكات IP بعبء قليل جداً. يسمح للتطبيقات بإرسال وحدات صغيرة تسمى رزمًا بياناتية من دون إنشاء اتصال رسمي مسبق بين المرسل والمستقبل.

على عكس TCP الذي يركز على التسليم الموثوق والترتيب وإعادة الإرسال والتحكم في التدفق، صُمم UDP للسرعة والبساطة وزمن التأخير المنخفض. لذلك يُستخدم في الاتصال الفوري والألعاب وبث الفيديو وDNS ووسائط VoIP وقياسات IoT واكتشاف الشبكة وأنفاق VPN.

طريقة خفيفة لنقل البيانات

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

هذا التصميم الخفيف يجعل UDP سريعاً، إذ لا توجد مصافحة اتصال قبل النقل، ولا إعادة إرسال مدمجة عند فقدان الحزمة، ولا شرط صارم لوصول الحزم بالترتيب.

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

كيف يعمل تدفق الرزم البياناتية

ينشئ التطبيق الحمولة

تبدأ العملية عندما يحتاج تطبيق إلى إرسال بيانات مثل استعلام DNS أو حزمة صوت أو تحديث حركة في لعبة أو مقطع فيديو أو قراءة مستشعر أو رسالة اكتشاف.

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

تحدد المنافذ الخدمة

يستخدم UDP أرقام المنافذ لتحديد التطبيق أو الخدمة التي يجب أن تستقبل الرزمة البياناتية. يحدد منفذ المصدر التطبيق المرسل، بينما يحدد منفذ الوجهة الخدمة الموجودة على المضيف المستقبل.

على سبيل المثال، يستخدم DNS عادة منفذ UDP رقم 53، بينما تستخدم كثير من بروتوكولات الصوت والفيديو والألعاب والتطبيقات المخصصة نطاقات منافذ محددة خاصة بها. من دون المنافذ لن يعرف الجهاز المستقبل أي تطبيق يجب أن يعالج البيانات الواردة.

تتم إضافة الترويسة

يبين تتم إضافة الترويسة أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, المنافذ, NAT, المجموع الاختباري, الترويسة بعناية.

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

يتولى IP التسليم عبر الشبكة

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

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

لماذا تفضل بعض التطبيقات السرعة

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

هنا تظهر قيمة UDP. فهو يسمح للتطبيقات بالاستمرار من دون انتظار إعادة الإرسال في طبقة النقل. ويمكن للتطبيق استخدام مخازن اهتزاز التأخير، والتنبؤ، وإخفاء فقدان الحزم، وتصحيح الأخطاء الأمامي، أو معدل بت تكيفي للتعامل مع تسليم غير مثالي.

يبين لماذا تفضل بعض التطبيقات السرعة أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, TCP بعناية.

الخصائص الأساسية

تشغيل بلا اتصال

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

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

لا توجد ضمانات تسليم مدمجة

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

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

عبء منخفض

الرأس صغير والسلوك بسيط. وهذا يقلل عبء عرض النطاق والمعالجة. وفي أحجام كبيرة من الرسائل الصغيرة يمكن أن يكون ذلك ميزة مهمة.

يبين عبء منخفض أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم DNS, زمن التأخير بعناية.

دعم البث والبث المتعدد

يمكن أن يدعم UDP الاتصال بالبث والبث المتعدد بحسب إعدادات الشبكة. ويسمح ذلك لمرسل واحد بالوصول إلى عدة مستقبلين بكفاءة أكبر من إنشاء جلسات منفصلة كثيرة من نوع واحد إلى واحد.

يستخدم البث المتعدد كثيرا في IPTV، واكتشاف الخدمات، وبروتوكولات التوجيه، والأنظمة الصناعية، وبعض تصاميم توزيع الوسائط. لكن البث المتعدد يجب أن تدعمه المحولات والموجهات وسياسات الشبكة.

تحكم مرن من التطبيق

لأن البروتوكول يوفر تسليما أساسيا فقط، تستطيع التطبيقات بناء سلوكها الخاص فوقه. قد يعطي نظام البث أولوية للتشغيل السلس، وقد يعطي خادم الألعاب أولوية لأحدث تحديثات الحالة، وقد تعطي شبكة الحساسات أولوية لكفاءة البطارية، وقد تنشئ VPN طبقة موثوقية وتشفير خاصة بها.

هذه المرونة هي أحد الأسباب التي تجعل UDP مهما في الشبكات الحديثة رغم بنيته البسيطة.

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

أين يُستخدم عادةً

استعلامات DNS

يبين استعلامات DNS أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, المنافذ, DNS بعناية.

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

اتصالات الصوت والفيديو

تعتمد مكالمات VoIP، واجتماعات الفيديو، وتدفقات وسائط SIP، وصوت RTP، وجلسات WebRTC، والمؤتمرات الفورية غالبا على UDP لنقل الوسائط. والسبب بسيط: الصوت والفيديو المباشران يحتاجان إلى تأخير منخفض.

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

الألعاب عبر الإنترنت

ترسل الألعاب غالبا تحديثات متكررة للموقع والحركة والإجراء والحالة. وقد يهتم خادم اللعبة بآخر موقع للاعب أكثر من تحديث قديم وصل متأخرا.

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

البث والوسائط الحية

يبين البث والوسائط الحية أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, المنافذ, الفيديو, البث العام بعناية.

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

إنترنت الأشياء وبيانات المستشعرات

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

مع ذلك، يجب أن تراعي أنظمة IoT الموثوقية والأمان وفقدان الشبكة. فقد تحتاج الإنذارات الحرجة وتحديثات البرامج الثابتة وأوامر التحكم إلى تأكيد أقوى من القياسات العادية.

VPN وبروتوكولات الأنفاق

تستخدم بعض تقنيات VPN بروتوكول UDP لأنه يعمل جيدا في ظروف الشبكة المتغيرة ويتجنب بعض التأخيرات التي قد تحدث عند تداخل بروتوكولات موثوقة داخل بعضها.

عندما تحمل VPN حركة TCP داخل نفق TCP، قد تتفاعل آليات إعادة الإرسال أحيانا بشكل سيئ. أما الأنفاق المعتمدة على UDP فتمنح برنامج VPN تحكما أكبر في الموثوقية والتشفير والتوقيت.

اكتشاف الشبكة

يبين اكتشاف الشبكة أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, البث المتعدد, البث العام بعناية.

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

فوائد التصميم للمطورين والشبكات

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

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

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

وأخيرا يمنح البروتوكول مطوري التطبيقات مرونة. يمكنهم اختيار الرسائل التي تحتاج إلى إقرار، والتي يمكن إسقاطها، والتي يجب تكرارها، والتي يجب أن تنتهي صلاحيتها بسرعة. وبذلك يطابق التطبيق سلوك النقل مع حاجاته التجارية أو التقنية الحقيقية.

القيود والمخاطر

فقدان الحزم

يبين فقدان الحزم أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, الرزم البياناتية, الجدران النارية, الازدحام بعناية.

قد يكون ذلك مقبولا للتحديثات الفورية غير الحرجة. أما الأوامر أو المعاملات أو السجلات المهمة فتحتاج إلى موثوقية إضافية.

الوصول خارج الترتيب

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

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

لا يوجد تحكم افتراضي في الازدحام

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

ينبغي أن يتضمن التصميم المسؤول للتطبيق، عند الحاجة، التحكم في المعدل، أو معدل بت تكيفيا، أو تنظيم الإرسال، أو سلوكا مدركا للازدحام.

تحديات الجدار الناري و NAT

يبين تحديات الجدار الناري و NAT أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, TCP, المنافذ, NAT, الجدران النارية بعناية.

تستخدم التطبيقات غالبا رسائل إبقاء الاتصال، وSTUN، وTURN، وICE، أو خدمات الترحيل لدعم الاتصال عبر بيئات NAT والجدران النارية.

التعرض الأمني

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

ينبغي للخدمات التي تستخدم UDP أن تتحقق من الطلبات، وتحد من حجم الاستجابة، وتطبق حدودا لمعدل الطلبات، وتقيّد الوصول حيثما أمكن، وتستخدم التشفير أو المصادقة عند الحاجة.

طرق موثوقية مبنية فوق UDP

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

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

يبين طرق موثوقية مبنية فوق UDP أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم UDP, الأمان بعناية.

مقارنة عملية مع TCP

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

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

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

نصائح النشر واستكشاف الأعطال

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

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

يبين نصائح النشر واستكشاف الأعطال أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم الحزم, زمن التأخير, تذبذب التأخير بعناية.

في بيئات NAT، افحص مهلات التعيين وسلوك إبقاء الاتصال. إذا عملت الجلسة لفترة قصيرة ثم توقفت، فقد يكون جهاز NAT يغلق تعيين UDP بسرعة كبيرة.

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

أفضل ممارسات الأمان

لا تعرض خدمات UDP غير الضرورية للإنترنت العام. يجب حظر الخدمات المجهولة أو غير المستخدمة افتراضيا. وينبغي تحديث الخدمات المواجهة للعامة ومراقبتها وتقييد معدل استخدامها.

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

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

يبين أفضل ممارسات الأمان أن UDP يترك جزءاً كبيراً من التحكم للتطبيق، لذلك يجب تصميم الرزم البياناتية, المنافذ, NAT بعناية.

FAQ

هل يمكن تشفير UDP؟

نعم. يمكن إضافة التشفير فوق UDP من خلال البروتوكولات أو التطبيقات. فطبقة النقل نفسها لا تشفر البيانات، لذلك يجب توفير الأمان من طبقة أخرى.

لماذا لا تُظهر اختبارات منافذ UDP استجابة أحيانًا؟

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

هل يعمل UDP مع IPv6؟

نعم. يمكن أن يعمل UDP فوق IPv4 وIPv6. سلوك النقل متشابه، لكن العنونة وقواعد الجدار الناري وإعدادات الشبكة قد تختلف.

هل يمكن أن تكون حزم UDP أكبر من MTU الخاصة بالشبكة؟

يمكن أن تجزأ في طبقة IP، لكن التجزئة قد تزيد خطر الفقد. لذلك تحافظ كثير من التطبيقات على صغر حجم الرزم البياناتية لتجنب التجزئة.

لماذا تتحمل تطبيقات الوقت الحقيقي بعض فقدان الحزم؟

لأن انتظار البيانات القديمة قد يسبب تأخيرا. تفضل التطبيقات الفورية غالبا الاستمرار بأحدث البيانات واستخدام الإخفاء أو التنبؤ أو التخزين المؤقت أو الجودة التكيفية لتقليل أثر الفقد.