الخلاصة
- يحمل QUIC DATAGRAM مخطط بيانات تطبيقياً واحداً بصورة غير موثوقة ويحفظ حدوده، من دون إعادة إرسال أو ضمان ترتيب بين رسائل DATAGRAM.
- يشير max_datagram_frame_size إلى دعم استقبال اتجاهي وحجم، لا إلى سعة أو تسليم أو معالجة مضمونة.
- يثبت ACK معالجة طبقة النقل للحزمة، ولا يثبت تأكيد التطبيق أو اكتمال المعاملة.
ينشأ الخطأ عندما تتحول نتيجة ناجحة محلياً إلى إيصال تسليم عن بعد. صُمم QUIC DATAGRAM لبيانات يمكن للتطبيق أن يقبل فقدانها. فهو يحافظ على وحدة الرسالة، لكنه لا ينشئ إزاحات تيار أو تسليماً مرتباً للبايتات أو إعادة إرسال بعد اكتشاف الفقد، ولا يضمن ترتيب رسالة DATAGRAM بالنسبة إلى أخرى. حدود الرسالة محفوظة، أما ضمان الموثوقية فليس جزءاً من الخدمة.
يجب الفصل بين إطار QUIC DATAGRAM وبين مخطط UDP الذي يحمل حزمة QUIC. يوجد الإطار داخل حزمة QUIC، وقد توجد الحزمة داخل مخطط UDP. لذلك فإن رؤية الحامل الخارجي أو بناء الحزمة أو الحصول على ACK لا تثبت أن رسالة التطبيق وصلت إلى تطبيق الطرف الآخر.
يُعلن max_datagram_frame_size لكل اتجاه على حدة، وقيمته الافتراضية صفر. وتشير أي قيمة أكبر من صفر إلى استعداد الطرف لاستقبال إطارات DATAGRAM المطابقة في ذلك الاتجاه، وفق شروط المصافحة وقواعد حالة 0-RTT المحتفظ بها حيث تنطبق. لا يجوز للمرسل تجاوز القيمة المعلنة. لكن هذا لا يثبت وجود ذاكرة أو قدرة تطبيقية أو تسليماً لاحقاً. وقد يكون الحد الفعلي أصغر بسبب max_udp_payload_size وMTU للمسار. ولا تسمح الإضافة بتجزئة إطارات DATAGRAM، لذلك يجب أن يتعامل بروتوكول التطبيق مع الحد الأصغر.
تنتمي إطارات DATAGRAM إلى اتصال QUIC كله ولا تحمل QUIC stream ID. أما معرّفات التدفقات المنطقية، ومعنى البيانات، وسياسة الانتهاء، وإزالة التكرار، والترتيب عند الحاجة، وإشارة الاكتمال، فهي مسؤوليات التطبيق. لا يستطيع النقل وحده معرفة ما إذا كانت رسالتان تمثلان المحاولة التجارية نفسها.
عند تقديم التطبيق للمخطط، ينشئ QUIC إطاراً جديداً ويحاول وضعه في أول حزمة متاحة، مع الخضوع للتحكم في الازدحام وتنظيم وتيرة الإرسال. وإذا لم يسمح التحكم بالإرسال بعد، فعلى التنفيذ الاحتفاظ بالإطار حتى يسمح بذلك أو إسقاطه قبل الإرسال. ويمكن لوقت انتهاء يحدده التطبيق أن يؤدي إلى إسقاط سابق للإرسال. لذلك ينبغي تفسير نجاح واجهة التطبيق وفق عقدها الحقيقي؛ ولا يجعل RFC 9221 هذا النجاح إيصال إرسال أو استقبال أو اكتمال.
ينبغي للمستقبل أن يسلم الإطار الصحيح إلى التطبيق فوراً فقط إذا استطاع معالجته والاحتفاظ بمحتواه في الذاكرة. لا يوفر DATAGRAM تحكماً صريحاً في التدفق، ولا تُحسب بياناته ضمن حدود بيانات التدفق المعتادة. عدم ظهور حجب بسبب التحكم في التدفق ليس دليلاً على قدرة المستقبل؛ ويجوز له إسقاط الإطار إذا تعذّر عليه معالجته أو الاحتفاظ بمحتواه.
تستثير إطارات DATAGRAM ACK، رغم أنها لا تُعاد بعد اكتشاف الفقد. قد يتأخر ACK ضمن الحدود المعتادة، ويمكن لحزم استكشافية طلب رد أسرع. وقد يؤدي إعادة الترتيب إلى عكس اعتقاد مؤقت بالفقد. يثبت ACK معالجة طبقة النقل للإطار في الحزمة، لكنه لا يثبت معالجة التطبيق أو التخزين الدائم أو اكتمال العمل.
يجب فصل سجل هوية الرسالة، والقبول المحلي ونتيجة الواجهة، وسياسة الانتهاء، والدعم الاتجاهي والحجم الفعلي، وتأخير الازدحام أو تنظيم وتيرة الإرسال، والإسقاط قبل الإرسال، ورقم الحزمة ومساحة الأرقام، وملاحظات ACK أو الفقد وانعكاساتها، ومعالجة الحزمة في طبقة النقل لدى المستقبل، ومعالجة التطبيق، والتخزين الدائم أو اكتمال العملية.
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

