الخلاصة

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

ساعتان لبايت واحد بلا إقرار

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

عرّفت RFC 793 هذه المهلة قراراً محلياً خاصاً بالاتصال. عند انتهاء USER TIMEOUT لا تحدث محاولة إرسال أخرى؛ تُفرَّغ الطوابير، ويُبلَّغ المستخدم بأن الاتصال أُجهض، وتُحذف كتلة التحكم، وتنتقل الحالة إلى CLOSED. وتحافظ RFC 9293 الحالية على الفصل نفسه: RETRANSMISSION TIMEOUT يعيد الإرسال، وUSER TIMEOUT ينهي الحالة.

لذلك سبقت سلطة التطبيق خيار UTO. أتاحت الواجهة المجردة عام 1981 تحديد المهلة عند OPEN وتغييرها عند SEND. ثم صاغت RFC 1122 حدّي R1 وR2 للإفراط في إعادة إرسال المقطع ذاته. عند R1 تظهر إشارات المشكلة، وعند R2 يُغلق الاتصال. ويجب أن يتمكن التطبيق من ضبط R2 لكل اتصال؛ أما توصية المئة ثانية على الأقل للبيانات فليست رقماً ملزماً لكل استعمال.

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

أربعة ثمانيات لم تبرم صفقة

نشرت RFC 5482 في 2009 وحددت UTO خيار TCP رقم 28 بطول 4. تختار البتة G الثواني أو الدقائق، وتحمل البتات الخمس عشرة الباقية القيمة المقترحة. الصفر محجوز. الحقل مدة زمنية، لا عدد مرات إعادة إرسال ولا تقدير RTT.

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

تقسيم السلطة صريح. ADV_UTO هو الرقم المعلن، وREMOTE_UTO آخر نصيحة مستلمة، وUSER_TIMEOUT القيمة المحلية المعتمدة. يحدد ENABLED تشغيل الامتداد، فيما يحدد CHANGEABLE ما إذا كان اقتراح النظير يستطيع التأثير في القرار المحلي.

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

البقاء الأطول له كلفة حالة

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

لهذا تلزم RFC 5482 التنفيذ بحدين. يجب أن يكون الحد الأدنى أكبر من RTO الحالي؛ وإلا فقد ينهي فقد عابر أو مسار بطيء الاتصال قبل أن تحصل إعادة الإرسال على فرصة معقولة. ويمكن تعديل الحد الأعلى وفق التوثيق وعدد اتصالات النظير واستهلاك الموارد وحالة الهجوم. وقبول اقتراح طويل لا يسلب الطرف المحلي حق التخلص من الحالة.

تؤدي keep-alive وظيفة أخرى. إذا استُخدمت مع UTO، وجب أن يكون مؤقتها أكبر من مهلة المستخدم المعتمدة، حتى لا تنهي سياسة إجهاض مختلفة الاتصال أولاً. كما يستطيع جدار ناري ذو حالة حذف المسار وفق مهلة خمول خاصة به. لا يفحص UTO المسار، ولا يوثّق النظير، ولا يضمن بقاء الاتصال حتى الرقم المعلن.

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

ما الذي غيّرته RFC 5482 فعلاً

لم تخترع RFC 5482 قدرة التطبيق على اختيار مدة الانتظار. جعلت السياسة المحلية مسموعة للنظير من دون نقل سلطة القرار. وهذا يميزها عن Window Scale الذي يثبت طريقة تفسير حقل بعد المصافحة، وعن PAWS الذي يستخدم الطوابع الزمنية لرفض معنى قديم في فضاء التسلسل، وعن SACK الذي يصف كتل البيانات الواصلة بعد فجوة.

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

المصادر