الخلاصة

  • تعامل RFC 3366 مع مثابرة ARQ على الوصلة كميزانية زمنية: كم من الوقت تنفق الوصلة في استعادة إطار قبل أن تتوقف؟ وليست المثابرة زيادة مجانية في الاعتمادية.
  • قد تساعد إعادة الإرسال تدفقاً واحداً، لكنها تضيف تأخيراً متراكماً أو تذبذباً أو حجباً للتدفقات الأخرى؛ وتأكيد الإطار لا يثبت وصول البيانات إلى التطبيق في الوقت المناسب.

الإطار ليس الحزمة كاملة

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

نُشر RFC 3366 بوصفه أفضل ممارسة حالية BCP 62، وطلب من مصممي الوصلات أخذ هذا الحد الفاصل بجدية. فهو لا يحدد تقنية لاسلكية بعينها ولا يفرض عدداً موحداً لمحاولات الإعادة. بل يشرح كيف تتفاعل آلية الإصلاح المحلية مع حركة الإنترنت التي تحملها الوصلة.

ميزانية المحاولات تستهلك وقتاً مشتركاً

يسمي النص استعداد البروتوكول للمحاولة مجدداً «المثابرة». يمكن للوصلة تحديد عدد ثابت للمحاولات، أو ترك المؤقتات وإجراءات اكتشاف العطل لتحدد متى تتوقف. والعدد ليس ساعة: فزمن الانتشار والتنافس على الوسط المشترك والاصطفاف وحجم الإطار والمعالجة كلها تغير الزمن الفعلي.

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

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

ما الذي تستطيع الوصلة معرفته بلا تخمين؟

قد يبدو طبيعياً إعطاء التدفق الذي «يبدو موثوقاً» مثابرة أطول، والبقية محاولات أقل. لكن RFC 3366 يوضح أن الملاحظة لا تكفي. فقد ترى الوصلة سلوك التحكم في الازدحام، من دون معرفة مهلة التطبيق أو ما إذا كان يفضل اكتمال البيانات على حداثتها. وقد تكون أرقام المنافذ مضللة أو يعاد تعيينها؛ وتجمع الأنفاق تدفقات مختلفة؛ ويحد التشفير من الفحص؛ وقد تُستبدل علامة الخدمة أو يكون معناها محلياً فقط.

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

وسّع RFC 3819، المنشور عام 2004 كإرشاد أعم لتصميم الشبكات الفرعية، الصورة إلى مفاضلة بين الفقد ومتوسط التأخير وتغير التأخير. وهو يدعم المرونة، لكنه لا يحول مثال محاولتين إلى خمس في RFC 3366 إلى قاعدة معاصرة أو مقياس لمدى النشر.

يظل الإقرار محلياً

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

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

المصادر

لم يكتب Lu Heng RFC 3366. وتُعرض مقالتاه صراحةً كعدستين تحليليتين للفصل بين التوصية والتنفيذ العامل والإعداد والنتيجة المرصودة.