الخلاصة

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

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

نُشر RFC 3522 في أبريل 2003 بوصفه وثيقة Experimental لا Internet Standard. غايته إزالة غموض إعادة الإرسال: رقم الإقرار يثبت وصول البايتات، لكنه لا يبين هل استجاب المستقبل للنسخة الأصلية أم للنسخة المعادة. خيار TCP Timestamps يمكنه التمييز بين التاريخين.

وتقف صلاحية الوثيقة عند الكشف. خطوة (RESP) فيها لا تفعل شيئاً. تصحيح الاعتقاد وإعادة حالة التشغيل عمليتان منفصلتان، ولكل منهما أدلتها وسلطتها.

الإقرار الأول المقبول شاهد يأتي بعد الفعل

عند بدء حلقة استرداد، يضبط المرسل SpuriousRecovery على false ويحفظ في RetransmitTS قيمة Timestamp Value التي حملتها إعادة الإرسال الأولى، سواء بدأتها مهلة زمنية أم fast retransmit. لا يجوز أن تستبدلها عمليات إعادة لاحقة داخل الحلقة نفسها.

بعد ذلك ينتظر أول ACK مقبول يعترف ببيانات لم تكن مقرة. إذا كانت قيمة Timestamp Echo Reply أصغر تماماً من RetransmitTS، فلا بد أنها تعود إلى إرسال أصلي سبق النسخة المعادة. بعد اجتياز فحوص الغموض، يمكن تصنيف الاسترداد بأنه زائف.

لأولوية الإقرار معنى عملي. ففي المهلة الزائفة قد تثير الإقرارات المتأخرة للنسخ الأصلية سلسلة go-back-N من النسخ الجديدة. الكشف المبكر يستطيع وقف بعض ذلك قبل أن يتسع.

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

المظهر الواحد لا يثبت سبباً واحداً

قد ترتفع المهلة على نحو مفاجئ فينتهي RTO قبل وصول ACK. وقد تعيد الشبكة ترتيب الرزم فتنتج إقرارات مكررة تكفي لإطلاق fast retransmit. وقد يؤدي تكرار رزمة أو إقرار إلى النمط نفسه.

يثبت الطابع الأقدم أن الاسترداد لم يكن لازماً لتلك النسخة؛ ولا يثبت أن السبب هو إعادة الترتيب، ولا يحدد وصلة لاسلكية أو نطاقاً تشغيلياً، ولا يقيس الازدحام.

أما الأثر فيختلف باختلاف المحفز. غالباً ما ترسل fast retransmit الزائفة نسخة واحدة بلا حاجة وتخفض النافذة إلى النصف. وقد تعيد المهلة الزائفة المرسل إلى slow start وتولد نسخاً إضافية حين تصل إقرارات الأصول المتأخرة.

ويفصل RFC كذلك حالة fast timeout: إذا ضاعت الرزمة فعلاً، لكن المؤقت سبق مسار الإقرارات المكررة، فالاسترداد صحيح. السبق في اختيار آلية التدخل لا يحول الفقد الحقيقي إلى إنذار كاذب.

التساوي ليس دليلاً إيجابياً

شرط الخوارزمية الأساسية هو “أصغر من”، لا “أصغر من أو يساوي”. إذا كانت ساعة الطوابع خشنة أو كان المسار سريعاً، فقد يحمل الأصل والنسخة القيمة نفسها. حينها يمتنع RFC عن إعلان استرداد زائف.

هذا الامتناع قد يفوّت تحسيناً، لكنه يمنع رد حالة التشغيل اعتماداً على معلومة لا تميز بين التاريخين. عامل المقارنة نفسه جزء من معيار الإثبات.

ينبغي للايصال أن يحفظ القيمتين الخام، ودقة الساعة، والعامل المستخدم، والفرع الذي نُفذ. عبارة «تم فحص Eifel» لا تقول إن النتيجة موجبة أم سالبة أم غير حاسمة.

ضياع جميع الإقرارات يصنع تشابهاً خطيراً

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

عندما تصل النسخة، قد يعيد مستقبل يتبع قواعد الطوابع التاريخية طابع آخر أصل مرتب. سيكون أقدم من طابع الإعادة، فيشبه تماماً النمط الذي تبحث عنه Eifel.

