بروتوكول بيانات المستخدم UDPUser Datagram Protocol UDP

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

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

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

• لا يدعم المصافحة No handshaking: لا يقوم بروتوكول UDP بإقامة اتصال بين المرسل والمستقبل قبل بدء نقل البيانات؛ مما يجعله مناسبًا للتطبيقات التي تتطلب نقل البيانات بتأخير أقل في بعض الحالات، دون ضمان انعدامه، مثل بث الفيديو أو الألعاب عبر الانترنت، ولكنه أيضًا يعني أن البيانات قد تُفقد أو تصل بترتيب غير صحيح.
  
  
• لا يتضمن آلية تأكيد إرسال واستلام الحزم No acknowledgment mechanism: يعمل بروتوكول UDP دون تأكيد إرسال الحزم أو استلامها حيث لا يحصل المرسل على أي إشعار من المستقبل عما إذا كانت الحزم قد وصلت بنجاح أم لا؛ مما يجعله مناسبًا للتطبيقات التي لا تتطلب تبادل التأكيد مثل VoIP.
  
  
• لا يقوم بتصحيح الأخطاء No error recovery: لا يحتوي UDP على آليات لإعادة إرسال الحزم المفقودة، أو التعامل مع ترتيبها؛ مما يعني أن التطبيقات يجب أن تكون قادرة على التعامل مع هذه الحالات أو تحملها.
  
  
• البساطة Simplicity: يعتبر UDP هو أبسط بروتوكول اتصال يعمل في طبقة النقل حيث يقوم بتوصيل حزم البيانات بدون تعقيدات مقارنة ببعض البروتوكولات الأخرى.
  
  
• الحمل القليل Low overhead: يتميز UDP بصغر حجم رأس الحزمة التي تبلغ 8 بايت فقط؛ مما يجعله مناسبًا لنقل البيانات الصغيرة، مثل استعلامات DNS.
  
  
• عديم الحالة أو غير معتمد على الحالة Stateless: لا يحتفظ UDP بأي معلومات عن جلسات الاتصال السابقة أو حالة الاتصال بين المرسل والمستقبل بعد انتهاء عملية إرسال الحزمة أي أن كل حزمة بيانات تعتبر مستقلة بذاتها، ويتم معاملتها بشكل منفصل، ولا يعتمد إرسالها أو استقبالها على جلسات الاتصال السابقة.
  
  
• السرعة Speed: لا يشمل UDP مصافحة أو إقرارًا مدمجين، وقد يقلل ذلك بعض التأخير؛ لكن السرعة الفعلية تعتمد على الشبكة وتصميم التطبيق ولا تتفوق دائمًا على TCP؛ لذلك فهو مناسب للتطبيقات التي تتطلب زمن فعلي مثل الألعاب عبر الانترنت والبث المباشر.
  
  
• لا يحتوي على آلية للتحكم في الازدحام No congestion control: لا يوفر UDP آليات للتحكم في ازدحام الشبكة؛ فيجب أن تضيف التطبيقات فوقه آليات مناسبة لضبط معدل الإرسال وتجنب الازدحام. وهذا يمكن أن يؤدي إلى فقدان البيانات في الشبكات المزدحمة أو تأخرها.
  
  
• دعم البث العام والموجه Broadcast and multicast support: يدعم UDP إرسال الحزم عبر البث العام لجميع الأجهزة في الشبكة المحلية وكذلك البث الجماعي لمجموعة محددة؛ مما يجعله مناسبًا لأنواع أكثر من التطبيقات، مثل تطبيقات مؤتمرات الفيديو التي تعتمد على البث الجماعي.

• نوع الاتصال Type of Connection: بروتوكول UDP يعد من النوع الـ connectionless أي أنه لا يقوم بإقامة اتصال موثوق بين المرسل والمستقبل قبل بدء نقل البيانات، بينما بروتوكول TCP فهو من النوع الـ connection-oriented أي أنه يقوم بإقامة اتصال بين المرسل والمستقبل لنقل البيانات.

• الموثوقية Reliability: يعتمد بروتوكول التحكم في النقل TCP على آليات للنقل الموثوق إلى التطبيق عند نجاح الاتصال، وقد يفشل الاتصال [مثل آلية الإقرار]، بينما يُعتبر بروتوكول UDP أقل موثوقية؛ لأنه لا يحتوي على تلك الآليات التي تضمن تسليم البيانات.

• التحقق من الأخطاء Error checking: يستخدم TCP checksum لكشف التلف، ويستخدم أرقام التسلسل والإقرار وإعادة الإرسال لمعالجة الفقد؛ أما التحكم في التدفق فيراعي سعة المستقبل، بينما يكتفي بروتوكول UDP بفحص الأخطاء عن طريق المجموع الاختباري ولكنه يتجاهل الحزم التي لم تصل ولا يحاول معالجة الأخطاء عند وقوعها.
  

• الإقرار Acknowledgment: يحتوي بروتوكول TCP على مقاطع الإقرار acknowledgment segments التي يرسلها المستقبل للمرسل؛ لإعلام المرسل بأن البيانات قد تم استلامها بنجاح، بينما لا يتضمن بروتوكول UDP هذه المقاطع.

• الترتيب Ordering: يسلّم TCP البايتات إلى التطبيق بالترتيب الصحيح عند نجاح الاتصال، مستخدمًا أرقام التسلسل sequence numbers حتى لو وصلت المقاطع بترتيب مختلف، بينما  قد تصل datagrams في UDP بترتيب مختلف عن ترتيب الإرسال؛ لأنه لا يستخدم أي آليات لترتيب حزم البيانات أثناء نقلها.

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

