بروتوكول بيانات المستخدم
| بروتوكول الاتصالات | |
| اختصار | بروتوكول بيانات المستخدم |
|---|---|
| المطور(ون) | ديفيد ب. ريد |
| مقدمة | 1980 |
| متأثر | كويك |
| طبقة OSI | طبقة النقل (4) |
| طلبات التعليقات | طلب التعليقات رقم 768 |
في الشبكات الحاسوبية ، يعد بروتوكول بيانات المستخدم ( UDP ) أحد بروتوكولات الاتصال الأساسية لمجموعة بروتوكولات الإنترنت المستخدمة لإرسال الرسائل (التي يتم نقلها كبيانات في حزم ) إلى مضيفين آخرين على شبكة بروتوكول الإنترنت (IP). داخل شبكة IP، لا يتطلب بروتوكول بيانات المستخدم (UDP) اتصالاً مسبقًا لإعداد قنوات الاتصال أو مسارات البيانات.
إن بروتوكول UDP هو بروتوكول بدون اتصال ، مما يعني أن الرسائل تُرسل دون التفاوض على اتصال وأن بروتوكول UDP لا يتتبع ما أرسله. [1] [2] يوفر بروتوكول UDP مجموعات اختبارية لسلامة البيانات وأرقام منافذ لمعالجة وظائف مختلفة في المصدر والوجهة للبرقية. لا يحتوي على مربعات حوار مصافحة وبالتالي يعرض برنامج المستخدم لأي عدم موثوقية للشبكة الأساسية؛ لا يوجد ضمان للتسليم أو الطلب أو الحماية من التكرار. إذا كانت هناك حاجة إلى مرافق تصحيح الأخطاء على مستوى واجهة الشبكة، فقد يستخدم التطبيق بدلاً من ذلك بروتوكول التحكم في الإرسال (TCP) أو بروتوكول التحكم في تدفق الإرسال (SCTP) المصمم لهذا الغرض.
يُعد بروتوكول UDP مناسبًا للأغراض التي لا يكون فيها التحقق من الأخطاء وتصحيحها ضروريًا أو يتم إجراؤه في التطبيق؛ يتجنب بروتوكول UDP التكلفة الزائدة لمثل هذه المعالجة في مكدس البروتوكول . غالبًا ما تستخدم التطبيقات الحساسة للوقت بروتوكول UDP لأن إسقاط الحزم أفضل من انتظار الحزم المتأخرة بسبب إعادة الإرسال ، وهو ما قد لا يكون خيارًا في نظام الوقت الفعلي . [3]
تم تصميم البروتوكول بواسطة ديفيد ب. ريد في عام 1980 وتم تعريفه رسميًا في RFC 768.
صفات
UDP هو بروتوكول طبقة نقل بسيط موجه للرسائل وموثق في RFC 768. على الرغم من أن UDP يوفر التحقق من سلامة (عبر المجموع الاختباري ) للرأس والحمولة، [4] إلا أنه لا يوفر أي ضمانات لبروتوكول الطبقة العليا لتسليم الرسالة ولا تحتفظ طبقة UDP بأي حالة لرسائل UDP بمجرد إرسالها. لهذا السبب، يشار إلى UDP أحيانًا باسم بروتوكول البيانات غير الموثوق به . [5] إذا كانت موثوقية الإرسال مطلوبة، فيجب تنفيذها في تطبيق المستخدم.
هناك عدد من السمات التي يتمتع بها بروتوكول UDP والتي تجعله مناسبًا بشكل خاص لتطبيقات معينة.
- فهو موجه نحو المعاملات ، ومناسب لبروتوكولات الاستعلام والاستجابة البسيطة مثل نظام اسم المجال أو بروتوكول وقت الشبكة .
- إنه يوفر مخططات بيانات مناسبة لنمذجة بروتوكولات أخرى مثل نفق IP أو استدعاء الإجراء عن بعد ونظام ملفات الشبكة .
- إنه بسيط ومناسب للتمهيد أو لأغراض أخرى دون مجموعة بروتوكولات كاملة ، مثل DHCP وبروتوكول نقل الملفات البسيط .
- إنه عديم الجنسية ، ومناسب لأعداد كبيرة جدًا من العملاء، كما هو الحال في تطبيقات بث الوسائط مثل IPTV .
- إن عدم وجود تأخيرات في إعادة الإرسال يجعله مناسبًا للتطبيقات في الوقت الفعلي مثل Voice over IP والألعاب عبر الإنترنت والعديد من البروتوكولات التي تستخدم بروتوكول البث في الوقت الفعلي .
- نظرًا لأنه يدعم البث المتعدد ، فهو مناسب لمعلومات البث كما هو الحال في العديد من أنواع اكتشاف الخدمة والمعلومات المشتركة مثل بروتوكول الوقت الدقيق وبروتوكول معلومات التوجيه .
الموانئ
يمكن للتطبيقات استخدام مآخذ البيانات لإنشاء اتصالات من مضيف إلى مضيف. يربط التطبيق مأخذًا بنقطة نهاية نقل البيانات الخاصة به، والتي هي عبارة عن مزيج من عنوان IP ومنفذ . بهذه الطريقة، يوفر UDP إرسالًا متعددًا للتطبيق . المنفذ هو بنية برمجية يتم تحديدها من خلال رقم المنفذ ، وهو قيمة عددية صحيحة مكونة من 16 بت، مما يسمح بأرقام المنافذ بين 0 و65535. المنفذ 0 محجوز ولكنه قيمة منفذ مصدر مسموح بها إذا لم تتوقع عملية الإرسال رسائل في الاستجابة.
قسمت هيئة أرقام الإنترنت المخصصة (IANA) أرقام المنافذ إلى ثلاثة نطاقات. [ 6 ] تُستخدم أرقام المنافذ من 0 إلى 1023 للخدمات الشائعة والمعروفة. في أنظمة التشغيل الشبيهة بنظام يونكس ، يتطلب استخدام أحد هذه المنافذ إذن تشغيل المستخدم الفائق . أرقام المنافذ من 1024 إلى 49151 هي المنافذ المسجلة المستخدمة للخدمات المسجلة لدى IANA. المنافذ من 49152 إلى 65535 هي منافذ ديناميكية غير مخصصة رسميًا لأي خدمة محددة ويمكن استخدامها لأي غرض. يمكن أيضًا استخدامها كمنافذ مؤقتة ، والتي يمكن للبرامج التي تعمل على المضيف استخدامها لإنشاء نقاط نهاية اتصالات ديناميكيًا حسب الحاجة. [6]
بنية بيانات UDP
يتكون مخطط بيانات UDP من رأس مخطط بيانات يتبعه قسم بيانات (بيانات الحمولة للتطبيق). يتكون رأس مخطط بيانات UDP من 4 حقول، كل منها 2 بايت (16 بت): [3]
| الإزاحة | ثماني بتات | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ثماني بتات | قليل | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | منفذ المصدر | ميناء الوجهة | ||||||||||||||||||||||||||||||
| 4 | 32 | طول | المجموع الاختباري | ||||||||||||||||||||||||||||||
| 8 | 64 | بيانات | |||||||||||||||||||||||||||||||
| 12 | 96 | ||||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
يعد استخدام حقلي المجموع الاختباري ومنفذ المصدر اختياريًا في IPv4 (خلفية أرجوانية فاتحة في الجدول). في IPv6، يكون حقل منفذ المصدر اختياريًا فقط. إذا لم يتم استخدامه، فيجب ضبط هذه الحقول على الصفر. [7]
- منفذ المصدر: 16 بت
- يحدد هذا الحقل منفذ المرسل عند استخدامه، ويجب افتراض أنه المنفذ الذي سيتم الرد عليه عند الحاجة. إذا كان المضيف المصدر هو العميل، فمن المرجح أن يكون رقم المنفذ منفذًا مؤقتًا. إذا كان المضيف المصدر هو الخادم، فمن المرجح أن يكون رقم المنفذ رقم منفذ معروف من 0 إلى 1023. [6]
- منفذ الوجهة: 16 بت
- يحدد هذا الحقل منفذ المستقبل وهو مطلوب. وعلى غرار رقم منفذ المصدر، إذا كان العميل هو المضيف الوجهة، فمن المرجح أن يكون رقم المنفذ رقم منفذ مؤقت وإذا كان المضيف الوجهة هو الخادم، فمن المرجح أن يكون رقم المنفذ رقم منفذ معروف. [6]
- الطول: 16 بت
- يحدد هذا الحقل طول حزمة بيانات UDP (حقول الرأس وحقل البيانات) بالبايتات . الحد الأدنى للطول هو 8 بايت، وهو طول الرأس. يحدد حجم الحقل حدًا نظريًا يبلغ 65535 بايتًا (رأس مكون من 8 بايتات + 65527 بايتًا من البيانات) لحزمة بيانات UDP. ومع ذلك، فإن الحد الفعلي لطول البيانات، والذي يفرضه بروتوكول IPv4 الأساسي ، هو 65507 بايت (65535 بايتًا − رأس UDP مكون من 8 بايتات − رأس IP مكون من 20 بايتًا ). [8]
- باستخدام مخططات IPv6 الضخمة ، من الممكن الحصول على مخططات بيانات UDP بحجم أكبر من 65535 بايت. يتم ضبط حقل الطول على الصفر إذا كان طول رأس UDP بالإضافة إلى بيانات UDP أكبر من 65535 بايت. [9]
- المجموع الاختباري : 16 بت
- يمكن استخدام حقل المجموع الاختباري للتحقق من الأخطاء في الرأس والبيانات. هذا الحقل اختياري في IPv4، وإلزامي في معظم الحالات في IPv6. [10]
- البيانات: متغير
- حمولة حزمة UDP.
حساب المجموع الاختباري
تم تعريف الطريقة المستخدمة لحساب المجموع الاختباري في RFC 768، وتمت مناقشة الحساب الفعال في RFC 1071:
المجموع الاختباري هو المكمل الواحد المكون من 16 بت لمجموع المكمل الواحد لرأس وهمي للمعلومات من رأس IP ورأس UDP والبيانات، مع إضافة صفر من الثمانيات في النهاية (إذا لزم الأمر) لعمل مضاعف لثمانيتين. [7]
بعبارة أخرى، يتم جمع كل الكلمات المكونة من 16 بت باستخدام حساب المكمل الواحد. أضف قيم 16 بت. في كل إضافة، إذا تم إنتاج بت حمل (بت 17)، قم بتحريك بت الحمل 17 هذا وأضفه إلى البت الأقل أهمية في الإجمالي الجاري. [11] أخيرًا، يتم بعد ذلك تكميل المجموع بـ 1 للحصول على قيمة حقل المجموع الاختباري لـ UDP.
إذا أسفرت عملية حساب المجموع الاختباري عن القيمة صفر (كل 16 بت 0)، فيجب إرسالها كمكمل للواحدات (كل 1) حيث يشير المجموع الاختباري ذو القيمة صفر إلى عدم حساب أي مجموع اختباري. [7] في هذه الحالة، لا يلزم أي معالجة محددة في المستقبل، لأن كل 0 وكل 1 تساوي صفرًا في حساب المكمل للواحدات.
تكمن الاختلافات بين IPv4 و IPv6 في الرأس الزائف المستخدم لحساب المجموع الاختباري، وأن المجموع الاختباري ليس اختياريًا في IPv6. [12] في ظل ظروف معينة، يُسمح لتطبيق UDP الذي يستخدم IPv6 باستخدام وضع المجموع الاختباري الصفري UDP مع بروتوكول النفق. [13]
رأس IPv4 الوهمي
عندما يعمل UDP عبر IPv4، يتم حساب المجموع الاختباري باستخدام رأس زائف يحتوي على بعض المعلومات نفسها من رأس IPv4 الحقيقي . [7] : 2 الرأس الزائف ليس رأس IPv4 الحقيقي المستخدم لإرسال حزمة IP، فهو يستخدم فقط لحساب المجموع الاختباري. حساب المجموع الاختباري لـ UDP اختياري لـ IPv4. إذا لم يتم استخدام المجموع الاختباري، فيجب ضبطه على القيمة صفر.
| الإزاحة | ثماني بتات | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ثماني بتات | قليل | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | عنوان المصدر | |||||||||||||||||||||||||||||||
| 4 | 32 | عنوان الوجهة | |||||||||||||||||||||||||||||||
| 8 | 64 | الأصفار | بروتوكول | طول UDP | |||||||||||||||||||||||||||||
| 12 | 96 | منفذ المصدر | ميناء الوجهة | ||||||||||||||||||||||||||||||
| 16 | 128 | طول | المجموع الاختباري | ||||||||||||||||||||||||||||||
| 20 | 160 | بيانات | |||||||||||||||||||||||||||||||
| 24 | 192 | ||||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
يتم حساب المجموع الاختباري عبر الحقول التالية:
- عنوان المصدر: 32 بت
- عنوان المصدر من رأس IPv4.
- عنوان الوجهة: 32 بت
- عنوان الوجهة من رأس IPv4.
- الأصفار: 8 بت؛ الأصفار == 0
- كل الأصفار.
- البروتوكول: 8 بت
- قيمة البروتوكول لـ UDP: 17 (أو 0x11 ).
- طول UDP: 16 بت
- طول رأس UDP والبيانات (مقاسة بالثمانيات).
رأس IPv6 الوهمي
نظرًا لأن IPv6 يحتوي على عناوين أكبر وتخطيط رأس مختلف، فإن الطريقة المستخدمة لحساب المجموع الاختباري تتغير وفقًا لذلك: [10] : §8.1
يجب تعديل أي بروتوكول نقل أو أي بروتوكول آخر من الطبقة العليا يتضمن العناوين من رأس IP في حساب المجموع الاختباري الخاص به للاستخدام عبر IPv6، ليشمل عناوين IPv6 ذات 128 بت بدلاً من عناوين IPv4 ذات 32 بت.
عند حساب المجموع الاختباري، يتم مرة أخرى استخدام رأس وهمي يحاكي رأس IPv6 الحقيقي :
| الإزاحة | ثماني بتات | 0 | 1 | 2 | 3 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ثماني بتات | قليل | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
| 0 | 0 | عنوان المصدر | |||||||||||||||||||||||||||||||
| 4 | 32 | ||||||||||||||||||||||||||||||||
| 8 | 64 | ||||||||||||||||||||||||||||||||
| 12 | 96 | ||||||||||||||||||||||||||||||||
| 16 | 128 | عنوان الوجهة | |||||||||||||||||||||||||||||||
| 20 | 160 | ||||||||||||||||||||||||||||||||
| 24 | 192 | ||||||||||||||||||||||||||||||||
| 28 | 224 | ||||||||||||||||||||||||||||||||
| 32 | 256 | طول UDP | |||||||||||||||||||||||||||||||
| 36 | 288 | الأصفار (0) | العنوان التالي (17) | ||||||||||||||||||||||||||||||
| 40 | 320 | منفذ المصدر | ميناء الوجهة | ||||||||||||||||||||||||||||||
| 44 | 352 | طول | المجموع الاختباري | ||||||||||||||||||||||||||||||
| 48 | 384 | بيانات | |||||||||||||||||||||||||||||||
| 52 | 416 | ||||||||||||||||||||||||||||||||
| ⋮ | ⋮ | ||||||||||||||||||||||||||||||||
يتم حساب المجموع الاختباري عبر الحقول التالية:
- عنوان المصدر: 128 بت
- العنوان في رأس IPv6.
- عنوان الوجهة: 128 بت
- الوجهة النهائية؛ إذا كانت حزمة IPv6 لا تحتوي على رأس التوجيه، يستخدم TCP عنوان الوجهة في رأس IPv6، وإلا، في العقدة الأصلية، فإنه يستخدم العنوان الموجود في العنصر الأخير من رأس التوجيه، وفي العقدة المستقبلة، فإنه يستخدم عنوان الوجهة في رأس IPv6.
- طول UDP: 32 بت
- طول رأس UDP والبيانات (مقاسة بالثمانيات).
- الأصفار: 24 بت؛ الأصفار == 0
- كل الأصفار.
- العنوان التالي: 8 بت
- قيمة بروتوكول طبقة النقل لـ UDP: 17 .
الموثوقية والتحكم في الازدحام
بسبب افتقارها إلى الموثوقية، قد تواجه تطبيقات UDP بعض فقدان الحزم أو إعادة ترتيبها أو الأخطاء أو التكرار. إذا كنت تستخدم UDP، فيجب على تطبيقات المستخدم النهائي توفير أي مصافحة ضرورية مثل التأكيد في الوقت الفعلي على استلام الرسالة. قد تضيف التطبيقات، مثل TFTP ، آليات موثوقية أولية إلى طبقة التطبيق حسب الحاجة. [6] إذا كان التطبيق يتطلب درجة عالية من الموثوقية، فيمكن استخدام بروتوكول مثل بروتوكول التحكم في الإرسال بدلاً من ذلك.
في أغلب الأحيان، لا تستخدم تطبيقات UDP آليات الموثوقية وقد تعوقها هذه الآليات. تعد الوسائط المتدفقة والألعاب متعددة اللاعبين في الوقت الفعلي ونقل الصوت عبر IP (VoIP) أمثلة للتطبيقات التي تستخدم UDP غالبًا. في هذه التطبيقات المعينة، لا يمثل فقدان الحزم مشكلة قاتلة عادةً. في VoIP، على سبيل المثال، يعد زمن الوصول والتذبذب من المخاوف الأساسية. سيؤدي استخدام TCP إلى حدوث تذبذب في حالة فقد أي حزم لأن TCP لا يوفر بيانات لاحقة للتطبيق أثناء طلب إعادة إرسال البيانات المفقودة.
التطبيقات
تستخدم العديد من تطبيقات الإنترنت الرئيسية بروتوكول UDP، بما في ذلك: نظام اسم المجال (DNS)، وبروتوكول إدارة الشبكة البسيط (SNMP)، وبروتوكول معلومات التوجيه (RIP) [3] وبروتوكول تكوين المضيف الديناميكي (DHCP).
يتم نقل حركة الصوت والفيديو عمومًا باستخدام UDP. تم تصميم بروتوكولات بث الفيديو والصوت في الوقت الفعلي للتعامل مع الحزم المفقودة من حين لآخر، لذلك يحدث تدهور طفيف في الجودة فقط، بدلاً من التأخيرات الكبيرة في حالة إعادة إرسال الحزم المفقودة. نظرًا لأن كل من TCP وUDP يعملان عبر نفس الشبكة، فقد وجدت بعض الشركات في منتصف العقد الأول من القرن الحادي والعشرين أن زيادة حركة مرور UDP من تطبيقات الوقت الفعلي هذه أعاقت قليلاً أداء التطبيقات التي تستخدم TCP مثل نقاط البيع والمحاسبة وأنظمة قواعد البيانات (عندما يكتشف TCP فقدان الحزمة، فإنه سيقلل من استخدام معدل البيانات الخاص به). [14]
قد تستخدم بعض أنظمة VPN مثل OpenVPN بروتوكول UDP وتقوم بالتحقق من الأخطاء على مستوى التطبيق أثناء تنفيذ اتصالات موثوقة.
QUIC هو بروتوكول نقل مبني على UDP. يوفر QUIC اتصالاً موثوقًا وآمنًا. يستخدم HTTP/3 QUIC على عكس الإصدارات السابقة من HTTPS التي تستخدم مزيجًا من TCP و TLS لضمان الموثوقية والأمان على التوالي. هذا يعني أن HTTP/3 يستخدم مصافحة واحدة لإعداد اتصال، بدلاً من وجود مصافحتين منفصلتين لـ TCP وTLS، مما يعني تقليل الوقت الإجمالي لإنشاء اتصال. [15]
مقارنة بين UDP وTCP
بروتوكول التحكم في الإرسال هو بروتوكول موجه نحو الاتصال ويتطلب المصافحة لإعداد الاتصالات من البداية إلى النهاية. بمجرد إعداد الاتصال، يمكن إرسال بيانات المستخدم في اتجاهين عبر الاتصال.
- موثوقة – يدير بروتوكول TCP عملية تأكيد الرسالة وإعادة الإرسال وحالات انتهاء المهلة. يتم إجراء محاولات متعددة لتسليم الرسالة. إذا فقدت البيانات أثناء النقل، فسيتم إعادة إرسالها. في بروتوكول TCP، إما لا توجد بيانات مفقودة، أو في حالة حالات انتهاء المهلة المتعددة، يتم قطع الاتصال.
- مُرتَّب – إذا تم إرسال رسالتين عبر اتصال بالتتابع، فستصل الرسالة الأولى إلى التطبيق المُستقبِل أولاً. وعندما تصل أجزاء البيانات بالترتيب الخاطئ، يقوم بروتوكول TCP بتخزين البيانات غير المرتبة مؤقتًا حتى يمكن إعادة ترتيب كافة البيانات بشكل صحيح وتسليمها إلى التطبيق.
- ثقيل الوزن – يتطلب بروتوكول TCP ثلاث حزم لإعداد اتصال بمقبس قبل أن يتم إرسال أي بيانات مستخدم. ويتولى بروتوكول TCP التحكم في الموثوقية والازدحام .
- البث - تتم قراءة البيانات كتدفق بايتات ، ولا يتم إرسال أي مؤشرات مميزة لإشارة حدود الرسالة (الجزء).
بروتوكول بيانات المستخدم هو بروتوكول بسيط يعتمد على الرسائل ولا يتطلب اتصالاً . لا تقوم البروتوكولات التي لا تتطلب اتصالاً بإعداد اتصال مخصص من طرف إلى طرف. يتم تحقيق الاتصال عن طريق نقل المعلومات في اتجاه واحد من المصدر إلى الوجهة دون التحقق من جاهزية أو حالة المستقبل.
- غير موثوقة – عند إرسال رسالة UDP، لا يمكن معرفة ما إذا كانت ستصل إلى وجهتها؛ فقد تضيع أثناء الطريق. لا يوجد مفهوم للإقرار أو إعادة الإرسال أو مهلة زمنية.
- غير مرتبة - إذا تم إرسال رسالتين إلى نفس المستلم، فلا يمكن ضمان الترتيب الذي يصلان به.
- خفيف الوزن – لا يوجد ترتيب للرسائل، ولا اتصالات تتبع، وما إلى ذلك. إنها طبقة نقل بسيطة للغاية مصممة فوق IP.
- الرسائل البريدية – يتم إرسال الحزم بشكل فردي ويتم التحقق من سلامتها عند وصولها. تحتوي الحزم على حدود محددة يتم الالتزام بها عند استلامها؛ حيث ستؤدي عملية القراءة عند مقبس الاستقبال إلى الحصول على الرسالة بالكامل كما تم إرسالها في الأصل.
- لا يوجد تحكم في الازدحام - لا يتجنب بروتوكول UDP بحد ذاته الازدحام. يجب تنفيذ تدابير التحكم في الازدحام على مستوى التطبيق أو في الشبكة.
- البث - نظرًا لكونه بدون اتصال، يمكن لـ UDP البث - يمكن توجيه الحزم المرسلة بحيث يمكن استقبالها بواسطة جميع الأجهزة الموجودة على الشبكة الفرعية.
- البث المتعدد – يتم دعم وضع التشغيل المتعدد حيث يمكن توجيه حزمة بيانات واحدة تلقائيًا دون تكرار إلى مجموعة من المشتركين.
المعايير
- RFC 768 – بروتوكول بيانات المستخدم
- RFC 2460 – مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6)
- RFC 2675 – مخططات IPv6 الضخمة
- RFC 4113 – قاعدة معلومات الإدارة لبروتوكول بيانات المستخدم
- RFC 8085 – إرشادات استخدام UDP
انظر أيضا
- مقارنة بروتوكولات طبقة النقل
- أمان طبقة نقل البيانات (DTLS)
- قائمة بأرقام منافذ TCP وUDP
- بروتوكول النقل الدقيق (μTP)
- بروتوكول البيانات الموثوقة (RDP)
- بروتوكول بيانات المستخدم الموثوق به (RUDP)
- بروتوكول نقل البيانات المستند إلى UDP
- هجوم فيضان UDP
- عنوان مساعد UDP
- ثقب UDP
- UDP-Lite – متغير يقوم بتسليم الحزم حتى لو كانت مشوهة
مراجع
- ^ دليل مبيعات وخدمات الشبكة . 2003. ISBN 9781587050909.
- ^ Windows Command Line: The Personal Trainer for Windows 8.1 Windows Server 2012 and Windows Server 2012 R2 . 2015. ISBN 9781627164139.
- ^ abc Kurose, JF; Ross, KW (2010). Computer Networking: A Top-Down Approach (الطبعة الخامسة). بوسطن، ماساتشوستس: بيرسون للتعليم. ISBN 978-0-13-136548-3.
- ^ كلارك، م ب (2003). شبكات البيانات والبروتوكولات الدولية والإنترنت، الطبعة الأولى . غرب ساسكس، إنجلترا: جون وايلي وأولاده المحدودة.
- ^ content@ipv6.com (15 أغسطس 2006). "نظرة عامة على بروتوكول UDP". Ipv6.com . تم الاسترجاع في 17 أغسطس 2011 .
{{cite web}}: CS1 maint: numeric names: authors list (link) - ^ abcde Forouzan, BA (2000). TCP/IP: Protocol Suite, 1st ed . نيودلهي، الهند: شركة تاتا ماكجرو هيل للنشر المحدودة.
- ^ abcde J. Postel ، محرر (28 أغسطس 1980). بروتوكول بيانات المستخدم. IETF . doi : 10.17487/RFC0768 . STD 6. RFC 768. معيار الإنترنت 6.
- ^ ستيفنز، دبليو ريتشارد (1994). TCP/IP Illustrated: The protocols . المجلد 1 (الطبعة الثانية). أديسون ويسلي. ISBN 978-0-20-163346-7.
- ^ د. بورمان؛ س. ديرينج ؛ ر. هيندين (أغسطس 1999). مخططات IPv6 الضخمة. مجموعة عمل الشبكة. doi : 10.17487/RFC2675 . RFC 2675. المعيار المقترح يلغي الحاجة إلى RFC 2147.
- ^ ab S. Deering ؛ R. Hinden (يوليو 2017). مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6). IETF . doi : 10.17487/RFC8200 . STD 86. RFC 8200. معيار الإنترنت 86. RFC 2460 المتقادم .
- ^ "حساب مجموع المتممات الأحادية المكونة من 16 بت". mathforum.org . جون. 20 مارس 2002. مؤرشف من الأصل ( البريد الإلكتروني ) في 17 نوفمبر 2020. تم الاسترجاع في 5 نوفمبر 2014 .
- ^ مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6). ص 27-28. doi : 10.17487/RFC8200 . RFC 8200.
- ^ مواصفات بروتوكول الإنترنت، الإصدار 6 (IPv6). ص. 23. doi : 10.17487/RFC8085 . RFC 8085.
- ^ "تأثير بروتوكول UDP على تطبيقات البيانات". Networkperformancedaily.com. مؤرشف من الأصل في 31 يوليو 2007. تم الاسترجاع في 17 أغسطس 2011 .
- ^ "QUIC، نقل تدفق متعدد الإرسال عبر UDP". chromium.org . تم الاسترجاع في 17 فبراير 2021 .
روابط خارجية
- مهام منفذ IANA
- المشكلة مع فحص UDP (PDF)
- انهيار إطار UDP
- UDP على مآخذ مجلة MSDN وWCF