تستخدم الخطوة 5 دعم DSACK وتسأل هل يغطي ACK كل البيانات المعلقة. في الحالة الحساسة تنهي الإجراء من دون إعلان يستدعي الرد. وهكذا لا تختزل الخوارزمية في echo < retransmit؛ مسارات الرفض جزء من مخرجاتها.

تخزين القيمة المنطقية النهائية وحدها يمحو سبب السماح بالاسترجاع أو منعه.

يستطيع المستقبل العدائي صنع شهادة مقنعة

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

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

الأمان ليس خاصية تختصر بعبارة «الطوابع مفعلة». إنه حاصل ما احتُفظ به، وما يستطيع الطرف الآخر معرفته، ودقة الساعة، والسياسة المتبعة حين يغيب الدليل.

لا يستخرج الكشف حالة لم تُحفظ

تعني (RESP) في RFC 3522 عدم القيام بشيء. تذكر الوثيقة أهدافاً ممكنة، منها استعادة حالة التحكم في الازدحام، ووقف go-back-N، وتعديل عتبة الإقرارات المكررة أو مقدرات RTT، ثم تتركها عمداً خارج النطاق.

جاء RFC 4015 لاحقاً بخوارزمية استجابة Eifel. فالاستجابة تحتاج إلى تحضير مختلف: من يريد إعادة نافذة ازدحام أو عتبة slow start يجب أن يحفظ قيمتهما السابقة. لا يمكن اشتقاق قيمة مُسحت من حقيقة أن الاسترداد كان زائفاً.

كما تحتاج العودة إلى حد أمان. يمكن أن تكون إعادة رزمة بعينها زائدة بينما ضاعت رزمة أخرى في الرحلة نفسها. يبين نقاش DSACK في RFC 3708 هذه الحالة المختلطة. إثبات براءة نسخة واحدة لا يبطل كل استجابة للازدحام.

للكاشف أن يصنف الحدث الذي رآه. وليس له تلقائياً أن يستعيد كل متغير تأثر بحلقة أوسع.

النجاح اللاحق لا يلغي أثر التدخل

بعد الكشف قد ترسل الاستجابة بيانات جديدة، أو تعدل RTO، أو تعيد النافذة نحو قيمة محفوظة. كل كتابة تحتاج إيصالاً: الحالة قبل المحفز، والحالة بعده، ونتيجة الكاشف، وقاعدة الاستجابة، والقيم المعادة، والتعديلات التالية.

ثم يبقى على الشبكة إيصال التدفق. اتساع النافذة لا يثبت توقف إعادة الترتيب، أو ثبات السعة، أو اكتمال معاملة التطبيق. وتحافظ أعمال لاحقة مثل خارطة TCP وRACK-TLP وCUBIC على الفرق بين تعرف إشارة فقد زائفة والاستجابة بأمان لشبكة متحركة.

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

ابنِ إيصالاً لفقد قابل للعكس

سجل تفاوض الطوابع ودقة ساعتها. احتفظ بنطاق البايتات الأصلية وطابعها، ومحفز الفقد، وعدد الإقرارات المكررة أو حالة المؤقت، وكل قيم التحكم في الازدحام قبل التدخل.

اربط أول إعادة إرسال وRetransmitTS الذي لا يتغير. احفظ أول ACK مقبول، والنطاق الذي أقره، وTimestamp Echo Reply، وكتل DSACK، وقرار الخطوة 5 بالتحديد. وبيّن هل استُخدمت الصيغة الأساسية أم الآمنة.

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

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

حدود الأدلة

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

يُعامل RFC 3522 كوثيقة Experimental من أبريل 2003، لا كـ Internet Standard. وتبقى RFC 4015 وRFC 5681 وRFC 5682 وRFC 6298 وRFC 7323 ضمن حالاتها ونطاقاتها الخاصة. أما RFC 9438 وRFC 8985 وRFC 9002 فهي أدلة مقارنة لاحقة، وليست إثباتاً لتنفيذ RFC 3522.

مقالتا Heng Lu عن السلطة والكود العامل عدستان تحريريتان معلنتان. تساعدان على فصل الإشارة الرسمية عن حالة التشغيل والنتيجة المرصودة، ولا تثبتان نية IETF.

النتيجة الضيقة كافية: يستطيع ACK تغيير التشخيص من دون تغيير الحالة. ولا ينبغي إعلان استعادة النتيجة قبل أن تعمل استجابة مستقلة ويُقاس أثرها.

المصادر