• إعادة الإرسال Retransmission: في حال فقدان حزمة بيانات خلال النقل، يقوم بروتوكول TCP بإعادة إرسالها بشكل تلقائي لمحاولة استعادة البيانات المفقودة؛ وقد يفشل الاتصال أو تنتهي مهلة إعادة الإرسال، وهو ما لا يتوافر في بروتوكول UDP.

• البث Broadcasting: يدعم بروتوكول TCP نمط البث الأحادي Unicast حيث يتم إنشاء اتصال مباشر بين مرسل واحد ومستقبل واحد، بينما لا يدعم البث broadcasting ولا البث المتعدد multicasting؛ لأنه مصمم للاتصالات الموثوقة بين نقطتين محددتين. يمكن استخدام UDP مع البث الأحادي والجماعي، ومع البث العام في IPv4 عند دعم الشبكة له؛ ولا يتطلب UDP إنشاء اتصال مسبق.

• تدفق البيانات Flow of Data: يوفر بروتوكول TCP تدفق البيانات في كلا الاتجاهين، أي أنه يمكن للجهاز [أ] أن يرسل بيانات إلى الجهاز [ب] ويستقبل بيانات منه في نفس الوقت. في المقابل، يمكن لتطبيق UDP الإرسال والاستقبال في الاتجاهين أيضًا؛ الفرق أنه يتعامل مع رسائل مستقلة ولا يقدم اتصالًا موثوقًا أو تدفق بايتات مرتبًا مثل TCP.
  

• التحكم في التدفق Flow Control: يتبع بروتوكول TCP آلية التحكم في التدفق؛ لضمان عدم إرسال كمية كبيرة من الحزم في وقت واحد إلى المستقبل بشكل يفوق قدرته على المعالجة، بينما لا يتبنى بروتوكول UDP أي آليات للتحكم في التدفق حيث يقع على التطبيق تنظيم الإرسال وفق قدرات المستقبل وحالة الشبكة.

• الصوت عبر بروتوكول الانترنت Voice over Internet Protocol [VoIP]: يستخدم بروتوكول UDP في تطبيقات المكالمات الصوتية عبر الإنترنت مثل Skype و WhatsApp لأنها من التطبيقات الحساسة للوقت حيث قد يقلل UDP التأخير الناتج عن انتظار إعادة الإرسال، دون ضمان السرعة أو غياب الانقطاع حيث أن فقدان حزم قليلة يكون أقل تأثيرًا على جودة الصوت من التأخير الذي قد يحدث في بروتوكولات مثل TCP وبالتالي فإن استخدام بروتوكول UDP يعد مثاليًا لهذا النوع من التطبيقات؛ لأن إجراء محادثة مستمرة مع خسارة بعض أجزاء الصوت غير الملحوظ أفضل من أن تكون المحادثة نقية بشكل كامل ولكن مشوشة بسبب التأخير.

• استعلامات نظام أسماء النطاقات DNS: يستخدم بروتوكول UDP في عمليات البحث الخاصة بنظام اسم المجال DNS حيث تكون الاستعلامات صغيرة عادةً وتتطلب استجابة سريعة. يساهم UDP في سرعة ترجمة أسماء النطاقات إلى عناوين IP بفضل طبيعة عمله التي لا تتطلب تأكيد استلام البيانات، مما يجعله مثاليًا لهذه المهمة. لا يفرض DNS زمنًا ثابتًا بعدة مللي ثوانٍ لظهور الصفحة؛ تعتمد المدة على الكاش والشبكة والخادم. يدعم DNS أيضًا TCP، وقد تستخدم الخدمات DNS over TLS أو HTTPS، ويجب التعامل مع فقد الاستعلام أو الإجابة.

• الألعاب عبر الإنترنت Online Gaming: تحتاج الألعاب الإلكترونية عبر الانترنت إلى نقل بيانات سريع وتقليل التأخير لتحقيق تجربة لعب سلسة. بخلاف التأخر الذي يمكن أن يؤثر بشدة على أداء اللاعبين في الوقت الحقيقي، فإن التعايش مع انخفاض مؤقت في جودة الفيديو أو الصوت لثوانٍ قليلة يُعتبر أكثر قبولًا. قد يناسب UDP تحديثات اللعب الآني، بينما قد تستخدم اللعبة TCP أو وسائل موثوقة لأجزاء أخرى؛ لأنه يسمح بإرسال البيانات بسرعة مما يحسن من استجابة اللعبة ويقلل من زمن التأخر.

• البث المتعدد Multicasting: يستخدم بروتوكول UDP في تطبيقات البث المتعدد حيث تتطلب إرسال بيانات إلى مجموعة كبيرة من المستقبلين بشكل متزامن مثل بث الفيديوهات المباشرة أو المؤتمرات عبر الانترنت، حيث يتميز UDP بقدرته على إرسال حزم البيانات إلى عدة أجهزة في آن واحد دون الحاجة إلى إنشاء اتصال فردي مع كل جهاز مستلم؛ مما يجعله مثاليًا لهذا النوع من التطبيقات.

طبيعة بروتوكول UDP وسهولة استغلاله:

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

استراتيجيات التزييف وتجنب التعقب:

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

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

الأهداف الشائعة للهجمات:

تركز الهجمات بشكل كبير على الخدمات التي تعتمد على بروتوكول UDP، مثل خوادم DNS، الألعاب، وخدمات البث. هذه الخدمات تتميز باحتياجها إلى سرعة الاستجابة العالية وبالتالي اعتمادها الكبير على UDP؛ مما يجعلها أهدافًا شائعة وسهلة الاستغلال في هجمات DDoS.