Summary

  • يحذر RFC 5238 من إعادة إرسال طلب وضعه DCCP في الصف ولم يرسله فعلياً؛ وعندما تتوفر الإشارة، ينبغي بدء مؤقت DTLS عند تسليم DCCP الرسالة إلى IP.
  • قبول الصف والتسليم السفلي والإرسال والاستقبال واكتمال DCCP وتقدم DTLS وجاهزية التطبيق وقائع منفصلة لا يثبت أحدها الآخر.

فقدان صُنع قبل الوصول إلى الشبكة

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

تدخل النسخة الصف نفسه وتنافس الأصل على الفرصة النادرة. يصبح الانتظار سبباً للتكرار، ثم يزيد التكرار الانتظار.

يرسم RFC 5238 حداً أفضل: حين تبلغ الواجهة عن الحدث، ينتظر DTLS حتى ينقل DCCP الرسالة إلى طبقة IP قبل تشغيل ساعة الإعادة.

موثوقية المصافحة لا تحمي كل ما بداخلها

لـ DCCP مصافحة اتصال ولـ DTLS مصافحة حماية. يمكن وضع سجلات DTLS داخل DCCP-Request أو DCCP-Response لتداخل المرحلتين جزئياً.

لكن موثوقية مصافحة DCCP لا تضمن Application Data المضمّنة. قد يتجاهلها الخادم، وقد تعيد طبقة DCCP الطلب من دون البيانات الأصلية. لذلك يحتفظ DTLS بآلية الاسترداد الخاصة به.

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

ساعتان قد تضخمان السبب نفسه

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

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

الأرقام لا تعبر الحدود

ينص RFC 5238 على عدم وجود علاقة بين رقم حزمة DCCP ورقم سجل DTLS، ولا بين مزامنة DCCP وحماية DTLS من الإعادة. مشاركة الوعاء لا تمنح معنى مشتركاً.

ويجب أن يقع سجل DTLS كاملاً داخل حزمة DCCP واحدة وألا يتجاوز الحد الحالي الذي يمكن أن يتغير مع الازدحام.

المصافحة تترك حالة بعدها

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

اكتمال الحماية وجاهزية المعدل نتيجتان مختلفتان.

حدود السجل

لا تثبت المصادر منتجاً أو تنفيذاً أو شبكة أو حادثة أو قياساً أو انتشاراً حالياً. يسجل IANA المعلمات ولا يثبت استخدامها، ولا تثبت مواصفات DTLS اللاحقة اعتمادها فوق DCCP.

حتى التسليم إلى IP لا يثبت الإرسال الفيزيائي أو استقبال النظير أو جاهزية الجلسة. إنه نقطة بدء أدق من القبول المحلي فقط.

أعط كل مؤقت حدثاً ومالكاً

سجل التقديم والدخول إلى الصف وقرار الازدحام والتسليم إلى IP وهوية التسلسل والإرسال المرصود والاستجابة وحالة DCCP ورحلة DTLS وإطلاق التطبيق. عيّن من يملك كل ساعة وما يشغلها ويوقفها ويلغيها.

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

تعني أولوية الواقع التشغيلي لدى Lu Heng أن قبول API للعمل ليس تنفيذه. صاحب المؤقت مسؤول عن حد الدليل لأن ساعته تصنع حركة مرور أيضاً.

Sources

سجل معياري إضافي

  1. نص RFC 5238
  2. معلومات RFC 5238
  3. RFC 5238 في Datatracker
  4. تاريخ RFC 5238
  5. تصويبات RFC 5238
  6. مراجع RFC 5238